3

I'm using a C++ library (easyBlack) to handle GPIO through /dev/mem.

As I have seen in the chapter "25.3.3 Interrupt Features" of "AM335x SitaraTM Processors - Technical Reference Manual"

In order to generate an interrupt request to a host processor upon a defined event (level or logic transition) occurring on a GPIO pin, the GPIO configuration registers have to be programmed as follows:

• Interrupts for the GPIO channel must be enabled in the GPIO_IRQSTATUS_SET_0 and/or GPIO_IRQSTATUS_SET_1 registers.

• The expected event(s) on input GPIO to trigger the interrupt request has to be selected in the GPIO_LEVELDETECT0, GPIO_LEVELDETECT1, GPIO_RISINGDETECT, and GPIO_FALLINGDETECT registers.

Until there all right, but all the documentation I can find is based using linux kernel header files ("linux/gpio.h" and "linux/interrupt.h"), and it seems that can not be used for user space programs, only in modules. Or examples that use the kernel drivers and watches a state file in the sysfs to implement the interrupt. That may work, but is slow and need a lot of resources.

Is there any other alternative other than to work with multi-thread to see if changing the values of the desired pins? (How does this other library - github.com/jackmitch/libsoc)

Maybe compile easyBlack as a kernel module?

Thanks!

Manuel Egío
  • 173
  • 1
  • 9

1 Answers1

1

Unfortunately, true Interrupts are impossible to get in Userspace. This is why all interrupt dependent code is written in either a kernel module or the kernel itself. Typically this is OK though. An ISR should by design be as fast as possible and leave actual processing to be scheduled at a later time. This is similar to what you mentioned above with the statefile in sysfs. For you however, it looks like the easyBlack library supports memory mapping the GPIO memory space into userspace, and then allowing you to poll the status of the pin. The examples that are shown, would be extremely processing intensive since there are no sleeps in the main while loop. This means that the process will take up as much of the cpu time as the scheduler will allow.

Since the Beaglebone is running an embedded Linux Kernel, I am assuming the a libGPIO driver has been written to support the GPIOs. LibGPIO is a framework within the linux kernel that abstracts away some of the gory details of different GPIO devices and presents, a standard interface. Try looking in the directory /sys/class/gpio. This should provide you with either a list of GPIO's or GPIO Chips.

Here is the GPIOsysfs documentation https://www.kernel.org/doc/Documentation/gpio/sysfs.txt

Your Userspace software can open the 'value' file of the coresponding GPIO, and can the use the 'poll' function on that filedescriptor. This will allow your software to block until the GPIO has changed, and then act accordingly, thus giving you a pseudo Interrupt capability in userspace.

whh4000
  • 905
  • 1
  • 12
  • 30