Go Fund Me again...

[1eye]

This is cross-posted from General Discussion, because some only read the CCSVI forum. Plus, I am inordinately proud of my prototype...

I have decided on the RGB Shades which was a successful Kickstarter project. I am nearly ready to start using them. I have bought an Arduino and a little daughter board with an accelerometer and gyroscope on it. There is also a thermometer on the same chip but I don't think I'll need it.

This little board needs a calibration cycle, so I thought I would run one. To prove it works, here is one cycle's worth of calibration data. This text was printed out by the Arduino calibration program. It takes 1000 readings and averages them.

*****************************************************the calibration print-out*****************************************************************************
...
...
...

FINISHED!

Sensor readings with offsets: -5 -2 16384 2 0 -4
Your offsets: -2885 1378 4644 70 19 9

Data is printed as: acelX acelY acelZ giroX giroY giroZ
Check that your sensor readings are close to 0 0 16384 0 0 0
If calibration was succesful write down your offsets so you can set them in your projects using something similar to mpu.setXAccelOffset(youroffset)

*****************************************************the calibration print-out*****************************************************************************

So I hope to have prototype number 1 working shortly. Wish me luck.

Chris

[Cece]

Your prototype sounds impressive. Much luck is wished. You may not need the luck if you've got the brains.

[ThisIsMA]

Hi 1eye,

I am confused by your post, but interested. What kind of a prototype are you talking about and what does it do?

Also if you're trying to raise money for it, can you provide a link to the Go Fund Me page?

I only read the ThisIsMS CCSVI board (and not very often these days since things have slowed down so much). But I stopped by and I'm curious about what you're creating, if you can explain it in simple terms.

What is the concept and what does it do that could help a person with MS?

Thanks!

M.A.

[1eye]

is the URL for my campaign. Reasoning that Dr. Norman Doidge and Dr. Oliver Sachs have both successfully treated patients with vestigial balance problems using neuroplasticty and existing sensory systems (tongue and eyes), I intend to train balance using an IMU (Inertial Measurement Unit, which is a 1" square PCB), glasses with LEDs in them, and earphones. The code for the IMU, the glasses, and the headphones exists and is ready to try using hardware I now have on hand. I'll let you know when it works.

[1eye]

I have encountered a snag, a failed piece of hardware. I have back-up, thanks to my one donation. Meantime, I wrote a screed about software which I will share with you. Please ignore this if you are not interested, as many many people will not be:

*****

Integers, Interrupts, Sharing, Pushing-Pulling, Latching, Self-Clearing, Interrupt Sources

The following is a small explication of the concepts mentioned in the title. They are among those in software with the largest and most critical need of disambiguation.


1. Integers:

An integer is a number. In digital software and hardware it is a number which is possibly represented in 4, 8, 16, 32, 64, or more bits. The finite number of bits is a hardware limitation. There really is no limit to the size or precision of this number in the mind of the user. The number of bits is of the ideal integer is really infinite. There is an assumption of zeros at either end. To abbreviate the word integer, it is often, in software languages, to reduce typing effort, abbreviated to int, INT, or Int. This abbreviation means "integer".


2. Interrupts:

A similar abbreviation is also "INT, int, or Int. This is often buried in the naming of a signal or subroutine or function. This name does not indicate an integer. It denotes an interrupt.

An interrupt is a signal, usually a single digital line which is either ON or OFF. This signal has a special meaning to software. It tells software that it must INTERRUPT the normal flow of execution. In response to this signal, the CPU will suspend the normal execution of the software, and "vector". Vectoring causes the CPU to save its program counter's value into a special register. This counter, normally stepping from one instruction to the next, is temporarily replaced with a pointer to the beginning of the "interrupt" subroutine.

The difference between this routine and any other program function, is that it is reachable by the hardware vectoring operation.

Software can optionally reach this subroutine by any logical software operational path, by being named as the next step of a program, but it is usually assumed that it is only reachable by vectoring. At the end of this subroutine, a "return from interrupt", a special instruction, is executed. The treatment of this instruction by software, is with a normal "return" instruction. But in reality this "return" at the end of the interrupting subroutine will be a "return from interrupt" instruction, sometimes an "RTI" in assembly language, which tells the CPU to go back to using its saved program counter, as if nothing had happened.

In order to set up the CPU to achieve this vectoring operation, the location of the special "interrupt" subroutine must be saved in a separate CPU hardware register. Now future "vectoring" operations may take place.

Because the interrupt subroutine looks to the programmer like any other "function" or subroutine, with a name and a normal "return" instruction at its beginning and end, it can not be easily distinguished by the programmer from any other software. It must therefore be explicitly described as such, either in its name, or in comments. That makes it look 'normal' to code readers, who may have no knowledge of the special hardware operations it represents. It is in fact, anything but normal, because of the special hardware behind its execution.

That special hardware includes the CPU's vectoring instructions and operations, and the hardware line, the "interrupt" signal, which is usually an indication that the hardware has reached some distinct state. In the case of one particular piece of hardware, several real occurrences may be indicated by an "interrupt" signal, such as that a FIFO register has become full, or that the user has dropped the hardware, or any number of things has occurred which are immediately detectable.

The interrupting hardware often needs an indication from software, that this occurrence has been detected, and that is usually one of the things the "interrupt" subroutine has to do. It also sometimes must set up hardware conditions to allow the next execution of this subroutine to occur.

(In order to confuse matters even more, some instruction sets have a special instruction called a "software interrupt'. This instruction results in vectoring, as if a hardware event had occurred. But none did. It is programmers interrupting themselves.)


3. Sharing:

A hardware line, a digital signal, may be shared, by connecting together two or more pieces of digital hardware. The digital signals are driven by an "open collector" or "open drain" circuit. When not driven, this device is "open" or represented by a high impedance, where essentially no current actively flows into the circuit. This signal can be shared by using a passive pull-up resistor, which is the default source of the signal's current.

When not driven by any of the sharing circuits, it is normally pulled into a logic "high" or "one" state by the pull-up resistor. Any of the "sharing" or connected-together circuits can be driven into a 0 or digital "low" state, by actively turning on one or more driving circuits, usually a transistor switch's collector or drain, so that it sinks current, overriding the pull-up resistor,s "one".

Thus the interrupt line may be shared by two or more hardware sources.


4. Pushing-pulling:

A shared signal my be driven or passively not driven. Thus, a digital signal may be shared or un-shared. One designer may share the signal by connecting it between two driving devices. Another may decide not to connect two lines together, thus making the circuit un-shared.

So a shared line may be driven low or 0 by any sharing devices, but an un-shared line may not. In such an un-shared circumstance the driving device must actively drive the line to logic high or logic low, 1 or 0. If this is the case, no pull-up resistor is required.

Instead of a pull-up resistor, an un-shared line is actively driven either-high or low. The circuit driving this un-shared line must actively pull it low, or push current into the driven device, with an active circuit to make the line go high, or 1. This will simplify the bill of materials, the assembly, and the cost.

The authors (conveniently or not) of the hardware, have sometimes left this decision to the user, the hardware designer. The penalty for this convenience in hardware design is a single line of code to program the line to be push-pull , in the case of an un-shared line, or active-low (open-high, or pulled-up with a resistor), in the case of a shared line. The kind of circuit design is unlikely to change, so more than one such line of code will usually not be needed.


5. Latching:

An interrupt signal may be driven by a source signal which goes active (programmatically high or low; again, unlikely to change) and then, within some very short and predictable interval, goes inactive (low or high) again of its own accord, depending on the design of the driving hardware or software, or both. If there is such a waveform driving the interrupt line, no special software in the driven (interrupted) device is required to clear the interrupting condition. It does it by itself.

There may, however, not be such a waveform driving the interrupt line. The interrupt condition may, in this case, be "latched" by the driving (interrupting) device, until the latch is cleared by some software-driven action.

That may be a register in the interrupted device, which can only be cleared by software (usually in the interrupt subroutine). In this case the interrupt line is programmed (again, usually only once, in some form of "setup" code) as a "latching" interrupt -- latching high, or low, depending on the interrupting hardware's inactive versus active state. Again, some form of single-use "setup" code is required.


6. Self-Clearing:

This is the case, above-mentioned, of an interrupt driven by a signal, periodic or not, which goes inactive within some short interval, by itself, without any software intervention. A self-clearing (non-latching) interrupt may require no software set-up, but the programmer should be aware nothing needs to be done. Conversely, depending on hardware requirements, software set-up may indeed be required.


7. Interrupt Sources:

It should be clear by now that interrupt code is not trivial. A lot depends on the individual hardware design. Code can be designed for many different hardware design choices, with the use of templates, inheritance, and variable compilation and execution being possible software requirements, or areas where improvement is possible.

Interrupt sources may be one-time events, or periodic. There may be requirements for nested interrupts, with differing priorities, or recursion. They may or may not themselves be interruptible, and may or may not have detailed time constraints.

Interrupt sources may be hardware detection of real-world conditions, such as physical event detection, user gestures, communication events, state changes of various kinds, or even changes in software execution ("software interrupts"). They often depend on details of hardware design and execution environments.Interrupt design is one of the most sensitive areas of software design.

There may be several possible interrupt sources in the same hardware. These may require separate software enabling, software service routines, hardware set-up and clearing.