AnsweredAssumed Answered


Question asked by khazanskii.roman on Apr 22, 2015
Latest reply on May 26, 2015 by Avizzano.Carlo_Alber
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.