Continue reading about BeagleBone Black

I’ve started writing down my latest findings about BeagleBone Black on the Thing printer website. Currently only three posts, but in my own humble opinion, worth a read : )

http://www.thing-printer.com/reach-expansion-board-replicape-ready-review/

http://www.thing-printer.com/replicape-printing-tree-frog/

http://www.thing-printer.com/writing-clutter-apps-beagleboneblack-using-python/

http://www.thing-printer.com/3d-rendering-pvr-sgx-beaglebone/

http://www.thing-printer.com/distribute-software-opkg-beaglebone-black-2/

Replicape Front Page Picture

I’ve also started the pre-sale of Replicape! The Replicape is now at Revision A4A with an added expansion port for a little project I’ve called Reach, which is basically a second cape that slots on top of Replicape giving it three more extruders for those interested in experimenting with CMYK color blending or similar. There are also a few improvements to the layout for some more noise reduction.

Update: Hipstercircuits.com will be featured on EEWeb.com! Yay!

Replicape Rev A4 ready for review

Replicape-1-of-6Replicape revision A4 is finally ready for review! The important changes include a brand new layout (Huge thank you to Stoneshop for sending me a brand new layout, that’s what open source hardware is all about), a few grips for reducing the noise and a few tweaks on the user interface. If anyone else besides David from CircuitCo wants to do layout revision, go right ahead! Comments are welcome.

A lot of people a have been asking about the board and when it will be ready and all I can say is: Soon! CircuitCo will be producing the board, testing it and handling RMAs and it will be sold through all your favorite electronics distributors (The same that sell BeagleBone black), so when it finally starts selling, it will definitely be available! I have not yet been able to get a definite date from CircuitCo, but they are reviewing as we speak, so I’m estimating sales will begin in a matter of weeks. The price is $179.

As for the software, there have been a lot of improvements in speed and bug fixing. Since this summer, there has been a software bug in the ADC driver that has caused a few of the measurements to be dropped giving unreliable temperature readings. A backport from the 3.12 kernel seems to have fixed this, so everything looks great. In fact We are now aiming at a Kickstarter in Q1 of 2014, in the meantime, here is a video showing an early prototype of Thing printer printing something : )

Tree frog on Thing from Elias Bakken on Vimeo.

Also, Koen has been doing a great job getting Slic3r running on Angstrom, so I’m working hard on moving everything to the 2013.06 dist of Angstrom so I can finally slice directly on the printer. Yay!

Most readers of this blog are very familiar with the features of the Replicape, but if not, have a look at the repository for an overview of the features. I also had a beer with Simen of the Bengler project yesterday, the guy that wrote the original code for GRBL, which is the the core of just about every desktop 3D-printer available. He gave me some great tips on improving the path planner in Replicape. In particular he mentioned having an n-step path segment prediction instead of the 18-step currently available on the Arduinos. Also, he pointed out that there would probably be a significant noise reduction in the steppers due to the much more fine pitch timing of the steps from the 200 MHz PRUs compared to the 3o kHz timers in the Arduions. He also liked the readability of code from writing Python : )

Sorry for not updating the blog lately, I’ve been busy with a paper, but now that that’s handled, I’m back baby! As a band-aid, here is a picture of the brand new Manga Screen (Rev A3) that arrived yesterday.

Manga Rev A3

DC-DC buck converter noise on Replicape

image (2)

The Replicape has two DC-DC buck step down regulators, one for supplying the 5V to the BeagleBone (Black), a MCP16321 and one 12V so you can use 12V fans or LEDs for keeping your stuff cool. (Pun intended)

When both the Replicape and the Manga Screen were finished and I was finally able to test them together, an issue arose. The screen would suddenly cut out during boot because the power to the USB was cut by the BBB. Only by lowering the brightness significantly and adding an extra electrolytic capacitor across the 5V input was I able to make them work together. Why was this happening?

It turns out that Rev A3A has a transient load issue when powered through the Replicape board. This was traced to the 5V DC-DC step down regulator. But even with slow changes in load, for instance ramping up the brightness on the display, the display would suddenly be cut when the load was high.

The Beaglebone has a power management circuit for the USB, a TPS2051 which has an under voltage lockout of 2V. This is probably what kicked in when a combination of switching noise and a sharp transient occurred.

Switching noise issues are not the easiest to debug. It doesn’t help (much) to add lots of capacitance to the output of the converter, it simply will not help reduce noise in the 200MHz range.

One solution to this problem was to limit the slew rate of the N-MOS on the step down converter by adding a resistor in series with the boost capacitor. This does decrease the efficiency of the converter by something in the region of 1%, but that is a small price to pay for a working USB power.

Below is a picture of a Replicape with a slew rate limiting resistor and one without. It is clear that the switching noise has been dramatically reduced with the slew rate limiting resistor.
Heat management is an important on such a small board, but a 1% reduction in efficiency should be acceptable.

image (3)image

A different solution would be to filter the noise by using an rc/lc filter or similar on the output, an RC snubber as they call it.

Sorry for the few updates lately, I’ve been in limbo trying to get ready for Maker Faire Rome. And the in the end I never did get the printer running in time for the event, haha! Still, it was a good show.

Ok, so this is the only hardware issue I am aware of, so hopefully CircuitCo will start production now.

Also, HipsterBot is dead! It’s now called Thing! You know, ‘cos it prints things? More updates in that later, I’m working on calibrating the printer now, so a few videos in a few days I’m sure!

Manga Screen Rev A2 – How to assemble

Populate the PCB

Remember to take your protein pills before such an endeavor. tools

Apply solder paste at strategic locations. Doesn’t have to be perfect, it will smear out in the reflow oven. solder-added

Into the oven it goes. This was actually after being in the oven. There are a lot of bridges here, these must be removed with a solder iron, flux and solder braid.
Manga Rev A2

Programming

This revision has an Atmega 32U4 AVR chip so there should be plenty of power to spare for anyone wanting to do some fancy touch filtering. The source code is in the Manga Screen repository.

Atmel stopped supporting FLIP for Linux on version 3.2.1, before they added support for Atmega 32U4, so in order to program the Atmega 32U4, I had to do the following:

sudo apt-get install  dfu-programmer

dfu-programmer atmega32u4 erase

dfu-programmer atmega32u4 flash MangaScreen.hex
Validating…
6436 bytes used (22.45%)
dfu-programmer atmega32u4 reset

The reset command sets the program counter (PC) to 0×00 so the user program starts. If you hit the reset button at any time, the PC will jump to the start of the bootloader code.

USB Device

The USB driver is built on top of the LUFA library.  It should populate as a USB with two devices, one serial port and on Human Interface Device (HID). The serial port will accept commands such as “set display on”, “set backlight 128″, “set gamma yadayada”. perhaps also Upload/download EDID etc.  The HID  will of course be the touch screen.

Software implementation of a slave EEPROM chip

A couple of weeks ago we did not know that the EEPROM chips that are present in all displays and supplies the host with EDID info can also be programmed through the HDMI cable. Therefore we thought the best thing to do would be to let the AVR chip handle the role of the EEPROM. The problem was that the I2C controller on the AVR had been reserved for the touch screen controller so we had to use two GPIO lines and handle the timing our selves. But there was only one interrupt line available so we gave that the the SCK line, when actually it is the SDA line that initiates the start and stop conditions. So if anyone ever decides to do make the same mistakes we did, you might enjoy the EEPROM.c and .h files found in the repository. However, my advice is: Spend that extra 10 cents on a real I2C EEPROM chip : )

The (almost) final result

As you can see in the picture below, the screen works fine and dandy. Right now it is run through the DVI interface of my Ubuntu box at the native resolution of 480×800@60Hz. The idea is that this screen will be used primarily with the HDMI interface for BeagleBone Black.

bit-little-brother

I also made a video as soon as I got the screen working. Here it is:

Manga screen rev A2 from Elias Bakken on Vimeo.

The next step

That is to get the touch functionality working by porting the Linux driver for the mXT224 to the AVR.

Capacitive touch support for Manga Screen on BeagleBone Black

Manga touch

The first evidence of working touch functionality for Manga Screen can be seen in the video below.

Currently I have only gotten this working on Ubuntu 13.04 with LXDE as the desktop environment. The touch screen is controlled via I2C at the moment, so four separate wires are going to the display in addition to the HDMI cable. This has all been fixed in the Rev A2 of the Manga Screen where  all communication is done via USB.

There was quite a bit of work that had to be done in order to get the Synaptic ClearPad 3000 series touch screen controller working with X on the BeagleBone Black.

- Port the Synaptics driver from kernel version 2.6 to 3.8.13

- Recompile the tslib library module

- Recompile the tslib input module

- Write a device tree overlay

Below are the details for reproducing this. I’m sure a lot of steps have been left out, but at least this is better than nothing.

Compile the tslib module

The tslib driver consists of both a shared library and a Xorg input module.

I don’t know if this is normal or not, but it appears that the tslib xorg module is dependent on
libts.so and is compiled in statically.The changes that were made to the module are currently in the git repository of the Manga Screen.

./configure
sudo make && sudo make install

If the default install dir is used, the .so-file has to coped to the location where the xorg input module expects to find it:

sudo cp /usr/local/lib/libts-1.0.so.0.0.0 /usr/lib/arm-linux-gnueabihf/

Compile the Xorg tslib input module

Here is a post explaining how to get the source code and recompile it:
http://boundarydevices.com/debian-in-more-depth-adding-touch-support/

Since there is no dependency information in the tslib lib (libts.so), you need to fix that:
http://stackoverflow.com/questions/11238134/dpkg-shlibdeps-error-no-dependency-information-found-for

I used the last solution.

Recompile the package:

sudo debian/rules binary

To re-install the debian package, do this:

sudo dpkg -i ../xserver-xorg-input-tslib_0.0.6-7build3_armhf.deb

The file /usr/local/etc/ts.conf is the overwritten, so remember to update it.

After that, you can compile with:

sudo make && sudo make install

You need to get the source for the tslib
ts_error(“line in %s is %s\n”, conffile, line);

 Rotation of screen with tslib does not work

With the tslib installed and the screen rotated, it turns out that X crashes, look:
http://patchwork.freedesktop.org/patch/1256/

I have been unable to get tslib 0.0.6 to work with Rotation=CCW on the screen. I get the error:

X: /usr/include/xorg/privates.h:123: dixGetPrivateAddr: Assertion `key->initialized' failed.

Instead I have had to hard code the rotation into the driver:

Rotation rotation = RR_Rotate_90;//rrGetScrPriv (pScrn->pScreen) ? RRGetRotation(pScrn->pScreen) : RR_Rotate_0;

Other errors: 

tslib: Selected device is not a touchscreen (must support ABS and KEY event types)

Make sure the right input device is selected try evtest /dev/input/event1. IF this reports these two symbols, it is the right device.

More info:

I’ve written up much of the process on the Replicape wiki as well, so if you want to reproduce this or expand on it, have a look at that as well: http://wiki.replicape.com/index.php?title=Installing_Ubuntu

Enable Device tree overlay on startup on BeagleBone Black

Update July 17, 2013: It appears that the reason the overlay can only be gotten from the firmware built in to the kernel and not from the file system (in /lib/firmware) is a bug in the latest kernels. Not sure which kernel numbers are affected by this, but it might work for earlier versions.

Ok, this should have been easy, but alas. Probably took me tree hours to figure it out. The key here is that loading firmware from file system does not work, you have to make it built-in and have it piggybacked with the kernel. This might be a bug because the file drivers/base/firmware_class.c does try to load the file, but fails, presumably due to insufficient rights. Go figure..

For this to work, you need a working “compile the kernel-setup”. Here is one example:

http://wiki.replicape.com/index.php?title=Compiling_the_kernel

Then you need to add the device tree source file to the directory:

kernel/firmware/capes/

So for me adding a capacitive multitouch driver based on I2C, I add the file:

BB-SYNAPTIC-00A0.dts to that directory.

You also need to edit the file

/arch/arm/boot/dts/am335-bone-common.dtsi

and then add something like this:

			/* Always enable the Synaptic multitouch over I2C overlay */
			slot@103 {
				ti,cape-override;
				compatible = "ti,beaglebone-black"; 
				board-name = "BB-SYNAPTIC";
				version = "00A0";
				manufacturer = "Synaptic";
				part-number = "BB-SYNAPTIC";
			};

If you do not want to recompile the kernel every time you want to add this line instead.

compatible = "kernel-command-line", "runtime";

You also have to edit the file kernel/firmware/Makefile

and add your device tree overlay as a cape:

# the virtual peripheral capes for Multitouch
fw-shipped-$(CONFIG_CAPE_BEAGLEBONE) += \
	BB-SYNAPTIC-00A0.dtbo

Recompile with action “uImage” and scp the uImage over to the /boot/ directory if you are on Angstrom. On Ubuntu, it’s the zImage that goes into /boot/uboot/.

 

Finally a working 4.3″ HDMI compatible LCD for BeagleBone Black!

image (2)

And it only took me 4 days to debug it!

This display is an LQ043Y1DX07 from Sharp, the same display that is in the HTC desire HD. The resolution is 800×480.
The display driver is an HX8363-A from Himax.
The receiver chip is a TFP401 from Texas Instruments which is really a DVI receiver. The reason for having a DVI receiver instead of an HDMI receiver is that having an HDMI receiver, you need to pay royalties.

The display needs a small amount of initializing through a 9-bit SPI interface. Currently this is done with a very inexpensive microcontroller, the MSP430G2231, the same that comes with the Launchpad. The current version can then be flashed using the Spy-bi-wire from a Launchpad.

The EDID information is read from an EEPROM chip. If you want to make EDID information yourself and do not have access to a windows machine, have a look at the python script I made: https://bitbucket.org/intelligentagent/manga-screen/overview

The HX8363-A actually has a lot of registers for debugging the parallel RGB interface. You can check the state of the HSYNC, VSYNC, ENable and ClocK in addition to this you can check the status of the booster voltage and the result of the sleep out command.

image

The working title has been Replicape display, but from the next revision on I’m calling it Manga Screen

So why is this important?

4.3″ is fairly small size for an HDMI compatible display. There are several versions available in larger sizes at various sizes. The reason for this is that you need a high resolution to be compatible with the TFP401 PLL which is 25MHz. Now there are several LCD displays that are small, and have a large resolution, but newer displays with high resolution usually use the DSI protocol which is also impossible to get a hold of unless you are a member of the MIPI org.

The main use for this is together with the Replicape 3D printer cape, but I’m sure it can be used with a lot of other interesting projects as well.

What’s next?
Well, what’s a screen without capacitive touch? I also want the screen to be powered via USB and programmable via the same interface. If that works for the next revision, the idea is to get a batch of 50-100 made and we’ll see how it goes.

This is of course open source hardware and software: https://bitbucket.org/intelligentagent/manga-screen

Update: I tried it on a Raspberry Pi as well, and lo and behold, it worked! (Hope I’m not swearing in church here, BeagleBone, I still love you the most : )

raspiUpdate 2: The screen now has the right orientation: http://hipstercircuits.com/problems-with-beaglebone-black-and-their-solution/

Problems with BeagleBone Black and their solution

This page will be a running log for problems I encounter and their solutions.

LXDE under Ubuntu 13.04

On Ubuntu 13.04 I have not been able to log in and use the LXDE desktop environment in the normal manner. The LXDM (Lightwaight X11 Display Manager) did show the login screen and I was able to log in, but got a blank (or blue) screen after that. Writing “ps aux” showed that the [PreLogin] process was stuck on <defunct>. starting lxde manually with startlxde did work fine. The only solution I have found to this so far is instead installing lightdm. Should be as simple as:

sudo apt-get install lightdm lightdm-greeter-example-gtk

The lightDM display manager might be a bit big. An alternative is the Gnome Display Manager (GDM).

Unable to log in via SSH 

I’ve had a lot of trouble with logging in via SSH. One of the reasons is that the dropbear RSA key is corrupted. I think it might be related to having two BBBs.. From this thread on the beagleboard.org google group:

rm /etc/dropbear/dropbear_rsa_host_key
dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key

I’ve also had trouble with avahi-daemon.service active up and stealing all the resources. This can be seen by writing “top” and seeing that systemd takes up all the resources. To mask the avahi-daemon:

systemctl mask avahi-daemon.service

I have no idea what the consequences are, but this fixed the problem for me at least..

Rotate the screen
rotate
To rotate the screen (or change the orientation of the monitor if you will), add a couple of lines to the file

/etc/X11/xorg.conf:

Driver "fbdev"
Option "Rotate" "CCW"

This goes in the section “Device”. The driver replaces the “modesetting”-driver.
CCW stands for counter clock wise.

This only works for X11, so if you want to rotate the framebuffer, add this to the kernel command line:

fbcon=rotate:3

 Device tree compiler on Ubuntu 13.04

If you are getting the error:

dtc: invalid option — ‘@’

Robert C Nelson has a solution:

http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Upgradedistro”device-tree-compiler”package

wget -c https://raw.github.com/RobertCNelson/tools/master/pkgs/dtc.sh
chmod +x dtc.sh
./dtc.sh

For some reason ‘which dtc’ did point to /usr/local/bin/dtc, but I still had to specify the whole path. Weird..

Unable to configure bonescript

This is the error message:

Job for bonescript.socket failed. See ‘systemctl status bonescript.socket’ and ‘journalctl -xn’ for details.

I noticed that the job was unable to start since there was already a version running. The solution was to kill the running instance:

ps aux | grep server.js

find the pid and run:

kill -9

Then try to start:

systemctl start bonescript.socket

This is probably not a permanent solution, but it worked for installing tslib that for some reason wanted to configure bonescript..

Dallas one-wire temperature reading on BeagleBone Black with dto

w1

OK, this was very straight forward with the help of Koen’s blog and the BeagleBoard google group.

The Dallas one-wire protocol is pretty straight forward, at least when there is already a Linux driver for it.  A 18B20 was mounted with the data pin in P9.22, the same as on the new revision of Replicape but can be any GPIO pin. The reason for having an extra temperature sensor is so that the cold end can be monitored. On all metal hot-ends, the temperature needs to stay below the glass transition temperature, so it’s a good idea to keep an eye on it. The 18B20 goes up to 125 degrees celsius and should be perfect for this.

On your BeagleBone (Black), try this:

nano BB-W1-00A0.dts

Copy-paste this:

/dts-v1/;
/plugin/;

/ {
	compatible = "ti,beaglebone", "ti,beaglebone-black";

	part-number = "BB-W1";
	version = "00A0";

	/* state the resources this cape uses */
	exclusive-use =
		/* the pin header uses */
		"P9.22",
		/* the hardware IP uses */
		"gpio0_2";

	fragment@0 {
               target = <&am33xx_pinmux>;
               __overlay__ {
					dallas_w1_pins: pinmux_dallas_w1_pins {
						pinctrl-single,pins = < 							0x150 0x37 						>;
					};
               };
	};

	fragment@1 {
               target = <&ocp>;
               __overlay__ {
		       onewire@0 {
			       compatible      = "w1-gpio";
			       pinctrl-names   = "default";
			       pinctrl-0       = <&dallas_w1_pins>;
			       status          = "okay";

			       gpios = <&gpio1 2 0>;
		       };
         };
	};
};

Compile it:

dtc -O dtb -o BB-W1-00A0.dtbo -b 0 -@ BB-W1-00A0.dts

Copy it:

cp BB-W1-00A0.dtbo /lib/firmware/

Enable it:

echo BB-W1:00A0 > /sys/devices/bone_capemgr.9/slots

Test it:

python

Copy-paste this on the command-line:

import time

w1="/sys/bus/w1/devices/28-000002e34b73/w1_slave"

while True:
    raw = open(w1, "r").read()
    print "Temperature is "+str(float(raw.split("t=")[-1])/1000)+" degrees"
    time.sleep(1)

You should see something like this:

Temperature is 32.375 degrees
Temperature is 32.437 degrees
Temperature is 32.437 degrees
Temperature is 32.5 degrees
Temperature is 32.562 degrees

And that is how hot it is on a Saturday night on Oslo when the CTO of the company we share office space with insists on having the severs in-house :)

To avoid any confusion, you should probably point out that the 000002e34b73 part of/sys/bus/w1/devices/28-000002e34b73/ depends on the unique ID of the temperature sensor, so everyone will have to adjust it before running your example script.

-n.st

 

Update January 21. 2013: Also, please note that there are two different versions of the Dallas W1 temperature device. One works fine (Marking: 18B20) with the latest Linux W1-gpio driver. The other (Marking: 18B20P) only spits out 85 deg.

Capture input events via GPIO on BeagleBone black

Beaglebone black gpio input from Elias Bakken on Vimeo.

If you want to listen to button presses or monitor switches on BeagleBone, the best way is not to poll the pins as some have suggested, but instead use the gpio_keys driver to generate an event when a switch changes state, either closes or opens. That way you do not spend any resources checking if something has happened and you also get an event the instance it happens. As an example, I’ll use the Replicape which has six end-stops one for each of the extremes of the three axes x1, x2, y1. y2, z1, z2. If an axis goes beyond it’s normal travel range for any reason, the system should pick this up so the physical equipment is not damaged. It can also be used for automatic calibration and centring of the print head.

To setup a system of six pins configured as inputs, try the following:
Start nano:

nano BB-GPIO-KEYS-00A0.dts

And then copy-paste this:

/dts-v1/;
/plugin/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* identification */
    part-number = "BB-GPIO-KEYS";
    version = "00A0";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            end_stop_pins: pinmux_end_stop_pins{
                pinctrl-single,pins = <
                    0x090 0x37 // P8_7  = End stop X1  = GPIO2_2
                    0x070 0x37 // P9_11 = End stop Y1  = GPIO0_30
                    0x074 0x37 // P9_13 = End stop Z1  = GPIO0_31
                    0x158 0x37 // P9_18 = End stop Z2  = GPIO0_4
                    0x1AC 0x37 // P9_25 = End stop Y2  = GPIO3_21
                    0x180 0x37 // P9_26 = End stop X2  = GPIO0_14
                >;
            };
        };
    };

    fragment@1 {
        target = <&ocp>;
        __overlay__ {            
            #address-cells = <1>;
            #size-cells = <1>;                            

            gpio_keys {
                compatible = "gpio-keys";
                pinctrl-names = "default";
                pinctrl-0 = <&end_stop_pins>;
                #address-cells = <1>;
                #size-cells = <0>;

                switch_x1 {
                    label = "End-stop-X1";
                    debounce_interval = <50>;
                    linux,code = <1>;
                    gpios = <&gpio3 2 0x5>;
                    gpio-key,wakeup;
                };                
                switch_x2 {
                    label = "End-stop-X2";
                    debounce_interval = <50>;
                    linux,code = <2>;
                    gpios = <&gpio1 14 0x5>;
                    gpio-key,wakeup;
                };
                switch_y1 {
                    label = "End-stop-Y1";
                    debounce_interval = <50>;
                    linux,code = <3>;
                    gpios = <&gpio1 30 0x5>;
                    gpio-key,wakeup;
                };                
                switch_y2 {
                    label = "End-stop-Y2";
                    debounce_interval = <50>;
                    linux,code = <4>;
                    gpios = <&gpio4 21 0x5>;
                    gpio-key,wakeup;
                };                
                switch_z1 {
                    label = "End-stop-Z1";
                    debounce_interval = <50>;
                    linux,code = <5>;
                    gpios = <&gpio1 31 0x5>;
                    gpio-key,wakeup;
                };                
                switch_z2 {
                    label = "End-stop-Z2";
                    debounce_interval = <50>;
                    linux,code = <6>;
                    gpios = <&gpio1 4 0x5>;
                    gpio-key,wakeup;
                };                
            };
        };
    };
};

Most of this should be familiar if you know about device tree overlays. The important thing is the gpio_keys node. Notice the “gpio-keys” compatible directive. This matches the compatible field in the kernel file “drivers/input/keyboard/gpiuo_keys.c” for those who need a point of reference.. For each switch you have, add a new node as seen above. Each switch or button needs a label, an optional debounce interval that will keep the switch from reporting multiple events due to bouncing. The default is 5 ms.

The linux code is the code that gets reported in the event.
The gpios is the bank and pin number. Look in the SRM to find out the right one for the pins you want. Again, there is a gottcha here since the bank number is one more than what’s in the SRM. Look in the above overlay and you will figure it out.
The last argument in the gpio-field of each button is the “flags”. I’ve not found any documentation for this, but is seems bit two is direction and bit one is pullup, so 0×4 + 0×1 = 0×5 is input, pullup. The “gpio-key, wakeup” I think is whether or not linux will go out of sleep mode if an event happens.

Compile it:

dtc -O dtb -o BB-GPIO-KEYS-00A0.dtbo -b 0 -@ BB-GPIO-KEYS-00A0.dts

Move it:

cp BB-GPIO-KEYS-00A0.dtbo /lib/firmware/

Enable it:

echo BB-GPIO-KEYS:00A0 > /sys/devices/bone_capemgr.*/slots

Look for errors:

dmesg

You should now have a new event device file in /dev/input/event1.

A simple way to check that it’s working is to cat the file:

cat /dev/input/event1

And then close the switch. If you see a bunch of digital garble, it’s working as expected :)

If you want a more elaborate scheme, here is a python script that should work:

nano switch_test.py

Input this stuff:

evt_file = open("/dev/input/event1", "rb")
while True:
    evt = evt_file.read(16) # Read the event
    evt_file.read(16)       # Discard the debounce event 
    code = ord(evt[10])
    direction  = "down" if ord(evt[12]) else "up"
    print "Switch "+str(code)+" "+direction

Start the program:

python switch_test.py

And the toggle the switch. You should see something like this:

root@beaglebone:~# python switch_test.py
Switch 2 down
Switch 2 up
Switch 2 down
Switch 2 up
Switch 2 down
Switch 2 up
Switch 2 down
Switch 2 up

For further reading, Derrek Molloy has a great (very extensive) video explaining how to do polled input and output: http://www.youtube.com/watch?v=wui_wU1AeQc