Delay in UART transmission at highbaud rates

[shafy s]

Posted on February 22, 2017 at 18:53

Hi, I am developing an application using STM32L432 nucleo32 board, that samples 5 ADC channels and send that the data to UART.   The ADC channels are sampled using a timer and the maximum sampling frequency can be 10kHz.  So there can be 10K timer events. 

But I am facing some bottle neck in the UART.. even with baud rate of 921 kbps , the UART is causing delay in the transmission of the samples.  The 10K samples, ie 100000 bytes takes around 10 sec to reach the receiving end which is a PC terminal. For testing, I have removed the ADC sampling and tried sending hard coded data and getting the same result.  We have tried higher Baud rates (>1.5 Mbps), with little improvement.  The uart clock used is 32 MHz.  Is there a way to decrease this latency ?

#stm32 #uart

[shafy s]

Posted on February 22, 2017 at 18:58

I am using the stm32L432  nucleo32 board for this.

[Andrei Chichak]

Posted on February 22, 2017 at 19:34

What is your transmission method? Polling the transmitter empty bit? Interrupts? DMA?

A

[Tesla DeLorean]

Posted on February 22, 2017 at 19:56

If you have latency, perhaps you need to send the data earlier. Consider a ping-pong method, but the output rate needs to be higher than the input to sustain.

921600 baud might give you 92000 bytes per second, but you don't want to interrupt for every byte, either for the USART or the ADC

Consider using DMA to send 10000 characters to the USART at a time. This will significantly decimate the interrupt loading.

You are looking to get 1KHz interrupts, not 100KHz ones. The latter will likely saturate the processor with busy work.

[AvaTar]

Posted on February 23, 2017 at 09:37

Latency doesn't matter, I think you have a throughput problem - as the other posters noted.

With that high baudrates, you never get it to work with single-character UART interrupts. DMA (or  FIFO on other MCUs - not ST) is mandatory.

I hope you understood that you cannot run your ADC sampling and the UART transmission synchronously.

And, you might consider adding some redundancy to your transmission protocol (checksum, start/stop character), or your application will get lost on the first corrupted character.

[shafy s]

Posted on February 23, 2017 at 15:05

Hi,

We are using DMA.   In each timer event, the  ADC conversion is started in DMA mode and once it is complete the data is send to UART in DMA mode.

For testing we have commented out the ADC conversion and sending hard-coded data(11 bytes) when the timer call back is received. Before sending the data to UART , the Tx completion event is checked

At 921600 baud, upto 4Khz sampling rate the transmission seems to be fine. Above that , sometimes the Tx completion event is not received between successive timer event.

For baud rate higher than 921600, the number of bytes received correctly at the receiving side (a PC terminal application) is decreasing.  It seems like there is some limitation in the receiving side also.  We are investigating this.

[Tesla DeLorean]

Posted on February 23, 2017 at 16:59

Honestly from your description it doesn't sound like you are pipelining the acquisition and transfer effectively.

[shafy s]

Posted on February 23, 2017 at 18:24

Our requirement is to plot this as real time data in an LCD display interfaced to board.  An algorithm also need to be run on this data on the second board.  So we cannot loose the timing information.  So I am afraid pipelining cannot be used.

[Andrei Chichak]

Posted on February 23, 2017 at 18:46

Do you realize that this is a pipelined processor that uses cache and has many instructions in flight at any time, and can take pipeline stalls just by its design? Do you realize that DMA cycle steals by freezing the CPU for a few extra cycles every time it has to shuffle another character to and from the UART?

[AvaTar]

Posted on February 23, 2017 at 18:49

UART (RS232) is an unsafe protocol. I would consider an intrinsically faster alternative, like USB or ethernet.

Working implementations for such high baudrates I know of operate on PCB level, between identical devices.