Thanks, Dennis, for the detailed response! [headsmack] to myself for missing the "GPIO_DATAIN Register" section in the Sitara docs.
This is what has been concerning me about the file reading approach: > it may also be that for the duration the "file" is open, others may be > blocked But then again for my application I only need to poll the files' status every 2-3 seconds or so -- nothing high bandwidth at all. > Are A/B/C and M (master) truly independent? Yes -- they are all separate programs kicked off at boot time by their own crontabs -- M is the only program that has to see all the pins -- A, B, and C don't need to know or care about each other. Regarding the master program M, I still want to keep A, B, and C independent and ignorant of each other, but I really like your idea of a "status queue" + monitoring and ack mechanism for A, B, and C themselves. Great food for thought, and thanks again for the detailed post and suggestions!!! Joe On Sat, Jun 3, 2017 at 5:58 AM, Dennis Lee Bieber <[email protected]> wrote: > On Thu, 1 Jun 2017 20:46:43 -0700 (PDT), > [email protected] 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). > -- > Wulfraed Dennis Lee Bieber AF6VN > [email protected] HTTP://wlfraed.home.netcom.com/ > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the Google > Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/RCQkMm5ysFs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/naa5jcphvesuvuf4pckn538r8ho2o47oj9%404ax.com. > For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAEEhCymG72g93_tF5vWF4J03DAYFXMN8DxY0bWDFirLFfg1Wgw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
