When to use DMA on USART

[scott2399]

Posted on June 09, 2016 at 11:29

Hi,

I'm fairly new to micros with DMA and am wondering when to use the DMA to create a cyclic buffer.

Background...

I'm looking to update some working but un-maintainable drivers, eventually I'll be sorting I2C, ADC, SPI etc. but thought I'd start with something simple, the USART.I am using a STM23F103, presently in the MCBSTM32EXL, it's already on the final board, and the code works on both, but it's easier to have the dev-board on my desk.I'm also using what I've seen some people call barebones, writing to the registers myself rather than using drivers. At the moment I really want to understand what the chip is doing, so I can make good design decisions, rather than getting something working that I don't fully understand.

Foreground...

I have 2 USARTs, A. baudrate 115.2k, sending/receiving packets in bursts (100bytes ish) every 10ms (100Hz).B. baudrate 115.2k, working as a receive/respond interface, parsing requests for information and sending data back.Is it good practice to use DMA for this? What is the break point or is there one? Is it different for the two cases? I did find this discussion 

/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/General%20question%20about%20DMA&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=107

 where >100kHz is the quoted as the break point, so I get the impression that DMA is overkill for this.I have an interrupt driven version working, and would like to get to a DMA version running almost as personal development. Where can I find a good example? I have found this [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/UART%20with%20DMA%20mode&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=19302]UART with DMA mode but all the examples listed have FIFO options listed in the DMA options. I don't think the STM32F1xx has these registers (but I could just have missed it in the manual). Could you point me at an example for this chip?Thanks in advance for any help.Scott null

[AvaTar]

Posted on June 09, 2016 at 12:26

> When to use DMA on USART

IMHO depends on the application, and the kind of communication. > B.baudrate 2k, working as a receive/respond interface, parsing requests for information and sending data back. Such packet-based communication usually employs fixed start and end characters, and intermittent exchange (of packets). If the packet size doesn't match the DMA buffer size - which it practically never does, if one assumes occasional transmit errors - packet get partially stuck in the DMA buffer, and will only be available for processing after the next packet fills the DMA buffer. That introduces a latency which is often unacceptable. Thus, this would be a case where DMA is not recommended. > A. baudrate 2k, sending/receiving packetsin bursts (100bytes ish) every 10ms (100Hz). If the above mentioned latency doesn't matter, DMA would be ok. Other vendors (NXP's LPC1xxx and TI's TM4C, for example) have FIFO option for their UARTs. One might view it as dedicated DMA with reduced configurability. > I did find this discussion

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=https%3a//my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/General%20question%20about%20DMA&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=107

where >100kHz is the quoted as the break point, so I get the impression that DMA is overkill for this. For the interrupt frequency, you need to divide the baudrate by ten (roughly, 8 databits, 1 start, 1 stop bit), giving about 10kHz interrupt rate for your 2kBps. That alone is far from saturating the core. > I'm looking to update some working but un-maintainable drivers, eventually I'll be sorting I2C, ADC, SPI etc. ... ST's I 2C peripheral is not quite famous for a comprehensible and bug-free implementation, at least on early silicons like the F1 series ...

[scott2399]

Posted on June 09, 2016 at 15:23

Thanks for the quick response AvaTar,

Great information and pleased that I'd not missed stuff.> ST's I2C peripheral is not quite famous for a comprehensible and bug-free implementation, at least on early silicons like the F1 series ... Oh... I see trouble ahead... Thanks again, Scott

[AvaTar]

Posted on June 09, 2016 at 15:30

> Oh... I see trouble ahead...

Not that I2C is unusable - but search this forum (if it hasn't technical issues again) and other sites, to see for yourself ...