Hello,
So here is my setup.
UART1 - GSM
UART2 -GPS
https://pastebin.com/N9E88L9t Here is the code that I used to set up UART2.
https://pastebin.com/eStNxiHsHere is the code for Initialising UART1.
If I do not use uart_flush, everything works fine and I receive GPS data over UART2 perfectly.
https://pastebin.com/Wxuhcan2 Here is the output for UART2 Read without a flush.
https://pastebin.com/rCTtt8KrHere is the output of UART2 Read with a flush.
Here is a link to the read Function that I am using.https://pastebin.com/7S4L2vYe
Any Ideas why is this happening?
A uart flush on UART1 also affects UART2 read.
https://pastebin.com/JcWxggLjHere is the output of UART2 while executing a uart flush on UART1.
Am I missing something in the initialisation?
Regards
Read Issue with UART 2
-
- Posts: 9766
- Joined: Thu Nov 26, 2015 4:08 am
Re: Read Issue with UART 2
How are you reading UART1? Are you 100% sure the static char line in readLine isn't overwritten by some other thread or something?
Re: Read Issue with UART 2
Just to be sure I wrote a different readline routine for UART1 and UART2 but the problem still persists.
Regards
Regards
Re: Read Issue with UART 2
Hi llewellyn,
I think this a misunderstanding about the meaning of uart_flush(). "Flushing" a buffer can mean emptying it into a consumer, or it can mean throwing it away.
In this case, uart_flush() discards all input which has been read from the UART and buffered pending reading by the application. So this is why you lose input data when you call it. I'll look at whether we can change the name to be less ambiguous.
If your concern is making sure you receive data as quickly as possible after it comes into the UART, you can do this by calling uart_intr_config() (after uart_driver_install()) and reducing the .rxtimeout_thresh and/or the .rxfifo_full_thresh values. This will cause UART RX interrupts to happen more rapidly, meaning data will appear in the ringbuffer more regularly (the default is for an interrupt to happen after 120 characters are read into the hardware FIFO, or after 10 byte-periods have passed without new data arriving.) ie the default worst-case latency between UART data being received and an interrupt pushing it into the UART buffer is approx 8ms at 9600bps or 70us at 115200bps.
If you need to "flush" by waiting until all bytes are transmitted by the UART, call uart_wait_tx_done().
I think this a misunderstanding about the meaning of uart_flush(). "Flushing" a buffer can mean emptying it into a consumer, or it can mean throwing it away.
In this case, uart_flush() discards all input which has been read from the UART and buffered pending reading by the application. So this is why you lose input data when you call it. I'll look at whether we can change the name to be less ambiguous.
If your concern is making sure you receive data as quickly as possible after it comes into the UART, you can do this by calling uart_intr_config() (after uart_driver_install()) and reducing the .rxtimeout_thresh and/or the .rxfifo_full_thresh values. This will cause UART RX interrupts to happen more rapidly, meaning data will appear in the ringbuffer more regularly (the default is for an interrupt to happen after 120 characters are read into the hardware FIFO, or after 10 byte-periods have passed without new data arriving.) ie the default worst-case latency between UART data being received and an interrupt pushing it into the UART buffer is approx 8ms at 9600bps or 70us at 115200bps.
If you need to "flush" by waiting until all bytes are transmitted by the UART, call uart_wait_tx_done().
I can't explain this, unless there is also a stray UART2 flush somewhere in the code. If you're sure this is happening then it points to bug in the driver.llewellyn wrote: A uart flush on UART1 also affects UART2 read.
Re: Read Issue with UART 2
@ESP_Angus : Thanks for your reply.
Basically, I want to discard all data after I have received $GPRMC string from GPS. So I call a uart_flush after I receive the required string.
The issue is not about losing data while I call uart_flush. But the consequent data received after I flush is never "correct" or corrupt.
If I just call uart_flush once. All the data received after that will be jumbled and corrupted and not the expected string.
I have confirmed the issue with a flush on uart1 too. It affects the uart2 performance.
I will try the solution you suggested and let you know about it.
Regards
Basically, I want to discard all data after I have received $GPRMC string from GPS. So I call a uart_flush after I receive the required string.
The issue is not about losing data while I call uart_flush. But the consequent data received after I flush is never "correct" or corrupt.
If I just call uart_flush once. All the data received after that will be jumbled and corrupted and not the expected string.
I have confirmed the issue with a flush on uart1 too. It affects the uart2 performance.
I will try the solution you suggested and let you know about it.
Regards
Re: Read Issue with UART 2
Hi ,
The Exact same issue described here was faced and reported on arduino-esp32 issues https://github.com/espressif/arduino-es ... -325694606
And it was solved by using the designated pins for UART2 instead of using the gpio matrix.
But since Pin16 and 17 cannot be used in ESP32-WROVER module I cannot use the designated pins for UART2
Regards
The Exact same issue described here was faced and reported on arduino-esp32 issues https://github.com/espressif/arduino-es ... -325694606
And it was solved by using the designated pins for UART2 instead of using the gpio matrix.
But since Pin16 and 17 cannot be used in ESP32-WROVER module I cannot use the designated pins for UART2
Regards
Re: Read Issue with UART 2
I was able to solve this by changing rx_flow_ctrl_thresh from 122 to 40.
Re: Read Issue with UART 2
Hi ,
isnt the flow ctrl threshold used for hw flow control??
Regads
isnt the flow ctrl threshold used for hw flow control??
Regads
Who is online
Users browsing this forum: No registered users and 97 guests