18F6722 Interrupt delay

[gnz]

I am using 18F6722. int_EXT3 is defined High to LOW. When it occurs 18F6722 is late to be in interrupt routine. All the other interrupts are disabled.

This problem doesn't occur when the subroutines in the main program are used as #inline

[Ttelmah]

Handling interrupts takes time. When the event occurs, the flag gets set normally in state one of the next instruction. Then if the enables are both set, the code will vector to the 'global' handler (more time). Tn the global handler has to save every important register that is in use (typically about 20 instruction times), and then poll the interrupt flags to see what device has interrupted (anything from half a dozen instruction times, up to dozens, if multiple handlers exist). Then the processor jumps to the defined handler. So, typically, there will be perhaps 30+ instruction times 'latency', between the event, and you actually arriving in the handler. You can reduce this, by using the 'global' handler, and only saving the registers you actually modify in your interrupt code. Depending on what your handler actually does, latency down to perhaps half a dozen instruction times can be achieved this way.
If you are only going to need the one interrupt handler, and your interrupt code is not too large, post it, and we should be able to point you to how to bring the latency down.

Best Wishes

[Guest]

Thans for your help, i found the problem compiler tells this warning:
"Interrupts disabled during call to prevent re-entrancy: RTC_GETTIME()"

it automatically disables the global interrupts when this subroute calls. Is there any way to disable this setting?

[Ttelmah]

Yes.
This happens if rtc_gettime, is called inside the interrupt handler, or is directly 'tied' to code that is called in the handler. Don't call it in the handler...
If you want the interrupt to trigger a fetch of the RTC, then set a flag, and when this is set, in the external code, call the routine. If you want to get the RTC, inside the interrupt, then don't do this in the external code. Assuming this is something like an I2C routine that handles the device, imagine what would happen if while this was in 'mid fetch', it was called again inside the interrupt....

Best Wishes

[gnz]

Thanks for your reply.
the problem is over.