Posted on May 17, 2011 at 12:47Quote:
On 07-10-2008 at 22:50, Anonymous wrote:
clearing the bit at the end of the ISR can cause lost ints, but it could also cause double triggering of the ISR for each (non-lost) int event. this could happen because the pending bit clearing operation (a memory write) can be delayed and complete out of order with respect to the return from interrupt instruction. the end result is that the ISR ends before the pending bit is cleared, and thus it's immediately retriggered. to avoid this effect, after clearing the pending bit you should read back that same register. this will stall the processor until after the write finishes.
Yes, I've already seen this effect. With CPU of this kind we need to remember about caching, pipelining, etc.
🙂 As of my primary problem - it is solved now, seems I wasn't just careful enough. Sometimes it is enough to take some rest/sleep and think again.
I've made 2 mistakes:
- I didn't notice that TIM2 clock is multiplied by 2 if PCLK1 divisor is not equal to 1. I can't find it stated nowhere in the reference manual, only trace of this feature I've found on the clock tree diagram in the datasheet. So, my timer was actually running at 72MHz, not 36MHz as I expected. I've found this mistake after enabling the PWM output and attaching scope to it.
- You were right about my ISR being actually too slow, which I discovered after cutting it down to plain GPIO switching. I've made a mistake measuring it previously.
Actually now I have some boilerplate code in the ISR (I register callbacks to ISR via pointer, in the callback I have another level of indirection, etc. - for various design reasons). I've checked how long it takes between PWM output edge and GPIO pulse - it turned out that it takes:
- 6us if compiled -O0
- 2.5us if compiled -O1
6us means about 400 CPU cycles - quite a lot, given the fact that there is a little code, just some kind of wrappers. I will probably investigate the code generated by a compiler in my spare time, anyway I was really surprised. Difference between -O0 and -O1 is also surprisingly high.
A latency of 2.5us is enough for the algorithm to work. Yesterday I've done the tests of my software UART and it works fine. However ISR leaves little room for other activities, so I will probably need to reimplement it in assembly eventually.
Anyway - ''problem'' solved, thanks for hints!
