BBB poll() function - Edge Detection Latency

GoogleGroups
1

Anybody tried using the poll() function for GPIO edge detection with BBB ? It works, but appears to have latency with interrupt generation. Same code works fine on original BB. I’m using GPIO0_22 with Robert C Nelson Ubuntu image. Also tried GPIO0_22 with same results. Times between edges using fixed freq square waves at 1 Hz vary as much as 15 mSec.

Thanks,

Tim

2

Ubuntu is NOT a RTOS, so your timings may vary all over the place…

for that matter Linux is NOT a REAL TIME deterministic Kernel…Period.

Tom

3

Works pretty well perfect on BB with 3.2 kernel and exact same code and hardware latchup . I’m not looking for “real-time”, but 15 mSec error in 1 sec is further off than it should be.

4

Small typo correction to previous posts - not in front of it right now, but error is actually 150 mSec. Will verify tomorrow.

5

What parameters are you using with Poll? The kernel docs recommend that you use a couple of specific settings:

From the docs:

GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42)
and have the following read/write attributes:

    /sys/class/gpio/gpioN/

	"direction" ... reads as either "in" or "out".  This value may
		normally be written.  Writing as "out" defaults to
		initializing the value as low.  To ensure glitch free
		operation, values "low" and "high" may be written to
		configure the GPIO as an output with that initial value.

		Note that this attribute *will not exist* if the kernel
		doesn't support changing the direction of a GPIO, or
		it was exported by kernel code that didn't explicitly
		allow userspace to reconfigure this GPIO's direction.

	"value" ... reads as either 0 (low) or 1 (high).  If the GPIO
		is configured as an output, this value may be written;
		any nonzero value is treated as high.

		If the pin can be configured as interrupt-generating interrupt
		and if it has been configured to generate interrupts (see the
		description of "edge"), you can poll(2) on that file and
		poll(2) will return whenever the interrupt was triggered. If
		you use poll(2), set the events __*POLLPRI and POLLERR*__. If you
		use select(2), set the file descriptor in exceptfds. After
		poll(2) returns, either lseek(2) to the beginning of the sysfs
		file and read the new value or close the file and re-open it
		to read the value.
6

Hi Jason,

I am pretty sure that I am setting things up properly (direction=input, edge=falling, POLLPRI event, etc.). Has been working great for months on original BB.

Again the edge detection is working with the BBB, just the timing between the edges are jumping around. With the same code on the BB white I get very steady values. I did another test this morning where I measured the time between edges for 20 pulses at 1 Hz. The frequency generator that I use is a little “touchy” so I can’t dial in exactly 1.0 Hz, but the values should be close and more importantly consistent.

The link below contains the output from 5 tests on BB, followed by same 5 tests with BBB on same pin. Weird thing with BBB is that it seems to try to make up for the errors - if you are over by 100 mSec, you may be under by 100 mSec on the next. When you add up all the errors - they almost cancel each other out.

Here is the output from the tests.

http://pastebin.com/iTTV2Z8B

Thanks,

Tim

7

I’m very new to BB’s so I don’t have any experience to draw upon, but if i had to guess, there was likely a scheduler algorithm change in the kernel between the BB White and the BB Black. Either that are there’s still some timing bugs to be worked out on the new GPIO stuff.