Interrupt latency, dead time, ADSP21489

I have done some simple experiments with the interrupt. I made a tight loop in the main, where I toggle a IO pin. I also toggle 10 times another pin in the interrupt.

We used the scope to evaluate, not only the interrupt latency, but what the processor can do in between the time that the interrupt happens, and the time we actually get there. In other words, this experiment allow us to evaluate the "dead time" caused by an interrupt.

Here is some screenshots from the scope:

Time between the interrupt happening and the pin toggle. (~500ns!! So 500ns where the processor is "dead" ?!)

Time between the end of toggle and the go back to the main loop (~400ns)

I tried to do kind of the same experiment with calling a function instead of enable an interrupt in order to see how fast it is to toggle another IO pin with a function calling. And obviously to see if this is really the interrupt which causes that.

What is the interrupt dispatcher type that was used in the code.? There are 5 Interrupt dispatcher types , each providing different levels of functionality and performance.

Depending on the dispatcher used ,the processor requires certain number of cycles before calling the dispatcher and certain number of cycles to return to the interrupted code.

For example , if you are using a Normal interrupt dispatcher [interrupt()] , the processor requires approximately 200 cycles before calling the dispatcher and 127 cycles to return to the interrupted code.

So depending on the speed at which the processor is running , you will see a fixed amount of time for calling the dispatcher and similarly some amount of time to return to the interrupted code .

For details regarding the various Interrupt dispatchers, refer to Page.No 315 of the VDSP++ Compiler Manual given in the following link

Actually, the problem is not really how many cycles it takes to interrupt or to return to the interrupted code. It is that the processor is "dead" during this amount of time! It cannot do something else and that is a problem for us.

So, is there a way to make this interrupt faster, or using another kind of interrupt?

Or, is there a way to make the processor not useless during these amounts of time?

For CrossCore Embedded Studio we introduced a new unified approach to interrupt handling. The adi_int interface provides the most flexible way to handle interrupts, it ports easily between processors, supports interrupt nesting and can easily be used with or without an RTOS. It is an interface that we will support for future processors.

If you are looking for the fastest response and you are willing to lose the benefits provided by adi_int, then it might be worth looking at the solution provided here: