How long does it take for uart data to be available on RX Buffer?

[Gardin]

Hello guys, hope you are all well.

I'm working on a project that heavily depends on UART.

I send commands and receive responses sometimes as big as 22KB.
The problem is that data does not always come in a good ordered way, sometimes I receive stop bits when they shouldn't be there.
Therefore, I need to call

Code: Select all

uart_read_bytes()

more than once and keep checking if I received the complete response.

What is weird is that this process takes much longer than it should, what appears to me is that there is a delay beetwen data coming to internal RX buffer and appearing as available on

Code: Select all

uart_read_bytes()

.

Why is the reason for this delay? The data shouldn't be available as quick as possible since data come in through interrupts?

ANY help is appreciated!! Thanks a lot

--
Gabriel Gardin.

[Scott.Bonomi]

I am a wee bit confused by your mention of stop bits. If you are running with no stop bits (N-8-0) and you are seeing them, as the last active bit in a 10 bit pattern, then the other side seems to be cheating. If you are seeing your end of frame marker without a complete frame, that often implies a buffer overrun. It may be a discontinuity on flow control between your port and the remote device. It may be she size of your local port buffer is not large enough. 22kBytes at 115200-N-8-1 should take almost .2 seconds, and most of 50 mSec at 460k. I expect there is a possibility of data getting lost if you empty the ring buffer while data is coming in.

Comparing the port config to the configuration of the remote device might be useful.
Ensuring that the ESP_LOG results are not coming out the same uart could be helpful.
If possible try setting a different flow control and seeing if that affects your results.
You also have the option to set the point at which the ISR is activated with uart_set_rx_full_threshold() which covers the case of the buffer getting overfull between the buffer full event and the ISR getting back to it to empty it. If the level is too low, you will be in the ISR continually, If too high, you will likely lose data during high load.

[Gardin]

First of all thanks a lot for the fast repply.

Yes, there is a problem with the remote device.

I first noticed the problem because the esp32 is receiving imcomplete messages, so I analyzed the TX, RX lines with a Logic Analyzer, and then I saw multiple discontinuities in the bits. I've contacted the other team for fixing this bug, but for now I need an workaround.
My workaround is to call uart_read_bytes() multiple times untill I receive the complete message, but this is taking way too long than it should, and I cannot figure it out why.

When you said

If you are seeing your end of frame marker without a complete frame, that often implies a buffer overrun.

you refer to a buffer on esp32 or on the remote device? Is it possible for this discontinuities to be caused due to a buffer overflow somehow?


Here is an image showing what I mean by discontinuities.

[ESP_Sprite]

Note that the UART has an internal FIFO buffer that hardware will try to fill up first before generating an interrupt: only after either the FIFO is decently full or the Rx line is idle for a wile will the interrupt go off. This is configurable, though.

[dastoned]

Note that the UART has an internal FIFO buffer that hardware will try to fill up first before generating an interrupt: only after either the FIFO is decently full or the Rx line is idle for a wile will the interrupt go off. This is configurable, though.

Thank you for the insight, ESP_Sprite. I understand that there is a 128 byte RX FIFO buffer in UART hardware, in addition I must give the UART driver also a buffer of at least 129 bytes. Why the latter buffer, if hardware already has one?

[ESP_Sprite]

Because for performance reasons, the interrupt will read the entire FIFO buffer into the receive buffer, so that the hardware buffer is entirely empty to guarantee as much bytes to be received as possible before the next interrupt.

[dastoned]

Ok, thank you again.

I'm just pointing out that the UART reference documentation (https://docs.espressif.com/projects/esp ... eHandle_ti) doesn't really describe what the driver's receive buffer does or how to choose its size.

[ESP_Sprite]

That is a valid point.

[Gardin]

Thank's guys! That was a really useful discussion.

[username]

@gardin. Have you looked at the many uart examples ?
https://github.com/espressif/esp-idf/tr ... erals/uart

There is more that one way to skin this cat. You can have events fire on when the uart sees certain characters. Maybe that will help.
I.E. looking for CR or LF at the end of your data string perhaps.