Interupts using GPIO pins implemented with librobotcontrol on Blue

General Discussion
,
1

I am trying to configure a GPIO pin to increment an counter every time the signal goes high. Is there a way of doing this using the librobot control from StrawsonDesign : Robot Control Library: Main Page or another C library

2

Hello,

First off, I am not fresh on the BBBlue recently like I used to be during 2018. Secondly, I know there is a way with C but not with the BBBlue, i.e. I think.

The BBBlue uses specific drivers and I am currently unaware of the GPIO access on the BBBlue. If you can access GPIO on the BBBlue, yes. C/C++ can be used.

Now, if you want me to research things for you, I can. I just need to know somethings first.

  1. Can you access GPIO on the BBBlue?
  2. If you can access GPIO on the BBBlue, where are they found in the kernel or Linux filesystem?

After you make me understand the GPIO whereabouts, I can then try to produce something in the form of C format for utilizing it for armhf.

Seth

P.S. I understand that you want to use the signal at High and when it turns High and not just on/off. So, bear with me while I research the C GPIO ideas after you so kindly answer the 1. and 2. from above.

I mean, I know too little about the Robot Control Library, although it is nifty, to say yay or nay on it for use with getting data on High instead of just on/off. Some resources:

  1. https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt
  2. https://www.kernel.org/doc/Documentation/gpio/gpio.txt

So, the rise to High is when the data needs to be incremented. Okay…

We need to figure out in the device tree how to appropriate these calls to rise and fall or just rise in this case. Depending on the newer GPIO “table” of ideas, libgpiod-dev can be used with calling something like this for the preprocessors:

#include <gpiod.h>
#include <stdio.h>
#include <unistd.h>

...

I have been researching this idea for some time at different intervals in time. Now although I do not know everything, I am sure it can be done with C formatted files for armhf.

3

Rise and Fall interruptions…

Here: libgpiod-example/libgpiod-event/main.c at master · starnight/libgpiod-example · GitHub

Libgpiod-dev is what needs to be installed via apt and maybe gpiod for python3 if you go that route.

So, if accessible and available, use that link with commanding the lines:

  1. gpioinfo
  2. If gpioinfo does not work, it is not installed.
  3. sudo apt install gpiod libgpiod-dev

Seth

4

Events…

So, I am mistaken sort of here for telling you it is possible. I am not sure what you DTS looks like as of now.

So, without the DTS of the GPIO(s) in question with a phandle for it and it not being documented in the device tree for the machine in question, no go.

Now, can we alter the uEnv.txt file beagleboard.org has made available? Yes. Can we use the lack of cape-universal, yes.

how? How can we still use GPIO(s) in this context. C is one way but the rules apply. The device bindings for the machine need to be documented. I always thought the BBBlue had no such documentation on this effort.

How far can we go with this in mind? Long ways in my mind but personally never thought it was worthwhile because of my lack of understanding in 2018.

The two links provided will tell you everything that is needed. They will not describe how to do it. That is more for the device-tree people to tell us how to manipulate and document the phandle(s) and other ideas.

Seth

P.S. If we take this on, I can help and sometimes I will be wrong or misinformed. I rarely get upset and I can stick with it. I always to this day wanted to make GPIO work with events myself and not rely on libraries or others outside of the kernel and device-tree-source.

So, it can be reality or a faded glimpse. Your choice. By no means am I easy to work with currently but I kind of think since I have two or three BBBlue boards, I can test myself and see about making it work.