This post provides supplementary information to the video that I have just posted on using GPIOs with the Beaglebone Black.

The Video

In this video I am going to continue my series on the Beaglebone by demonstrating how to use its GPIOs for both input and output applications. In this video I will wire simple input and output circuits that are attached to two GPIOs – one that lights an LED and the other that receives a button input. I covered this topic below before in a previous video. I am updating it here because there have been significant changes to the Linux kernel. This video will cover the Linux device tree for ARM embedded systems and explain how you can create custom device tree overlays to configure the GPIOs for your applications at run time from within the Linux userspace. I will explain the use of internal and external pullup and pulldown resistors and I will make available and describe a set of C++ code examples for reading and writing to the Beaglebone’s GPIOs. I have also built a set of PDF tables that aggregate the information that you need and make it easier to configure GPIOs on your Beaglebone’s P8 and P9 headers.

The code for this video is available by typing:

The information below is covered in the video, but here it is just in case you need to get a text view:

Getting started

We can get some information about the pins in use:

We can also get information about which pins are in use (allocated):

And a full list of the pins:

Setting up the Circuit

Using the same circuit as in my old video. Since each GPIO module provides 32 dedicated GPIOs (general purpose input/output) and the GPIOs support 4 banks of 32 GPIOs (so, 128 GPIOs in total) the naming of GPIO0_5, would be GPIO 5 as (0 x32 + 5 = 5)

(Pin  12 on the P9 Header) GPIO1_28 – The LED  = 1 x 32 + 28 = GPIO 60 (Offset 0x078, P9-12 GPIO1_28) #88

NOTE: GPIO 60 is not PIN 60!!!

If we check pins again and search for pin 60, by using the offset we can see:

The pin mode on pin 30 is 30 HEX. What does that mean?

Well to understand this you need the document to beat all documents – the AM3359 Technical Reference Manual. http://www.ti.com/product/am3359 and you can see the link for this document. The version I am using is called the “AM335x ARM Cortex-A8 Microprocessors (MPUs) Technical Reference Manual (Rev.H). It is a 18.5MB document with 4,727 pages (no typo there – 4,700 pages!). The current direct link is: http://www.ti.com/lit/ug/spruh73j/spruh73j.pdf

The GPIOs section is Chapter 25 and begins on page 4,056. The page I am most interested in is Page 815, Section 9.3.51. You can search the PDF for “conf_<module>” if you are using a different version of the document.

The value: 0x30 Hex is 110000 in Binary, so what does that mean?

Well, you have to see the table:

Bit Field Reset Description
6 conf_<module>_<pin>_slewctrl X Slew Control. Slew Rate: Fast is 0, Slow is 1
5 conf_<module>_<pin>_rxactive 1h Receiver Active. Input Enable: Receiver Disable 0, Receiver Enable 1
4 conf_<module>_<pin>_putypesel X Pad Pullup/Pulldown Type. Pulldown is 0, Pullup is 1
3 conf_<module>_<pin>_puden X Pad Pullup/Pulldown enable. Enabled is 0, Disabled is 1
2-0 conf_<module>_<pin>_mmode X Mode. Pad functional mux select. A number between 0 and 7 i.e. 000 and 111. This depends on which mode we require.

Well if you look at this table, you see that 0x30 means the slew rate is fast, the receiver is enabled, the pad is set for pullup and pullup is enabled. The Mode is 0. which means when you look a the table for this pin on the P9 header (Table 8. Expansion Header P9 Pinout), you see that pin is set as:

Beaglebone P9 Header, Pin 12, Mode 0 is gpmc_be1n, we would like to set it to Mode 7, which is gpio1[28] (Note the LED is currently on).

27 means 100111 = Fast, Enable Receiver, Pulldown type, enabled, mux mode 7.

37 means 110111 = Fast, Enable Receiver, Pullup type, enabled, mux mode 7.

Be careful, not all pins work in this way and there are external resistors on the board that affect the behaviour. For example, pins GPIO2_6 to GPIO2_14 all have external 42.2k resistors to GND and 100k resistors to high.

We can export the pins by echoing the GPIO number to /sys/class/gpio/export

Light goes on and off.

The Beaglebone Black System Reference Manual (SRM) is available at: http://circuitco.com/support/index.php?title=BeagleBoneBlack

Page 65 of the SRM has the table that you need to map the GPIO to the Offset!

GPIO1_28 maps to P9-12 with an offset of 160 (pin 88 44e10960)

Setup for Device Tree Overlays

https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md

As is described in this guide:

We now have $SLOTS and $PINS that we can echo

But we can also cat these values, for example cat $SLOTS:

Just so that I always have these environment variables I am adding them to my .profile. So my ~/.profile looks like this:

Which includes the environment variable to set up the certs to fix the configuration issue for curl as discussed here: Git and Curl SSL Certificates Configuration on Beaglebone Black

If we wish to set these values now, without typing them twice we can use the ‘.’ so:

And you can see that the variables have been set.

Using an Overlay

Overlays allow the initial device tree that was described at boot to be modified in userspace at run time. This is useful as we are able to enable any device without having to recompile the kernel and/or reboot. When you enable output using the pinmux settings, you’re only enabling the output driver circuitry at the pin. When you change the mux, you’re selecting which internal signal gets connected to this pins output driver. So, the pin mux (physical pin) is completely separate from the gpio block (internal signal). You have to enable both.

In this overlay example I am using the bone-pinmux-helper to enable the pins. The GPIO is treated as a separate peripheral, just like all other peripherals.

Now, note when you echo DM-GPIO-Test > $SLOTS, make sure that you don’t pass DM-GPIO-Test-00A0.dtbo

Checking the pins (for example, pins 88 and 85):

1020 is a20 – remember that it is in hexadecimal.

Now if we type dmesg, we can see the impact of this operation:

Now we can work with the GPIOs directly:

All is in order.

The C++ Code

All of the C++ code is available in the gpio directory of the github repository. The description of this code and its use can be found in the video.

Citation

If you use this video in your research, please cite:

Molloy, D. [DerekMolloyDCU]. (2012, May, 3). Beaglebone: GPIO Programming on ARM Embedded Linux [Video file]. Retrieved from http://www.youtube.com/watch?v=SaIpz0…

Further Reading:

Understanding the GPIOs: https://www.kernel.org/doc/Documentation/gpio/gpio.txt

Understanding Overlays: https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md

Understanding the Device Tree: http://devicetree.org/Device_Tree_Usage