If you have ever spent a while delving into the bare metal of talking to the I/O pins on a contemporary microprocessor or microcontroller you will know that it is not always an exercise for the faint-hearted. A host of different functions can be multiplexed behind a physical pin, and once you are looking at the hardware through the cloak of an operating system your careful timing can be derailed in an instant. For these reasons most of us will take advantage of other people’s work and use the abstraction provided by a library or a virtual filesystem path.
If you have ever been curious enough to peer under the hood of your board’s I/O then you may find [Ken Shirriff]’s latest blog post in which he explores the software stack behind the pins on a BeagleBone Black to be of interest. Though its specifics are those of one device, the points it makes have relevance to many other similar boards.
He first takes a look at the simplest way to access a Beagle Bone’s I/O lines, through virtual filesystem paths. He then explains why relying so heavily on the operating system in this way causes significant timing issues, and goes on to explore the physical registers that lie behind the pins. He then discusses the multiplexing of different pin functions before explaining the role of the Linux device tree in keeping operating system in touch with hardware.
For some Hackaday readers this will all be old news, but it’s safe to say that many users of boards like the BeagleBone Black will never have taken a look beyond the safely abstracted ways to use the I/O pins. This piece should therefore provide an interesting education to the chip-hardware novice, and should probably still contain a few nuggets for more advanced users.
We’ve seen a lot of [Ken]’s work here at Hackaday over the years, mostly in the field of reverse engineering. A few picks are his explanation of the TL431 voltage reference, a complete examination of the 741 op-amp, and his reverse engineering of the 1970s Sinclair Scientific calculator.
We appreciate [Fustini]’s tip on this story.
BeagleBone Black image: BeagleBoard.org Foundation [CC BY-SA 3.0], via Wikimedia Commons.
Ahh I thought I recognized the name. I used his work on the IR LED (for controlling TVs and such) all the time back in the day. Glad to see he’s still around. Nice work, Ken.
http://www.righto.com/2009/08/multi-protocol-infrared-remote-library.html
yes, he’s well known for his IR led receive and transmit code for arduino, plus many other things. he’s one to watch and does useful/clever things.
Very nice. I think he confused K for M in the third paragraph.
TheRegnirps: can you clarify where K and M are confused? I couldn’t figure out what you’re referring to.
The business of using the linux filesystem for GPIO is total brain damage. A train wreck.
Clearly it is suitable for low bandwidth applications, like monitoring your front doorbell for the button being pushed and such like. And if you make the IO faster, you quickly run into the fact that linux is not realtime. The hot tip on the BBB is to use the PRU units and the sky is the limit.
Yes but it’s easy, OK for flashing an LED or turning on an IoT light switch, not OK to drive a dozen strings of WS2812s
As you point out heavily missing from his article is more than a sentence on PRUs – which let you do things that are impossible on arduinos or rpis without breaking in to custom logic or fpgas
BBs (and their PRUs) are currently my goto platform for manufacturing test, testing and programming many boards in parallel
I’m working on an article about PRUs now; it was too much to fit into the GPIO article.
One thing I still don’t get (and would be good to address in your otherwise excellent article) is how sometimes an overlay is enough to use a pin, and other times I seem to need to also export the pin and set its direction and mode.
It would be nice if there was an easier way to develop for the PRUs. Assembly is not my friend. :(
I spent some time watching the creator of beagleboard explain how you can use beaglebone’s PRUs to create device drivers that are recognized by the OS and still have all of their timing requirements.
However, the road to success is not straightforward. Any additional info or practical examples would be a huge help!
I won’t fault anyone for -using- the linux filesystem GPIO, but I will throw mud at whoever set it up that way.
As you say, it is entirely adequate for some things. I wrote some code to drive a stepper motor generating pulses using the filesystem IO. It was humorous to listen to the motor supposedly running at constant speed. It was singing a strange song.
I moved the code to the PRU and it was dead nuts on.
It is necessary for architectures where you have to synchronize write access to the gpio data register. On the AM335x you can use the set and clear registers and never have to worry about undoing changes made by the OS at other pins in the same bank.
And I do have to say that Ken’s blog post is a nice piece of work. Nice of Hackaday to highlight it here and give the Beaglebone some attention. I have always been a bit mystified that the Raspberry Pi gets some much attention compared to the BBB.
Marketing, as near as I can guess. I’ve wondered about that also, and from a technical merit standpoint, the BBB wins more points. It does lose points in cost (nominal $55 vs $35), though.
I’ve used RPi’s, but I much prefer the BBB, if for no other reason that the connectors have a layout doesn’t look like someone dropped them on a blank PCB from three feet up, and then said “Yeah, that’ll do”. I would like to see a BBB with WiFi/BLE to compete with the RPi 3.
You mean like the BeagleBone Green Wireless @ http://www.seeedstudio.com/depot/SeeedStudio-BeagleBone-Green-Wireless-p-2650.html?