Printable View
For those of you who care:
Using DT-INTs and running an 18F8723@40Mhz -
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).
Note that this is just getting into, and out of, the interrupt. Anything you do inside the ISR will add to the times above.
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.
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.
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.
Awesome! :)Quote:
Originally Posted by Charles Linquis
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?Quote:
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).
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.