Hi Cai,
thank you for your report. Described behavior is not a bug, but it is could be a gap in documentation. RTOS driver is blocking current task until whole required data are received. Data transfer is managed on background. So low level uart driver is feeding background buffer (ring buffer) and task is blocked by UART_RTOS_Receive() call. That enable execution of some another task without waiting and wasting of time.
Background buffer have limited size (in case of example 32B), So if the reading from ring buffer is slower than writing into it, buffer will overflow and corrupt data. To show this situation in example, data reading is slowed down by 1s delay (vTaskDelay(1000)).
Warning "Ring buffer overrun!" is triggered when there is no empty space in background buffer.
Try to paste 32+3 characters (Ring buffer size 32B, 4B are read immediately) into terminal (paste it by Alt+V in TereTerm or by right click).
If you insert:
"12345678abcdefgh12345678abcdefghxxx"
terminal will print out four bits in each second without warning:
1234<1s>5678<1s>abcd<1s>efgh<1s>1234<1s>5678<1s>abcd<1s>efgh
First four bytes were immediately received ("1234") and rest of data became stored into ring buffer (application will read data after 1s, but transmission is very quick). Checkout background_buffer in watch window after UART_RTOS_Receive(). Ring buffer is almost full "5678abcdefgh12345678abcdefghxxx", but there is still one empty byte => no warning appears.
but if you insert 32+4 characters at once warning appears.
If you insert:
"12345678abcdefgh12345678abcdefghxxxx"
terminal will print out four firs bits and warning:
1234
Ring buffer overrun!
First four bytes were immediately received ("1234"),but ring buffer was fully loaded with data with no empty space. This situation trigger kStatus_UART_RxRingBufferOverrun returned from UART_RTOS_Receive().
RTOS driver uart_freertos is able to receive only 31B of data between two calls of UART_RTOS_Receive() in case of 32 B ring buffer (background_buffer in example).
There is also second buffer which can overflow. It is part of lpuart hardware and in example is called "Hardware buffer". You can try to put break point into UART_RTOS_Callback in fsl_uart_freertos.c. It will block data flow to ring buffer and it will cause overflow of hardware buffer.
The example showing that even if the application is not able to handle incoming data quickly enough, the status of UART_RTOS_Receive is always able to give information if the data are consistent or not because of overflow.
So take away note is, uart data can be broken by buffer overflow if application is not reading fast enough, but application can be aware of it because of returned status.
Regards,
David
