AnsweredAssumed Answered

How to receive a varying amount of data on a UART?

Question asked by Kenny Koller on Dec 14, 2018
Latest reply on Dec 14, 2018 by Mark Butcher

I seem to be stymied at every turn with the SDK 2.4.2. If one has a binary protocol with a fixed header size one can wait for the header, look for a packet length, then setup the UART to read the remaining amount. But I'm receiving a varying amount of ASCII data terminated with a carriage return. The EDMA driver fails to do this. Now I'm trying the ring buffer.


There is this from the header file:

* When the RX ring buffer is used, data received are stored into the ring buffer even when the
* user doesn't call the UART_TransferReceiveNonBlocking() API. If data is already received
* in the ring buffer, the user can get the received data from the ring buffer directly.

From the ring buffer directly? How do I know where in the ring to start pulling data? This can't be right. The implementation details are not exposed (and shouldn't be).


The comments for UART_TransferReceiveNonBlocking() include this:

* If the RX ring buffer is used and not empty, the data in the ring buffer is copied and
* the parameter @p receivedBytes shows how many bytes are copied from the ring buffer.
* After copying, if the data in the ring buffer is not enough to read, the receive
* request is saved by the UART driver. When the new data arrives, the receive request
* is serviced first. When all data is received, the UART driver notifies the upper layer
* through a callback function and passes the status parameter @ref kStatus_UART_RxIdle.
* For example, the upper layer needs 10 bytes but there are only 5 bytes in the ring buffer.
* The 5 bytes are copied to the xfer->data and this function returns with the
* parameter @p receivedBytes set to 5. For the left 5 bytes, newly arrived data is
* saved from the xfer->data[5]. When 5 bytes are received, the UART driver notifies the upper layer.

Again, I'm being forced to know the number of expected bytes and I don't know why anyone would want to use the callback in this fashion. If you already know the number of bytes why not just wait on the callback in the first place?


I don't understand why there isn't an API to access that ring buffer. I don't think the callback is needed at all.


What is a technique to read until a carriage return is detected? I just want to read what is available and look for that character.


It's 2018. Blade Runner and Soylent Green will both happen in the next few years yet we continue to write firmware like it's 1990. We deserve a punch in the face by a replicant. There. I said it. Now I'm off to my tiny house in the woods.