New HAL_UART API

[amomum]

Posted on April 22, 2015 at 19:16

In the good old SPL we just had UART_Init, UART_SendData (to send 1 byte) and UART_RecieveData (to receive 1 byte). All interrupt handlers and DMA operation was our own problem.

And many of us already wrote them and tested them. Okay.Now though we have HAL_UART_Send, which allows us to send a whole buffer of some size (via already written interrupt or DMA). That's great. My question is - why there is also HAL_UART_Receive which allows us to RECEIVE a buffer of some size? It will call a callback function when buffer is full.. but what if one byte got lost? What if I just don't know how many bytes I'm about to receive? I'm working with many binary protocols where size of every message is not fixed and transmitted inside of the message.What should I do, make a buffer size of 1? That's kinda weird.Or should I poll RxXferCount in the uartHandle? That would be a bit tricky, since this counter is actually decremented in the irqHandler (and is it affected by DMA at all?).Am I the only one who thinks this API is a bit strange? It would be nice to have a non-blocking function like ''UART_IsNewByteAvailable'', for example. #uart #hal #usart

[childresss]

Posted on May 18, 2015 at 18:15

one char at a time, at 200Kbaud, is not viable.

>>>>>>>>> ST, we need HAL to support ring-buffered serial reads with the UART RX always-on, for variable length incoming messages. PLEASE RESPOND, ST.

[childresss]

Posted on May 18, 2015 at 18:19

one char at a time, at 200Kbaud, is not viable.

>>>>>>>>> ST, we need HAL to support ring-buffered serial reads with the UART RX always-on, for variable length incoming messages. PLEASE RESPOND, ST.

[hbarta]

Posted on May 20, 2015 at 13:44

I'm faced with a similar situation. Luckily the protocol I'm using encodes the length of remaining data in the first four bytes received. This means I can issue two DMA requests. to receive the data. If it employed byte stuffing or used framing to demarcate the packets, I would not be so lucky.

I see that with DMA enabled that MX offers the setting to enable a FIFO. I am curious as to why this is not available for interrupt driven I/O or even character driven I/O. In the good old days when a UART was on a separate chip the 16550 had a FIFO and IIRC it could generate interrupts on FIFO levels or timeout. These mechanisms avoid the need for character by character servicing of the data stream. I suppose I would have to study the data sheet to see if the FIFO is usable w/out DMA or if the chips support some sort of timeout on DMA (once data are received.)

[taraben]

Posted on May 24, 2015 at 18:14

+1 from my side

I need a clear circular buffer api that respects and avoids race conditions. I have used the DMA receive functionality but this is far from perfect as it does not handle overflows. Adib.

[cavizzano9]

Posted on May 26, 2015 at 08:07

I had a similar issue in my Simulink targets.

Single or multiple bytes non blocking can be achieved by programming UART in combination with a circular DMA mode on a constant and well dimensioned buffer (no fifo, 1 byte transfer at time). Online you can use the DMA counter to manage how many bytes have been received: Check number of bytes, if not satisfied continue, otherwise proceed to copy the relevant bytes from the buffer before they will be overwritten by arriving data. DMA has no timeout feature, this helps you in having it continuously managing the incoming IO and use the counter as a pointer check. Obviously the only limitation is that you have to check the buffer more frequently it gets completely rewritten since last access.