High speed SPI on TIM PulseFinished interrupt?

[FredS]

    Hallo everyone,

As a relative newbe in the world of MCU programming, I am searching for an acceptable solution for the fast readout of an ADC chip with a SPI interface. It concerns the MCP33131D/10 ADC (16bit, 1MS/s) to be controlled by a STM32F401CCu Blackpill MCU.

The ADC SPI works slightly different from the standard SPI protocol: the normally used "CS-not" is named 'CONVST' (CONVersion STart), which controls the 'start acquisition' by its rising edge and signals 'data-available' by its falling edge. As this pulse is produced by the MCU, the 'data-available' is not signaled by the ADC, but must predicted by the program (datasheet: >= 1us after the rising edge).

My application should digitize an analog signal every 8us, meaning the CONVST signal must be high during 1 ... 1.5us with a rep-rate of 8us or 125kHz. My first design was the use of a PWM timer signal with a period of 8us and a 1.25us pulse. The interrupt condition 'pulse falling edge' should fire 'PWM_PulseFinished', that invokes the readout of the bytes by 'HAL_SPI_Receive()'.

During my searches on the internet for information around my plan I read a reply of an experienced programmer who stated that even a well-designed ISR will need several hundred clock-ticks to execute. In my case (with a 84MHz clock), this means ~4-5us. So my plan looks feasible, but will require very efficient programming and leaves very little room for other tasks (like exporting the collected data to an USB port). Is this method a way to go or are there better solutions?

I also considered the use of DMA for reading the data from the SPI-bus, but have no clue how to organize this approach in code. The SPI interface must start reading after detection of the falling edge of a Timer PWM signal. After that the two bytes must be transferred to the correct entry in the global data-array. And finally, the program must be informed when the whole array has received new values, so the data export can be started. I think to know a solution for the data dumping (resembles a situation I handled earlier), but I have no idea how to tackle the other tasks.

I sincerely hope there are experienced members of this forum, willing to think with me for a feasible solution for this case. Any advise and/or comment will be highly appreciated,

many greetings from the Netherlands,

Fred Schimmel

[FredS]

    Hallo TDK,

Thank you for this "trick" to bypass the call to a bulky function, while regeneration of files by CUBEIDE is still possible.

Greetings,

Fred Schimmel

[FredS · Accepted solution]

Hallo Jan,

Thank you for your honest sermon.

I fully agree with your reasoning that automated systems like CUBEIDE are quite comfortable when one wants to create simple, straight-forward applications without time-constraints. In those cases the invisible overhead is not bothering, maybe some higher power consumption. The constraints of that approach become a constricting harness once one wants something outside the foreseen concept. Plus it is obscuring the way things really happen, what is going on below the hood.

You gave me an additional push to dig deep to explore the inner part of functions and see how they finally end in adjusting register values. But on the other side, there is the wish to get my experiment running, for which the MCU-application is a requirement only. I should find a good balance between learning to program a MCU and making progress on my hobby-experiment.

Thanks for sharing your insights,

Fred Schimmel