SAMA5D27 SPI slave mode continuous read

Discussion around products based on ARM Cortex-A5 core.

Moderator: nferre

ytwin12
Posts: 1
Joined: Thu May 23, 2019 5:44 am

SAMA5D27 SPI slave mode continuous read

Thu May 23, 2019 9:53 am

Hi All.

We have an application. External ADC work in master mode. It collects data continuously and sends it to MPU.
The data converted by ADC is 32 bit (4 Byte). If 1K sampling rate is used, 1000 packets of data (4000 Byte) are converted per second. ADC as master, every conversion, 4Byte data will be transmitted to A5D27's SPI Receive Data Register (RDR), , we want to use MPU SPI SLAVE + DMA mode to receive data. If using DMA to move data from SPI RDR to memory, what is the best way to trigger a transmission of DMA? Avoid frequent software intervention.

Now, every time a DMA transmission is completed, a descriptor will be applied for. The descriptor will be placed in the transmission censored, and then the DMA transmission will be started. When the DMA transmission is completed, the DMA will enter its own interrupt service program, and the callback function will be executed in the interrupt service program.
This is very inefficient.

Is there a way to automatically transfer data such as 128 bytes or 256 bytes? Or use two large FIFOs to buffer ADC data alternately to avoid loss of valid ADC data.
blue_z
Location: USA
Posts: 1954
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAMA5D27 SPI slave mode continuous read

Fri May 24, 2019 11:16 pm

ytwin12 wrote: If using DMA to move data from SPI RDR to memory, what is the best way to trigger a transmission of DMA? Avoid frequent software intervention.
Use DMA (buffer) chaining (aka scatter/gather) to implement a 2-way (or even a N-way) round-robin buffer scheme.
Choose a buffer size that is a compromise between the frequency of interrupts, the number of received samples, and the notification latency.
For instance two buffers of 4000 bytes each means that a DMA completion interrupt occurs only once a second, but then there are 1000 samples to be processed and the oldest sample was taken a whole second ago.
IOW you can't respond in real-time with large buffers and infrequent DMA interrupts.

Imagehttps://www.embedded.fm/blog/2017/3/21/ ... ng-buffers

ytwin12 wrote: This is very inefficient.
That is an incorrect assertion based on faulty/incomplete understanding.
If this was true, then how do you explain the widespread use of DMA?
Who else besides you is pointing out this alledged "inefficiency"?
Your vague description of how you think DMA operates does not correlate well with the capabilities of the DMA controller in the SAMA5D2.
With its large DMA count capacity, the SAMA5D2 DMAC could be programed one time for repeated transfers of 3600000 samples and to interrupt only each hour. Is that "efficient" enough for you?

ytwin12 wrote: Is there a way to automatically transfer data such as 128 bytes or 256 bytes?
There's no such thing as "automatic"; operations have to be programmed or extra hardware has to be provided.
You would still need to be notified when data is available, so an "automatic transfer" does not eliminate the need for interrupts.

ytwin12 wrote: Or use two large FIFOs to buffer ADC data alternately to avoid loss of valid ADC data.
"FIFO" is typically interpreted to mean specialized hardware.
There's no need to install additional hardware for this issue that can easily be accomplished with proper utilization of the DMA controller that is integrated into the SAMA5D27.

You need to study the SAMA5D2 datasheet.

Regards

Return to “SAMA5D Cortex-A5 MPU”

Who is online

Users browsing this forum: No registered users and 8 guests