|There is priority involved, it's the priority of the interrupt handler"Armin" <firstname.lastname@example.org> schrieb im Newsbeitrag
"John Nagle" <email@example.com> schrieb im Newsbeitrag
Yes. This is a known problem with some CPU boards.
Even some embedded boards have this problem. Look for
emulated old-style serial ports, IDE disks emulated with
flash memory, USB keyboard emulation, and similar
stuff being done in system management mode.
When you have unexpected interrupt delays, give the full
There should be no long interrupt lockouts in any
standard QNX software.
How are you measuring the time delay between interrupts?
to measure the interrupt delay i use the Clockcycle() call, and get the
system time by each incoming interrupt.
Are you using an ISR + interrupt handler thread or just an interrupt
If you are using an ISR ... what is the priority of the returned event?
Is the SIGEV_PULSE_PRIO_INHERIT flag set?
If yes, the interrupt handler thread inherits the low(?) priority of the
pulse event. If no, what is the priority of the interrupt handler ?
If your device is a PCI device ... is its interrupt shared by an other
If yes, is the other driver disabling the interrupt for a long time?
Could it be that the interrupt logic of the hardware of you device has a
bug? Is the interrupt logic implemented in a FPGA??
i use ISR + interrupt handler thread. The signaling event is of type
SIGEV_INTR, so no priority allocated.
thread. It's possible that it gets preempted by a higher priority thread.
Also other interrupt of higher priority might disrupt it.