DMA for unknown datareceive throw USART

[phajek]

Posted on March 18, 2013 at 15:24

Hello,

I am working on a device which one funcion should be USART to Ethernet bridge on STM32F407. I need to receive data from USART and then work with them. But beacuse of speed I wanted to use DMA instead of interrupt after every received byte. The problem is, that I don�t know, how long will be received data=>I can�t set DMA to receive fixed number of bytes and then generate interrupt. So figured out one solution: I will configure DMA to transfer received byte from USART everytime, when it will be received. DMA will use double buffer mode. Then, I will create some timeout function which will be called  periodically after some time. This function will always switch DMA to the second buffer and then read data from the first buffer and work with them. Is it possible? Could be a problem if I will be switching to the second DMA buffer at the same time as the DMA transfer will be working(It will be moving byte from USART  rx buffer to memory )? (I know, that it is not very probably, but I need my device very reliable.) Or is there any better solution? Thank you #double-buffer #dma #dma-usart

[Tesla DeLorean]

Posted on March 18, 2013 at 15:32

Doing it a byte at a time doesn't solve any issues with respect to speed.

Use a reasonably large circular DMA buffer, generate interrupts on HT and TC conditions, track where the DMA pointer is, and have a secondary timeout interrupt to collect runt byte(s)

[Tesla DeLorean]

Posted on March 18, 2013 at 15:41

Alternatively have a large circular DMA buffer, have an interrupt run at about twice the fill rate, and have that periodic interrupt flush between the last and current fill points of this ring buffer.

[phajek]

Posted on March 18, 2013 at 15:55

Good idea. Thank you

[dthedens23]

Posted on March 18, 2013 at 16:41

there is an App Note that uses timer input to detect when there is no activity on the RX line.

it fires an interrupt and one can stop the DMA, gather data, restart DMA.works well for burst or message type communication.