I am aware that there are major architectural differences between the two families. I want to understand what needs to be done to make SC58x work with stream processing where interrupts (SPORTs) happen sample by sample. In a way, I need to know to translate some of the 214xx habits and tricks to the new SC58x specifically for applications that require low latency and for these applications hardware and software both come into play.
In the SHARC 214xx (or older), the interrupt vector table can be flexible in arranging the peripherals like SPORTS, DAI/DPI edges, etc. For the SC58x, the interrupts from peripherals seem to go through the system event controller. This is also visible when you open a SC58x CCES project. So with the SC58x, there is one vector to support different interrupts from different peripherals. Somebody ask this already in https://ez.analog.com/docs/DOC-12404.
A related question too is that for the SHARCs 214xx, there is support in the VDSP C libraries to differentiate the processing for the interrupts namely one can register an interrupt vector in varying degrees as discussed in EE-134. The types of
interrupt regiestration is differentiated by code overhead. (e.g. interrupt( ) vs interruptf( ) vs interrupts( )). In addition to what
is discussed in EE-134, there are tricks that can be implemented to minimize the impact of an interrupt saving and restoring of registers. In the current CCES, the interrupt registration is via the API adi_Int_InstallHandler( ) and please inform
me if there are new API for faster ones.
For the SC58x, since the peripheral interrupts are funneled through one interrupt is it correct to say that if there are several interrupts coming from different vectors that the code has to distinguish the source first before doing the actual interrupt code? Is there a way to impose a hierarchy within the unified interrupt (like manipulating the PICR in the 214xx)?
In an interrupt, (say written in assembly and in a 214xx context), you can minimize the impact of an interrupt context switch if you capitalize that SHARCs have secondary registers and DAGs and only save (and restore later) only the registers you use within the interrupt. Can a similar trick be done in the context of Sc58x? Some interrupts go in and out with minimal action, for the SC58x how can we minimize all the context switching for these?