Configuring Pins Mode Beaglebone

Question

In the beagleboard or beaglebone are different modes to work the pin. With the previous kernel they are located in /sys/kernel/debug/omap_mux. Do u know with the last Kernel where are those files?

Answer 1

I found many of the examples provided at hipstercircuits to be a bit overwhelming; especially if you're just looking to adjust the pins to mode 7. If anyone reading this is having the same issue, the following link may help: http://bbbadventures.blogspot.ca/2013/06/pinmuxing.html It provides the most basic template.

Should the link above break, here's the snippet provided (with a few tweaks for clarity):

/*
* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/plugin/;

/ { compatible = "ti,beaglebone", "ti,beaglebone-black";
    /* identification */
    part-number = "pinctrl-test-0";
    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            pinctrl_test: pinctrl_test_0_pins {
                pinctrl-single,pins = <
                    0x030 0x07 /* P8_12 OUTPUT | MODE7 */
                    0x034 0x07 /* P8_11 OUTPUT | MODE7 */
                    /* Add more pins here */
                >;
            };
        };
    };

    fragment@1 {
        target = <&ocp>;
        __overlay__ {
            test_helper: helper {
                compatible = "bone-pinmux-helper";
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_test>;
                status = "okay";
            };
        };
    };
};

When adding more pins to the above snippet, you can use the following tables to identify which hex values match the pins:

• https://github.com/derekmolloy/boneDeviceTree/blob/master/docs/BeagleboneBlackP8HeaderTable.pdf?raw=true
• https://github.com/derekmolloy/boneDeviceTree/blob/master/docs/BeagleboneBlackP9HeaderTable.pdf?raw=true

Each pin is set by appending an additional entry into pinctrl-single,pins. The format looks like this:

[offset] [mode]

Example: 0x030 0x07

In the two tables linked above refer to the third column, entitled "ADDR/OFFSET", for the offset value.

I hope this helps :)

Edit: I should also mention that the answers provided by Martin and Don are both excellent should help cover the rest of the important details.

Answer 2

Don Branson's answer is a great introduction on how to read GPIO pins, but unfortunately it does not cover how you can change a pin's mode, e.g. from GPIO to SPI. This became more complicated with kernels 3.8.13 (?) and up. For a number of reasons, the kernel developers switched to the "device tree model".

As of now, the details on how to use the device-tree-models seem to be in flux, so I will only describe the general process. You start out by describing the pins that you want to interact with in a file called "device tree source". The pins and their modes are specified using hexadecimals numbers that you have to look up in the documentation of the processor.

You then compile this file using dtc into a "device tree binary" and place this binary into /lib/firmware. Finally, you enable the pin modes by echoing the name of the binary file (you can omit the .dtb extension) to /sys/devices/bone_capemgr.*/slots.

A very informative example is layed out in this great blogpost:

http://hipstercircuits.com/enable-spi-with-device-tree-on-beaglebone-black-copy-paste/

I will try to expand my answer as I learn more about this topic myself. Or maybe someone can suggest edits or hopefully even a more expansive answer of their own? The information that is currently available seems to be a bit sparse...

The best of luck to you!

Answer 3

I found what I needed here: http://www.armhf.com/index.php/using-beaglebone-black-gpios/.

I'm running kernel 3.8.13.

Based on that, I wrote this script:

#!/bin/bash

# http://www.armhf.com/index.php/using-beaglebone-black-gpios/
# pin 9:11, gpio0[30] - 0 + 30 = 30
echo 30 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio30/direction
cat /sys/class/gpio/gpio30/value

# 1=switch open; 0=switch closed
while [ 1 ] ; do cat /sys/class/gpio/gpio30/value ; sleep .5 ; done

When the pin is held low, the script displays 0, and 1 when high. I breadboarded a circuit based on http://www.digikey.com/us/en/techzone/microcontroller/resources/articles/protecting-inputs-in-digital-electronics.html.

The orange wires on the right side of the pic act as a switch.

My plan is to then take this and a door switch from a dead printer to make a freezer switch. Then I'll modify the script to email me when the freezer's been open for more than say, 10 minutes.

Edit:

Did some study and found more info on how to set pinmux, specifically with device tree overlays:

Okay, watched this, and learned a lot: http://www.youtube.com/watch?v=wui_wU1AeQc

Was able to finally get control over pinmux settings on the BBB with the device tree overlay below. The fragment@1 section is still magic to me, so at some point hopefully it'll make more sense. Nevertheless, at least I can detect closed switches on all for pins.

One critical piece was the chart in Derek's project here: https://github.com/derekmolloy/boneDeviceTree/tree/master/docs

/dts-v1/;
/plugin/;

/ {
        compatible = "ti,beaglebone", "ti,beaglebone-black";
        part-number = "mousetraps";
        version = "00A1";

        /* https://github.com/derekmolloy/boneDeviceTree/blob/master/docs/BeagleboneBlackP9HeaderTable.pdf */
        fragment@0{
                target = <&am33xx_pinmux>;
                __overlay__ {
                        mousetrap_pins: pinmux_mousetrap_pins {
                            pinctrl-single,pins = <
                                    0x070 0x2f /* P9_11 30 INPUT MODE7 none */
                                    0x074 0x2f /* P9_13 31 INPUT MODE7 none */
                                    0x040 0x2f /* P9_15 48 INPUT MODE7 none */
                                    0x15c 0x2f /* P9_17 05 INPUT MODE7 none */
                            >;
                        };
                };
        };

        fragment@1{
                target = <&ocp>;
                __overlay__ {
                        test_helper: helper {
                                compatible = "bone-pinmux-helper";
                                pinctrl-names = "default";
                                pinctrl-0 = <&mousetrap_pins>;
                                status = "okay";
                        };
                };
        };
};

Answer 4

Check out this set of device tree files: https://github.com/nomel/beaglebone/tree/master/gpio-header

It allows you to change the gpio mux mode on the fly.

I just tried them and they seem to work.

Answer 5

Writing device tree overlay files is hard and particularly annoying if you're trying to play around with the device, as opposed to releasing a product. The config-pin utility helps out.

It allows querying and setting the pins to any of the modes they allow. You'll still need a device tree overlay to allow the mode you want, but there is a cape that allows everything, so you don't need to worry about it; it's called cape-universal. config-pin uses the pin number on the connector as pin names. For example, to set the pin known as P8.11, pin 13, gpio45 and gpio1_13 (that's one pin) to mode 6, also known as pr1_pru0_pru_r30_15 (which set the pin to output, controlled by pru 0 through bit 15 in register 30), you would do:

# The first line only needs to be done once; it loads the cape overlay.
config-pin overlay cape-universal
config-pin P8.11 pruout

You can run config-pin without arguments for information on other options, used for querying pin options and state. The program can also be used to set the value (as opposed to the mode) of gpio pins.

Answer 6

As it was asked above I will explain the fragment@n magic...the "fragment@n", "target" and "overlay" nodes are specific to the device tree overlay loader which patches an existing Device Tree. These nodes do not end up in the final merged DT, they are just there to tell the overlay loader what to do.

Overlay files can have multiple "patches" to the tree so to speak. Each fragment@n just declares a new patch, the "target" specifies where in the device tree the patch will be copied into and the "overlay" is the contents of the patch. Contents are merged and existing nodes are replaced. Targets can use actual DT path syntax (nodes separated by /) or aliases which is used here (&ocp and &am33xx_pinmux). Aliases are set for important nodes in the DT already.

The "compatible", "part-number" and "version" at the top are also specific to overlays and typically used like filters to determine if an overlay is supported on current hardware. All overlay files have specific syntax up to the overlay node at which point the inner contents is plain old device tree syntax. Kernels may support Device Tree but not overlays in which case you might have to copy and paste fragments into a single DTS/DTB yourself.DT and DTO is a beautiful system for embedded systems and drivers but takes getting used to.