interrupt latency

[fggnrc]

Posted on July 14, 2004 at 09:23

interrupt latency

[fggnrc]

Posted on July 13, 2004 at 05:13

Hello !

I am designing and application for the ST7FLITE29. The micro has to handle the RS 485 bus and some I/O. Since the ST7FLITE29 does not provide a SCI (hopefully ST7FLITE39 will do...), I am plannig to follow the sw UART route. The key problem in a software implementation of an async receiver is the syncronization with the internal timer(s): a up-to-down level transition interrupt is triggered at the beginning of the start bit and from this event all receiving timing must be syncronized therefore interrupt latency is the main source of phase errors. The ST7 documentation says that the latency is between 10 and 21 clock cycles. 10 cycles are needed to save registers onto the stack, while 11 cycles are the longest instruction completion time (MUL). In my application this statement is not always true: there is a small probability (1/250) that the timebase interrupt is serviced while the external interrupt is fired. This means that the maximum latency is given by the length of my timebase service routine plus 10 clock cycles. Is this true? As far as I can understand from the documentation, why 19 cycles are wasted (IRET + register saving on stack) while there is no need to restore and save anythig? Why not check for pending interrupts at the beginning of IRET ? Thanks everybody for your opinions and answers!

[anshulgrover415]

Posted on July 13, 2004 at 09:16

If you want to enable the interrupt even when you are in the timebase interrupt routine you can do so by using the RIM instruction in the ISR. In this case if any of your interrupt flag is set in the ISR then the corresponding ISR will be executed. IRET from that ISR will bring the execution to the first ISR and the IRET of the first ISR will again take the execution back to the main program. It will be kind of nested interrupt.

[fggnrc]

Posted on July 13, 2004 at 10:38

You are true!

Anyway, here is my planned RTC1 interrupt handler: RTC1_HNDLR INC SOME_COUNTER IRET If I follow your hint it would be: RTC1_HNDLR2 RIM INC SOME_COUNTER IRET In the worst case the maximum latency is: 4 + 9 + 10 cycles in my original RTC1 handler 8 + 10 cycles in the modified one. NOTE: INC needs 5 cycles to complete; IRET 9; register save 10. In your solution an important thing is missing: data coherence! If an Input Capture event must be handled (as in my application), the LTICR value is related to the one of the timebase counter. In RTC1_HNDLR2 every interrupt handler can suspend RTC1_HANDLER. If LTIC interrupt is fired between RIM and INC, SOME_COUNTER is not updated, so the user of LTIC makes a 1ms error! The ST7 interrupt priorites are designed to avoid such errors if there is no RIM inside an handler!

[anshulgrover415]

Posted on July 13, 2004 at 12:48

What if you write your routine like below

RTC1_HNDLR2 INC SOME_COUNTER RIM IRET In this case you will not make 1msec error as you are incrementing your counter. Here you are just saving the 9 cycles taken by IRET.

[fggnrc]

Posted on July 14, 2004 at 05:04

Aina,

your replies are helpful! In your example, the maximum latency drops to 17 (5 + 2 + 10) and data coherence is preserved. I started this thread to show a silicon limitation: the silly IRET + register save operation that the ST7FLITEx core has. It would be nice if I have not to bother of RIM and other workarounds: 5 cycles are always fewer that 17! Thank you again!

[anshulgrover415]

Posted on July 14, 2004 at 07:54

This register saving is done even in HC908GP32. This is done so that the registers are free to be used in the routine. If the saving is done by LD instructions then the time required will be much more.

[fggnrc]

Posted on July 14, 2004 at 09:23

Aina,

from your reply I realize that my previous statement was not clear. Think about what happen in any interrupt service routine without a RIM opcode. The core executes each instruction and finally the IRET. The micro-operations of IRET are: POP CC POP A POP X POP PC.h POP PC.l Since there is a pending interrupt, what happens ? The answer is in the figure 20 at page 35 of ST7FLITE2x datasheet: PUSH PC.l PUSH PC.h PUSH X PUSH A PUSH CC JP INTERRUPT_HANDLER Do you see the wasted cycles ? Would it be better if the core checked for a pending interrupt at the beginning of IRET, and jumped to the interrupt handler when the test is satisfied ?