SPI fastest receive method

mail2 · ‎2013-09-27

Posted on September 27, 2013 at 11:21

Hello,

I'm trying to receive data on an STM32F205 SPI1 as fast as possible.

The sender is a STM32F4, and it sends commands in different lengths up to 2048 Bytes per command. There is no OS on the receiver, just the main loop.

Polling for SPI_I2S_IT_RXNE seems too slow. Receiving via Interrupt also. Currently i'm using a 64 Byte Circular DMA buffer and read the data via SPI SPI_I2S_IT_RXNE Interrupt into an 32KByte Buffer. The Mainloop reads from the 32KByte Buffer. This method seems to be the fastest that i have found yet. Are there any other suggestions?

Thank you

Martin

waclawek.jan · ‎2013-09-27

Posted on September 27, 2013 at 13:23

> Are there any other suggestions?

Nothing spectacular.

You might play tricks on the processing of the data, which we don't know how do you perform.

You might experiment with alternating the DMA target into the two memories, which might potentially reduce DMA/CPU conflicts; but that depends on the above, too.

JW

frankmeyer9 · ‎2013-09-27

Posted on September 27, 2013 at 14:14

Are there any other suggestions?

You could try to beat your project's performance requirements with a more capable single core.

Multiprocessing is kinda pandora's box.

dthedens23 · ‎2013-09-27

Posted on September 27, 2013 at 17:49

The F205 can do 30Mbit/s SPI.

DMA is as fast as the peripheral.

So where is the slow down?

Do you have other DMA? is SPI the highest priority?

is the transfer bursty so that commands smaller than the DMA size do not complete the DMA? (There is an app note about using a timer to determine when there is no activity on the SPI pins)

mail2 · ‎2013-09-27

Posted on September 27, 2013 at 21:04

Hi,

The 205 sits on a small lcd display module, it has only to receive display commands via spi an executes this commands (draw line, set point, etc). There is no other DMA running and the priority is ''very high''. the second spi interface drives a touch controller in interrupt mode (lower priority) at 100+ KHz.

I selected the 205 because of the 30MBit SPI. The display commands itself are executed very fast, my buffers don't overflow. It seems, that the concurrent memory access of dma and cpu are slowing the things down. When i cannot get another ''trick'' to fasten the communication, then i will try to change the 205RB to a 405 with more internal speed an the second dma-able ram area.

But wait: I have just seen that the 205 has a second 16KB Ram area also (48+16=64K), so i will try to use this area for the dma, maybe it helps.

Do you remember which app-note discuss the ''timer trick''?

Thank you,

Martin

waclawek.jan · ‎2013-09-28

Posted on September 29, 2013 at 00:03

You still did not tell us, what exactly is your problem.

Btw., I'd say, ''drawing lines'' and other display-related operations might take much more time than the comm itself. But it again depends on the details, too.

JW