bbb gpio

TI gpio driver documentation is here

An easy to use website to retrieve the gpio pin numbers is available here

io access is implemented in the kernel as sysfs control: /sys/class/gpio

Pinning:

Name	Cape Pin	TI AM355x PIN	Linux GPIO	Remark
Relay 1	P8.8	GPIO 2_3	67
Relay 2	P8.10	GPIO 2_4	68
Pulse counter 0	P8.16	GPIO 1_14	46
Pulse counter 1	P8.22	GPIO 1_5	37
Pulse counter 2	P8.24	GPIO 1_1	33
Pulse counter 3	P8.18	GPIO 2_1	65
Pulse counter 4	P8.20	GPIO 1_31	63
MK3_RST	P8.39	GPIO 2_12	76
VE.Bus Standby	P8.43	GPIO 2_8	72
Buzzer	P9.14	GPIO1_18/PWMA

Example of toggling relay 1 from the command line:

echo 68 > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio68/direction
echo 1 > /sys/class/gpio/gpio68/value
echo 0 > /sys/class/gpio/gpio68/value

And finally unexport the gpio pin to release it back to driver control in case you'd want that:

echo 68 > /sys/class/gpio/unexport

Pulse counting

The pulse inputs are not connected to actual pulse counters on the bbb / AM3558. They are connected to general GPIO pins, and need to be polled.

Here's the results from a simple C program accessing the gpio under sysfs. Going through a list of 10 gpio pins (P8.27 - P8.36), but it could be a list of any size. The results are reported per each gpio read.

Here it is with no delay between polls. As expected the load is high.

root@bbb:~/poll-gpio# ./poll-gpio

Elapsed   : 160.958 seconds
Poll Count: 1000000
Rate      : 6212.81 polls/sec

root@bbb:~/poll-gpio# uptime
 11:49:57 up 18 min,  2 users,  load average: 0.96, 0.48, 0.21

Here is the same loop with a 48 ms pause after each 10 reads (e.g. each time through the list).

root@bbb:~/poll-gpio# ./poll-gpio 48
^C
Elapsed   : 338.314 seconds
Poll Count: 68080
Rate      : 201.23 polls/sec

root@bbb:~/poll-gpio# uptime
 12:19:56 up 48 min,  2 users,  load average: 0.00, 0.04, 0.06

200 polls/sec with 10 pins gives the 20 Hz for each pin.

I didn't measure for time variations between individual reads, but I think there is enough slack that there wouldn't be anything to care about.

And a trivial kernel driver would still make this even more efficient if that's ever needed.