direct control of I/O pins

is there a way to directly talk to (read and write) the I/O pins using assembly language or C/C++ using static addresses?

it sounds like there is a way to talk to the I/O pins with system calls, but the system calls sound like they are hideously slow (much slower than 1 usec.)



I am a newbee and have not come close to venturing there, but I understand there is a “PRU” module in the processor that can drive the IO pins directly if the pin-mux is set correctly. The PRU has it’s own assembly language and is the FAST way to go.

There is some stuff here:

You just have to mmap the appropriate chunk of /dev/mem and you can
bang on the GPIO control registers directly from C (or python, or

Things to watch out for:

* You need write permissions for /dev/mem

* You have to load an appropriate device tree overlay to control the
pin multiplexing

* You need to insure the GPIO blocks are powered up and enabled, with
an appropriate clock routed to them. The easiest way to do this is to
make sure you export at least one GPIO pin from the bank you want to use.

* I recommend you use the set and clear registers to twiddle bits, so
you only affect the bit(s) you're trying to control. That gets around
having to use read-modify-write updates with the corresponding
critical sections (or occasionally flaky behavior)

There are working examples of this all in my Debian + LinuxCNC
MachineKit image, including PRU code that writes to both system GPIO
and PRU dedicated I/O lines if you want to dig into that (not
necessary for what you're wanting). The image is available here:

...and the LinuxCNC code is here:;a=shortlog;h=refs/heads/MachineKit

...with the specific BeagleBone GPIO driver code in this file:;a=blob;f=src/hal/drivers/hal_bb_gpio.c;h=eec6496e77ee78c3bbec344b6f8f6969751c73a8;hb=refs/heads/MachineKit

Once the system is up and running, all GPIO access is done using
direct memory reads and writes, as it is not possible to call Linux
system functions from inside the xenomai real-time domain without
loosing hard real-time performance.

- --
Charles Steinkuehler