Post Go back to editing

Interrupt latency, dead time, ADSP21489

Hi,

I am working on the ADSP21489 EZ-Kit.

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.

                    Pink = function called, yellow = toggle IO in main loop  (~80ns)

If you have any comments or suggestion, I would be glad to read it.

Thank you,

Marc

  • Hi Marc,

    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

    http://www.analog.com/static/imported-files/software_manuals/50_21k_cc_mn_rev_1.5.pdf

    Let me know if you have further queries.

    Regards,

    Mahesh

  • Mahesh,

    Thank you for your answer.

    In fact, for some reasons, we are using CrossCore Embedded Studio, not VisualDSP++.

    So I don't know if there are these dispatchers for this compiler too. I am doing this interrupt initialization :

    void Init_Interrupt(void)

    {

         adi_int_InstallHandler(/*DPII*/ ADI_CID_P14I , (ADI_INT_HANDLER_PTR)InterruptHandler, 0, true);

         SRU(DPI_PB07_O, MISCB1_I); // route directly DPI7 (PWM) to MISCB1 (Interrupt)

                                                       // PWM now (for test) but external signal in the future

         //Falling edge

         *pDPI_IRPTL_FE |= EXT_MISC_1_INT;

         //unmask individual interrupts

         *pDPI_IRPTL |= EXT_MISC_1_INT;

         sysreg_bit_set(sysreg_IMASK, DPII);   //Enable DPI Interrupt

         sysreg_bit_set(sysreg_MODE1, IRPTEN); //Enable Interrupt

         adi_int_EnableInt(/*DPII*/ ADI_CID_P14I , true);

    }

    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?

    Thank you,

    Marc

  • Hi Mahesh,

    I understand well about these 5 dispatchers.

    But what about the CrossCore Embedded Studio? Are they available there?

    Our application will have only a single interrupt. Can we enable the use of the duplicated registers, instead of the compiler interrupt service routine making copy of all of these registers?

    Thank you,

    Marc

  • Hi Marc,

    The 5 dispatchers are not available for CrossCore Embedded Studio.

    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:

    https://ez.analog.com/thread/19118

    Please note that this solution is very restrictive, and undocumented, and therefore not the recommended solution.  This may or may not work for future SHARC processors.

    Please let us know if this helps.

    Thanks

    James 

  • I think CCES must support all of VDSP++'s dispatchers which must view in C/C++ manual or the people don't migrate CCES.

    Or can ADI add new abilities from CCES to VDSP++ like the native support of fixed point in C++.

  • Hi,

    I think that there is already a response to your points in the following thread.  It goes into a bit more detail, and it's probably the best place to post any replies.

    https://ez.analog.com/thread/21117

    Thanks

    James

  • This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

    Thank you,
    EZ Admin