Problem with realtime behavior of interrupts

[quote=“mario”]
How can you tell the for loop is not optimized out, you looked at the assembly code?
quote]

I just watch ClockCycles as I increase the number of empty loops.

It reminds me another question. As I increase the number of empty loops (the variable controlLoad), the delta-ClockCycles (the variable deltaTicks) change unexpectly. When controlLoad is small, deltaTicks is constant. It makes sense because of the InterruptWait function. When controlLoad is large (the CPU cannot finish within one ClockPeriod), deltaTicks grows linearly, instead of double/triple of ClockPeriod. It seems to me that interrupt/events are queueing. Does it make sense? How can I clear the queue, if there is one.

Yes it makes sense and as far as I know there is no way to clear the queue. Aside from calling InterruptWait in a tight loop.

It works!

Thanks mario!

I only need to call one interruptWait, no matter how many loops (hardware interrupts) I skip. I have one hypothesis about this behaviror: there is no queueing, but an interrupt register(bit). When a hardware interrupt is triggered, the bit is set. When the ISR runs, it clears the bit. I am searching for whether there exists such a bit. Any comment is appreciated.

Iris

  1. instead of InterruptAttach() and have your handler return a event,
    you can just InterruptAttachEvent(). This get rid some over-head.

  2. After InterruptWait(), and all caculaton, you want to InterruptUnmask()

  3. You want to run you program (Or say the thread doing InterruptWait())
    in a higher priority.

In item 2, do you refer to InterruptAttachEvent()?
From the QNX website, I need to call InterruptUnmask() after InterruptAttachEvent()
qnx.com/developers/docs/6.3. … event.html

This does not explain why I only need to call interruptWait once, no matter how many ticks I skip. And I have not found any alternative to avoid calling interruptWait again, if the program skips one tick.

FYI, I have set the program with the highest priority.