Honored Contributor
Honored ContributorBefore using interrupts you should look at the interrupt entry/exit code paths lengths and compare those to the time the task itself will take.
Also look at what the ISR itself does. If the ISR only sets a flag, can you read the hardware register at the point where you would look at the flag? Doing so saves you an interrupt entry/exit. Not using interrupts also means that you don't have to disable them when accessing the data areas the ISR might change. I will use interrupts on embedded systems, but only where it is necessary to process something before the current 'task' returns to the idle loop. In which case it is necessary to do all the relevant hardware accesses in the interrupt routine itself. I'm not sure how long your SPI read takes, a 32bit exchange at 20MHz is 160 instructions at 100MHz - not many really. The ISR paths could easily be longer than that, especially if they go through any OS interrupt dispatch code and a later call to schedule a thread (or whatever the RTOS uses). So polling for completion (even in an ISR) may actually make sense, especially if there some other actions you can do while the SPI transfer is progressing.
