GPIO quadrature encoder max count does not reach 10Khz

Started by rirazvan, March 14, 2015, 10:48:08 PM

Previous topic - Next topic

rirazvan

Hello,

I am testing a setup to read a quadrature encoder, 3600PPR, A, B channel and a trigger signal on GPIO.
The maximum correct count freq is around 10Khz on GPIO2 . At 15khz there are so many drop pulses that the count is useless.

I did test both A20 micro and Lime2.

Is my setup somehow wrong or there is a limitation in GPIO count speed?
What is the max speed that GPIO is able to handle on A20?
Is three a way to increase the GPIO speed rate?

Thank you

MBR

What kind of GPIO access did you use? The standard file-based way via the /sys entries or the direct access to the ports via the mmap()ed MMIO? The second one is much faster, although more complicated, see https://www.olimex.com/forum/index.php?topic=436.0.


rirazvan

I did it via the /sys using olimex GPIO code.
As far as I read on the forum the counting rate would be higher.

Maybe the GPIO pins that I use are assigned to another job. How would I check that?
The .fex file seem to be correct and the pin is assigned once.

I see that usage of mmap force takes the cpu  at @100%CPU. This will affect the other part of my application.

I did try also to use an I2C ADC, ADC101C021 ~189Ks/S  to measure a fast voltage drop and I was unable to reach fast and high speed of I2C TWI0 bus for the ADC.

I there another way to do a quadrature high speed pulse counting o A20? An USB CY7C68013A-56PVXC would be handled by A20 in real time counting?

Razvan

MBR

Quote from: rirazvan on March 15, 2015, 12:13:43 PM
I see that usage of mmap force takes the cpu  at @100%CPU. This will affect the other part of my application.

mmap()ing the /dev/mem to MMIO space just allow the aplication to access the MMIOs directly. This means that the application can read/write them as fast as posible, without any system/driver/library/whatever overhead. But this also means that without any timing/sleeping the read loop will take all the available time, resulting in CPU load at 100%. So you will need either some kind of hi-resolution timer or to insert delays (probably usleep()) into the read loop/thread.