2

I have a problem using my raspberry pi 2 for applications that need low latency.

I wrote a c++ GPIO routine that reads a high resolution quadrature ttl encoder. It then updates a counter and adds it to a value being read by i2c channel from another thread. Then another GPIO pins create a quadrature ttl encoder output. To not lose any pulses I need at least a loop with 10 usec cycle time for encoder reading thread.

The program cycle time is less than 3 usec in 99.9% of the times. Only one out of 1000 time the cycle time becomes more than 2000 usec.

I think the os is running so many unnecessary tasks that I don't need. For instance I don't need graphics, desktop, networking, Bluetooth, USB or even keyboard or monitor. I tried to stop all the running services with no luck. Any help would be much appreciated.

Farzad Ahmadpour
  • 21
  • 2
  • By the way, i know the i2c channel is slow but the multi thread approach allows me to run the encoder loop without waiting for i2c channel. As soon as data is available in i2c register i just read it in encoder loop. – Farzad Ahmadpour Jun 23 '15 at 23:34
  • 1
    Could you explain the timing requirements? In particular do the results have to be obtained in "real-time" or can they be buffered for a ms or so? Are you trying to read a quadrature, add an I2C offset, and write the updated quadrature via the other gpios? Regardless of what you are trying the first thing to do is dedicate one or more cores to your program using isolcpus in /boot/config.txt and using task affinity to assign your program to those cores. Google. – joan Jun 24 '15 at 07:23
  • I think this would be another hope:https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=52393 – user32352 Jun 29 '15 at 22:11

1 Answers1

1

I need at least a loop with 10 usec cycle time

You won't be able to get that consistently with a userspace application on a non realtime OS. A multi-tasking OS simply does not work that way; even if you minimize the number of processes, you cannot guarantee sub millisecond latency -- in my experience (which is admittedly limited in this regard), the lowest granularity you can get consistently with the linux kernel is 10 ms. Although you might get much lower than that regularly, eventually it will be off.

I don't know whether you can do better than that in kernelspace. You might be able to work out a way to predictably do it for short time periods (like, 10 ms) but at some point you must be at the mercy of the scheduler.

You can build the kernel with options to minimize latency but even those refer to "the milliseconds range". There are true realtime linux kernels but they are a separate project and so combining them with the pi kernel, also a spin-off, is daunting. This Q&A discusses some possibilities.

Not really mentioned there is RISCOS -- or rather, it's mentioned in a comment but then someone points out it is not a realtime OS. Which is true, but it does use cooperative multi-tasking (CMT). I have never used RISCOS but I did have to read a bit about CMT systems in school (they were common up into the 80's) and I think it is worth at least doing a bit of research about. Most likely, you cannot safely run a process without ceding control regularly, but you could guarantee that it will not be interrupted for short periods.

Community
  • 1
goldilocks
  • 58,859
  • 17
  • 112
  • 227