[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.
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.
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.