[Ken Shirriff] Demystifies BeagleBone I/O

August 19, 2016 by Jenny List 15 Comments

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.

Adding GPIOs To The Raspberry Pi With The Camera Interface

July 24, 2014 by Brian Benchoff 9 Comments

GPIOs

The Raspberry Pi Model B+ was just released, and now everyone who picks one of those up has a few more GPIO pins to play around with. For the millions of people with the two-year-old version of the Pi, we’re still stuck with the same old, same old: 17 GPIOs on the big header, and that’s about it as far as toggling pins goes.

The Broadcom SoC on the Pi has far more GPIO pins than are broken out on the large header, and a few of those go to the CSI camera interface. These GPIOs can be broken out with a few flat cables (Portuguese, Google Translatrix), giving you four more GPIOs, and this technique can also be used with the new, expanded Model B+.

The CSI camera connector has two I²C lines that go directly to the camera, controllable in Linux as GPIO0 and GPIO1. There are two more GPIO connectors on the CSI connector controllable as GPIO5 and GPIO21. By carefully slicing and soldering wires to a flat cable, these GPIO lines can be broken out onto a breadboard.

There’s a video below demonstrating these GPIO lines being used to control a few LEDs. Of course, anything that is possible with a normal Raspi GPIO is possible with the CSI connector GPIO lines.

Continue reading “Adding GPIOs To The Raspberry Pi With The Camera Interface” →

Input And Output On A Single Pin

May 8, 2014 by Brian Benchoff 15 Comments

[Emilio] has a Raspberry Pi with a few sensors running totally headless. It’s a great way to gather data and post it on the Internet, but for the rare occasions when the Pi needs to be turned off for maintenance, [Emilio] needs to connect a monitor, a keyboard, and a mouse. Not a perfect solution when a simple pushbutton and indicator LED would suffice. There’s one problem with adding a simple button and LED combo: there’s only one GPIO pin available in the setup. That’s nothing a few resistors won’t fix.

After wiring up a very simple circuit on a piece of perfboard, [Emilio] met his design goal of being able to tell if the Pi was running and giving it a software reset button using only a single GPIO pin. The circuit requires only two resistors, and the software to make everything run – a simple Python script – toggles the pin between input and output, checking if the button is held down for five seconds. If it is, the Raspi powers off for [Emilio]’s routine maintenance.

PhatIO Uses File System To Control External Hardware

November 29, 2012 by Mike Szczys 27 Comments

[Andrew Smallbone] wrote in with a link to his latest open source project. This is phatIO, a USB I/O device that uses a mass storage file system for control. The idea is that any operating system can manipulate files on a USB storage device. This enumerates as mass storage, and any alterations you make to its file system will result in pin manipulation on the I/O header.

We’ve long been Linux advocates and enjoy the fact that everything on a *nix system is a file. This simply extends the idea across multiple platforms. [Andrew’s] guide for the hardware gives an overview of how the system is structured. The top ‘io’ directory contains sub-directories called mode, pins, status, and a few others. Inside the directories are files for each pin. Writing to these files has much the same effect as writing to a data direction register, port register, or reading a pin register on a microcontroller.

The board is not yet in production and the github link to his hardware files gives us a 404 error. But there is code available for several software demos. After the break we’ve included video of the phatIO driving a Larson scanner.

Continue reading “PhatIO Uses File System To Control External Hardware” →

A Simple Method For Expanding Arduino IO Capacity

November 8, 2011 by Jeremy Cook 52 Comments

Although there are other ways to do this, [Rod] has decided to write up his method of using two Arduinos and the I2C protocol to expand an Arduino’s IO capacity. As seen in the picture above, you’ll sacrifice 2 analog pins, but if you happen to need IO and have an extra Arduino lying around, this could really help. [Rod] also notes that this method could be used with many Arduino’s in parallel if the situation called for it. The code for this simple hack is included as well, so be sure to check out his site if you want to try this idea.

Some other solutions for extra IO would be to buy an Arduino Mega with 54 digital IO pins or the Muxshield which gives you 48 IO (and is stackable for other shields). An advantage of using the two Arduinos, is that if they are needed to be split in the future for different projects, this could be done. It’s good to have options for your IO needs as every hack is different.

Check out the video after the break to see everything being hooked up.

Continue reading “A Simple Method For Expanding Arduino IO Capacity” →

Arduino I/O Speed Breakdown

January 6, 2010 by Devlin Thyne 45 Comments

[Jee Labs] has worked out how long it takes for an Arduino to perform various I/O operations. Predictably, analogRead() takes the longest, followed by analogWrite(). Arduino really falls behind when it comes to digital pin I/O: digitalWrite() takes a whopping fifty times longer than a direct bit write to a port register! This is something to take into consideration when you are looking to do some beefy I/O with an Arduino. Perhaps this I/O performance will be addressed in the future with Arduino 1.0.