ADSP-21569
Recommended for New Designs
Reaching speeds of up to 1 GHz, the ADSP-2156x processors are members of the SHARC® family of products. The ADSP-2156x processor is based on the SHARC...
Datasheet
ADSP-21569 on Analog.com
Back for the second episode of my series.
I have therefore expanded the project code illustrated in the first post of this series (here: SPI slave mode shifting 1s on MISO pin during adi_spi_DMARead() operation - Q&A - ADSP-2156x - EngineerZone) to get one step closer to the real-world application I'm going to develop.
In my application idea, master SPI is going to transfer N bytes to the slave, then slave SPI is going to transfer M bytes back to the master, all in a single transaction (by transaction I mean that, from SPI masters' point of view, the whole data exchange would be equivalent to a single transfer of N+M bytes).
To simulate this new scenario, I then applied the following changes to the code:
<--- in SPIDMAMode.h, replacing DESC_BUFFER_SIZE macro
<--- in SPIDMAMode.c
<--- new callback code
<--- changes in main() to pass SPI handlers as callback parameters.
Keeping SPI clock to around 1.3 MHz as in my previous post the result is exactly as expected:
but later when trying to raise clock frequency just a little bit to around 1.6MHz, this is what starts to happen:
clearly meaning that adi_spi_DMAWrite() inside Callback() is taking too long while disabling/enabling SPI slave peripheral.
This is what emerges by "looping the SPI dance forever" then analyzing the situation with statistical profiling:
So, the question is: how can I improve this behavior? There's no solution other than stop using ADI SPI driver and switching to a lower-level approach?
Thanks in advance to anyone who wants to contribute
