2008-10-09 05:37 AM
Max frequency of TIM2 periodic interrupt?
2011-05-17 03:47 AM
I don't see anything wrong with your clock setup code.
2011-05-17 03:47 AM
thanks for posting back, I'm glad the issue is gone.
> Difference between -O0 and -O1 is also surprisingly high. -O0 is almost a silly 1-to-1 translation, it produces horrendous code, the difference sounds right to me.2011-05-17 03:47 AM
Quote:
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!2011-05-17 03:47 AM
Quote:
On 09-10-2008 at 13:57, Anonymous wrote: thanks for posting back, I'm glad the issue is gone. > Difference between -O0 and -O1 is also surprisingly high. -O0 is almost a silly 1-to-1 translation, it produces horrendous code, the difference sounds right to me. In general - yes, I agree. However, at work I have to deal with SH-4 based CPUs, and the difference in this case is not as big, I believe. Perhaps just because optimizations with -O1 and -O2 implemented in gcc version that we are using are not too good (which I can ocasionaly confirm looking at produced code) :).