This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Champs,
I asked this for a key customer.
On F2837x,
This is the diassembly codes of the customer's critical ISR code by C compiler for context save (top left) and context restore (bottom right).
Based on these codes, it takes more than 30 cycles for context save/restore, is it right?
If we add 15-20 cycles of interrupt latency (from the event trigger to entry of the ISR), then there should be at least 20+30 = 50 cycles used in this ISR for interrupt latency, context save/restore.
Is my understanding right?
This should be limited to the architecture of C28x, right?
Is it possible to significantly reduce the context save/restore cycles without resorting to assembly manually?
(That is, use C compiler only)
Wayne Huang
Wayne,
It looks about right for a nestable interrupt. If you are not using TI-RTOS, and the ISR in question has the highest priority (i.e. won't be nested), you can make use of the INTERRUPT pragma, like this:
#pragma INTERRPUT(control_isr_cpu1_pwm8, HPI)
This forces the compiler to use SAVE & RESTORE instructions for the FPU part of the context save, rather than using MOVL for each register separately. It should remove about 4 cycles on both the context save and context restore. See section 6.9.14 of the C compiler guide for more information. Apart from that I don't think you can do much without going to assembly or somehow making use of the CLA.
Regards,
Richard