Interrupt driven library about pigpio HOT 6 CLOSED

If pigpio used interrupts rather than sampling it would break a lot of functionality.

For instance this view would be impossible https://www.youtube.com/watch?v=Lp7oEj0iAe8

A fundamental problem with gpio interrupts is they are not time-stamped so you have little idea of when they happened. By default pigpio sampling will give relative timings to +/- 10µs, with gpio interrupts you are talking about +/- 100µs and considerably worse on occasion.

There will also be a cross-over point where sampling will use less resources than interrupts. I suggest you do an experiment and see how many gpio interrupts per second are needed before 10-20% CPU is hit.

Also gpio interrupts can't handle changes in rapid succession, anything less than 50µs apart are likely to be missed.

from pigpio.

Thanks for the explanation. Yet I think GPIO interrupts would be a nice extra for the library for not-so-time-critical applications where one could live with -+100µs.

Could eventually a (helper) kernel module provide somewhat accurate time stamps for GPIO interrupts?

from pigpio.

pigpio doesn't stop you using interrupts. I use them myself when I want to compare performance.

If you need quick reaction on the Pi interrupts are great. Typically a one off event will be processed within 50µs rather than the 500µs imposed by the pigpio method of batching of events,

For most applications that reaction time is irrlevant, what is important is knowing the relative time of events with respect to each other.

I don't understand why the kernel doesn't time-stamp events. To me there is no down side. I assume it's because there is no portable clock in current Linux systems to use for the time-stamp.

Apparently LIRC has problems when the system is busy in discriminating the length of 500µs plus times between gpio levels! A suggested solution is to sample 8000 times per second. pigpio samples at a default 200 thousand times per second.

from pigpio.

Thanks for the explanation again. Another option would be for me to further reduce the sampling rate. Is there any easy way to do it? (Haven't looked at the code yet.) 10µs is still "too high" for my application. Is there any reason for not allowing lower sampling rates?

from pigpio.

I wouldn't call it easy, but it is not as hard as it use to be. I used to support using both the 19.2MHz clock and 500MHz clock for timing.

20µs is the obvious first choice. I'll have a look and get a feel for how hard the change will be. I might take several days though.

If you don't need the sampling logic it would be simpler to just make that thread a NOP.

In pthAlertThread change

cycle = (oldSlot/PULSE_PER_CYCLE);
pulse = (oldSlot%PULSE_PER_CYCLE);

stopped = 0;

while (1)
{

to

cycle = (oldSlot/PULSE_PER_CYCLE);
pulse = (oldSlot%PULSE_PER_CYCLE);

stopped = 0;

while(1) sleep(1);

while (1)
{

from pigpio.

OK. Thanks again. Never mind if you don't have the time tough. The library is fine as it is.

I suggest to make the information from this dialog somewhere in a FAQ or such documented for the next one who asks the same questions.

from pigpio.