…I wanted to satisfy one of my persistent self-stabilizing-flying-thing itches: how to pass control inputs from a handheld radio to the flying thing in question without having it process several consecutive servo pulse lengths. For the most common & simplest Arduino-compatible balancing algorithms, this limits the maximum control update frequency to 50hz, since the microcontroller has to actually measure 10 milliseconds of pulse commands (for, say, up to 5 or 6 channels) out of every 20 milliseconds. The remaining time is often taken up by software floating point multiplication and division.
The reason it takes so much of the loop time is because the abomination that is Arduino’s pulseIn() command. It’s a “busy wait” loop that sits and increments a counter while the pulse is being detected. It’s neither interrupt based nor uses the hardware timers (the loop is timed empirically). So while taking in a servo pulsewidth, the microcontroller can literally do nothing else. A little inefficient, in my mind.
Biohacking — Using Insulin Load for Better Sleep and Recovery
Get the only spam-free daily newsletter about wearables, running a "maker business", electronic tips and more! Subscribe at AdafruitDaily.com !
I think this is a perfect example of where the Arduino development environment is detrimental – it discourages people from learning efficient microcontroller programming with a less crippled language.
Adding an XBee to work around a major software limitation specific to the Arduino environment should never happen…
The Arduino team needs to do something to ease the transition from hand-holding (the Arduino IDE) to a more efficient way of doing things (Straight AVR-GCC.)
The AVR’s Input Capture Pin (ICP) is the right way to do pulse measurement. It completely avoids any CPU overhead while waiting for transitions and, unlike the busy loop, is unaffected by other interrupts that might fire during the measurement so there is far less jitter.
One caveat — on the Arduino it is necessary to reset the maximum value for TCNT1 or else only 8-bit values will ever be measured.
I think everybody should just choose the tools that they like and feel comfortable with. You can write nice and efficient code with the Arduino IDE and do not have to go to “Straight AVR-GCC”. Yes, pulseIn() is not that great, but it was written with ease of use in mind (I never use it, unless to just test something).
Just identify your bottlenecks and rewrite the functions that bother you. It is a great learning experience and one day you might drop the IDE or maybe you never have to.
Aha, I almost figured this would get on here! This hack has already been superceded by a pin change interrupt and timer based method. The Xbee was from the start a little ridiculous since it’s such a redundant workaround that costs so much, and the Nano also adds to the cost while being utterly underutilized.
It was a fun, brief “duh” project.
However, for old 72mhz and 75mhz FM radios, tapping the PPM port can be a great upgrade to a 2.4G system that has more extensibility than buying a new cheap 2.4G, rc-only rig.
Damn, and I was totally thinking of its potential as a kit too…
(Also, I hate embedded programming and diddling registers. Always have, always will.)
Additionally, using PC interrupts and timers is (i think) the only practical way to measure several pins in parallel, which is what you’d need for RC pulse reading in a multi-DOF vehicle controller.
If, however, you are only taking in one pulse, then using an ICP pin to trigger a timer is probably the least overhead method. This is probably used in single channel RC motor controllers since they can spend all the free time commutating the motor.