Interrupt timing

[Charles Linquis]

I hadn't seen that.
I wrote a little program that had a MAIN loop that did nothing but toggle a bit. I then created a TMR0 interrupt. I used a scope to see how long the toggling stopped every time the TMR rolled over. I got my numbers from that.

[Darrel Taylor]

What I normally do is start TMR1.
When it overflows and triggers an interrupt the timer is at 0 and keeps counting.

The first instruction in the ISR stops the Timer.
Read the value of the Timer and you have the Exact latency.

Your readings include both getting In and Out of the ISR.
Unless you are pushing the frequency envelope, the time to get In the ISR is more important.

[Charles Linquis]

I agree that your method is better, and grabbing that first byte (or whatever) is more important. I just wanted to do something quick and dirty to give me an idea of total time. I figured getting in would be roughly the same time as getting out. I just needed to make *certain* that I can always run 115K baud on the hardware serial port (with no handshaking) using a PBP interrupt without worrying.

Of course, it turns out that I can.

[Darrel Taylor]

Of course, it turns out that I can.

Awesome!

[tumbleweed]

An ASM interrupt consumes about 12uSec (determining INT source and context saving and context restoring).
A PBP interrupt consumes about 25uSec (more variables to save/restore).

Those numbers are sort of surprising, esp. the ASM one. That seems like a lot of instructions. I haven't used PBP for a long time... is there really that much overhead?

[Charles Linquis]

I need to check the ASM listing to figure out all the details, but it is a solid 12uSec. About 7uSec to get "in" and 5 to get "out".

This is with TMR0 as the interrupt source. Some other sources may take a few more clock cycles to decode.