On Thu, 1 Jun 2017 20:46:43 -0700 (PDT),
jhupcey@gmail.com declaimed the following:
Hello!
On a Beagle Bone Black Rev C is there a digital GPIO status register where
I can simply read the [digital] status of all the GPIOs?
There is a register for each GPIO bank (actually, a slew of registers
for each bank), but "simply read" may not be the case. {Further info below}
Is there a way for two or more separate programs to read-only monitor the
same digital GPIO pin at the exact same time?
The sys filesystem approach is to open/(read|write)/close the "file"
associated with each individual GPIO pin. I haven't experimented to see if
one can hold the "file" open and rewind (seek 0)/reread to get updates, or
must do the close/open stuff for each read. For a polling loop, that may be
a lot of OS overhead -- it may also be that for the duration the "file" is
open, others may be blocked (unless it can be opened in a shared read-only
mode without blocking the OS from updating the status).
Last time I looked, this is the method used by the BBIO Python
libraries.
I've looked through the PDF on the Sitara processor, every doc & book on
the BBB I could find, and through this board, and I have had no luck
finding reference to such an animal. I'm posting here since someone may
have discovered an "undocumented feature" like this.
Unless I have the wrong document (AM335x and AMIC110 Sitara™ Processors
Technical Reference Manual; Literature Number: SPRUH73P October
2011–Revised March 2017) what you are asking for is in Chapter 25. The
registers are listed in table 25.5 (as offsets -- I haven't found where the
banks are located yet). You probably want GPIO_DATAIN.
"""
25.4.1.17 GPIO_DATAIN Register (offset = 138h) [reset = 0h]
GPIO_DATAIN is shown in Figure 25-24 and described in Table 25-22.
The GPIO_DATAIN register is used to register the data that is read from the
GPIO pins. The GPIO_DATAIN register is a read-only register. The input data
is sampled synchronously with the interface clock and then captured in the
GPIO_DATAIN register synchronously with the interface clock. So, after
changing, GPIO pin levels are captured into this register after two
interface clock cycles (the required cycles to synchronize and to write the
data). When the AUTOIDLE bit in the system configuration register
(GPIO_SYSCONFIG) is set, the GPIO_DATAIN read command has a 3 OCP cycle
latency due to the data in sample gating mechanism. When the AUTOIDLE bit
is not set, the GPIO_DATAIN read command has a 2 OCP cycle latency.
"""
Ah... Chapter 2 "Memory Map", with some digging, gives the base
addresses for the GPIO banks (GPIO0 is in a different table from the other
three -- as it is "wake-up" event capable).
Getting access to the banks likely involves mmap operations, and that
may require running as root (granted, without doing some games to give user
accounts privileges in the sys filesystem, even the simple open/read/close
stuff requires root -- I believe work is being done to make GPIO, if not
the rest of the peripherals, accessible to user accounts).
Of course, mapping bank/register/bit to each external GPIO is left as
an exercise...
Back story:
<SNIP>
More specifically, my use case example is: independent programs A, B, and C
each monitor a own GPIO and perform different actions upon the respective
dry contact closure; in parallel a master program scans the status of all
the GPIOs at once to do it's own series of actions and reporting.
Are A/B/C and M (master) truly independent?
If A/B/C can be started by M via multiprocessing (if the processing is
simple enough, and most of the time is spent in I/O, even plain Python
threading may suffice) you could have M do the polling of the GPIO pins,
collect the states, and forward a single packet to each of A/B/C using a
(multiprocessing) Queue (one queue for each process).
The only process that would need to read the pin states would thereby
be the master.
You could also use one queue, shared by A/B/C, to return
acknowledgements to M -- thereby gaining an ability to detect if one of the
processes has died or hung up somewhere (by lack of an acknowledgement
message after some period of time).