I am using the PIC18F2550 and I wanted to know how much time takes between an event happens (e.g. ADIF)and the interrupt routine starts. In other words, how much time the "interrupt system" takes to change the MCU's state, saving all the registers and changing the Program Counter.
3 Answers
There are two things here: the time before the ISR starts and the time the ISR takes.
When you're using C, the ISR execution time may increase a lot: http://www.xargs.com/pic/c-faq.html#isrfunc
However you asked for the time before the ISR starts, which is a few clock cycles. This can be read in section 8.3 of http://ww1.microchip.com/downloads/en/DeviceDoc/31008a.pdf:
Interrupt latency is defined as the time from the interrupt event (the interrupt flag bit gets set) to the time that the instruction at address 0004h starts execution (when that interrupt is enabled).
For synchronous interrupts (typically internal), the latency is 3TCY.
For asynchronous interrupts (typically external), such as the INT or Port RB Change Interrupt, the interrupt latency will be 3 - 3.75TCY (instruction cycles). The exact latency depends upon when the interrupt event occurs (Figure 8-2) in relation to the instruction cycle.
The latency is the same for both one and two cycle instructions.
Some datasheets tell you the latency from event to interrupt execution explicitly, but this one doesn't seem to. Check the family reference manual; there might be more information in there.
In either case it's pretty quick. Basically the processor takes the next opportunity to execute a call to the interrupt location. The registers that get saved are written to special hardware for that purpose, so that happens overlapped. Basically, the processor has to wait until the start of the next instruction cycle, and there is probably one more to flush the pipeline, then execution resumes at the interrupt address.
If one or two instruction times really matter, then do some tests to see what the latency really is. Remember that events like ADIF are synchronous, so the jitter should be 0. With external asynchronous events there is necessarily one cycle of jitter since the instruction clock keeps running.
What are you doing such that one or two instructions of latency matter?
-
\$\begingroup\$ actually I am not doing nothing that much precise...is just that I saw someone saying that the interrupt can take up to 60 clock cycles to start, and this makes me afraid haha...besides there is always the learning side of things.. I saw it in this website (Ttelmah post): ccsinfo.com/forum/viewtopic.php?p=96945 \$\endgroup\$ Commented Mar 6, 2013 at 3:35
One good way to answer questions like this is to use MPLAB's simulator. If you enable the stopwatch you can see exactly how many CPU cycles, and how many microseconds everything takes:
-
3\$\begingroup\$ I might not trust the simulator 100% for these kinds of corner case details. I have certainly seen small discrepancies between the simulator and real hardware before. Also, you can't really model asynchronous inputs with the simulator. Everything happens on instruction clock boundaries in simulation. It may also not show you a xxIF bit until it handles it. All around, the simulator might be a good first order guide, but don't count on it being cycle-accurate in corner cases like this. \$\endgroup\$ Commented Mar 5, 2013 at 23:53
-
\$\begingroup\$ @OlinLathrop - That's good to know. I haven't had the opportunity to notice a discrepancy yet. \$\endgroup\$ Commented Mar 5, 2013 at 23:54