I am trying to track the position of a quadrature encoder using edge-triggered (rising & falling) interrupts on the gpio pins of the beagleboard. At the moment, it counts fine if the encoder rotates slowly. If the change is fast, the count “skips” or the interrupts get “stuck”. My estimate for the speed of interrupts is roughly 10kHz. So that’s about 10us between interrupts for the handler to process. I am not exactly sure what the problem is… I suspect that there is too much overheard in scheduling the handler or there is not enough time for the handler to finish before the next interrupt or both.
In system profiler, I can see that the time for the ISR and handler to complete is about 40us. Is this normal?
I agree, something is wrong. Interrupts have a priority too. If you have another driver that is not well written, you want your interrupt to be at a higher priority. I don’t think you will have this problem with anything written by QNX. I don’t recall how you choose the highest priority interrupt with QNX 6, but I’m sure it is documented somewhere. It is probably a parameter to proc.
If you ISR last 40us the interrupt will take about 50% of the cpu usage. I find 40us to be a very long time to spend in the ISR, but then again you aren’t talking about a fast machine. 10000 interrupts a seconds is a lot to ask for such a machine.
Warning: crazy idea : Find a way to transform the encoder input into an audio signal and use DMA to record audio. I am assuming that audio recording is done via DMA.