…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.
Adafruit publishes a wide range of writing and video content, including interviews and reporting on the maker market and the wider technology world. Our standards page is intended as a guide to best practices that Adafruit uses, as well as an outline of the ethical standards Adafruit aspires to. While Adafruit is not an independent journalistic institution, Adafruit strives to be a fair, informative, and positive voice within the community – check it out here: adafruit.com/editorialstandards
Stop breadboarding and soldering – start making immediately! Adafruit’s Circuit Playground is jam-packed with LEDs, sensors, buttons, alligator clip pads and more. Build projects with Circuit Playground in a few minutes with the drag-and-drop MakeCode programming site, learn computer science using the CS Discoveries class on code.org, jump into CircuitPython to learn Python and hardware together, TinyGO, or even use the Arduino IDE. Circuit Playground Express is the newest and best Circuit Playground board, with support for CircuitPython, MakeCode, and Arduino. It has a powerful processor, 10 NeoPixels, mini speaker, InfraRed receive and transmit, two buttons, a switch, 14 alligator clip pads, and lots of sensors: capacitive touch, IR proximity, temperature, light, motion and sound. A whole wide world of electronics and coding is waiting for you, and it fits in the palm of your hand.
Have an amazing project to share? The Electronics Show and Tell is every Wednesday at 7pm ET! To join, head over to YouTube and check out the show’s live chat – we’ll post the link there.
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.
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.