Twiddling an LED using the BeagleBone’s embedded Linux

If you comfortable working with 8-bit microcontrollers, the thought of moving to a hardware platform running embedded Linux may be a bit daunting. After all, there’s a lot going on between you and the chips on a board like the BeagleBone seen above. But [Matt Richardson] shows how easy it can be to get at the pins on this device. He put together a primer on hardware control from the embedded shell.

You will remember that the BeagleBone is the newest generation of the BeagleBoard. The ARM processor and other goodies make it a powerful tool, and those already familiar with Linux will be able to get up and running in no time. Just connect the board to your network and SSH into it to get started. [Matt] outlines this setup process in the clip after the break. He then hits the reference manual to find the pinout of the female headers on either side of the board. Each available I/O pin is mapped to the /sys directory and can easily be controlled by echoing your commands to the appropriate files. But [Matt] went a step further than that, writing his own Python library that implements Arduino-style syntax like the digitalWrite() function.

This example should give you enough of a shove to start porting your own libraries over for use with the device. Don’t forget to document your projects and tip us off about them.

Post navigation

18 thoughts on “Twiddling an LED using the BeagleBone’s embedded Linux”

The pins on the Beaglebone have a really low current limit. 4~8mA for most of them. So to be safe with the red LED you should use a 470 ohm resistor, or check the data sheet: http://www.ti.com/lit/gpn/am3359 starting on page 19, to see if you are on a 8mA pin.

How quickly does that code run? I figure there must be some significant overhead involved in repeatedly opening/closing files like that. Surely there must be a better way (and maybe a way to set multiple pins at once)?

/sysfs is the next generation virtual filesystem, and it replaces “procfs”.

If you know procfs, it means you can put and get values in that “tree”: cat “1” > /proc/foo or /sysfs/foo.

This is VERY useful. For the features in the VFS, you don’t actually need native language support (wrappers and libraries), as you can pretty much set and get system variables and system flags from anything that knows how to talk to the VFS (like say, any shell environment, or Perl Python etc.).

So you could do something like cat the value of random from sysfs and send it to a pin, and you could be displaying that random on an LED pin or sending that noise to a speaker. If you can write device drivers for Linux, you could create a device that’s a LOL shield driver, and control it from the shell. That’s pretty cool.

^^ What mike said. Instead of banging the GPIO port bits directly (by mmap’ping), e.g. a simple *my8bits|=0b00100101; You have to: call open() call write() call close(), plus the overhead of the kernel to check that open() filename is a “device”, then test for true/false, then mask and toggle that GPIO port for you. Granted you can leave the file open at start and keep calling read()/write(). On the beagleboard I wasn’t able to get even 1MHz of straight toggling a bit via fileio.