The missing barriers caused uart_get_buffered_data_len() to (very rarely)
return a garbage value. When used in MicroPython, though, this caused
select() to return and a subsequent read() to stall indefinitely until
a char was actually available.
Signed-off-by: Chen Yi Qun <chenyiqun@espressif.com>
Closes https://github.com/espressif/esp-idf/issues/6397
Merges https://github.com/espressif/esp-idf/pull/6396
- there was a small race in `uart_pattern_link_free`:
`rx_pattern_pos.data` was accessed for reading outside spinlock
- `uart_flush_input` enabled
`UART_INTR_RXFIFO_FULL|UART_INTR_RXFIFO_TOUT` intr mask on exit even
if these flags weren't set when function was called
Closes https://github.com/espressif/esp-idf/pull/7023
When `DIS_USB_JTAG` eFuse is NOT burned (`False`), it is not possible
to set pins 18 and 19 as GPIOs. This commit solves this by manually
disabling USB JTAG when using pins 18 or 19.
The functions shall use `gpio_hal_iomux_func_sel` instead of
`PIN_FUNC_SELELECT`.
During HAL layer refactoring and new chip bringup, we have several
caps.h for each part, to reduce the conflicts to minimum. But this is
The capabilities headers will be relataive stable once completely
written (maybe after the featues are supported by drivers).
Now ESP32 and ESP32-S2 drivers are relative stable, making it a good
time to combine all these caps.h into one soc_caps.h
This cleanup also move HAL config and pin config into separated files,
to make the responsibilities of these headers more clear. This is
helpful for the stabilities of soc_caps.h because we want to make it
public some day.
The under the error condition of rx buffer size is <=128 an error log is printed that reads uart rx buffer length error(>128). Propose an update to better describe the error condition as uart rx buffer length error(<=128).
Signed-off-by: Wu Bo Wen <wubowen@espressif.com>
Merges https://github.com/espressif/esp-idf/pull/5523
On ESP32, due to fifo reset issue, UART2 will work incorrectly if reset the fifo of UART1(TX fifo and RX fifo). The software can workaround the RX fifo reset issue,
while the TX fifo reset issue can not. When UART2 is used and UART1 is used as the log output port, a software reset can reproduce this issue. So we should reset the UART memory
before the software reset to solve this problem.
check master read write functions with array of registers)
fix master serial processing code and modbus controller to work with register array
modbus_master: add reading and writing of test value array (58 registers) to check failure is gone
remove parameter temporary buffer from modbus controller to allow more than 24 byte writes
driver: fix issue with TOUT feature
driver: fix uart_rx_timeout issue
driver: fix issue with rxfifo_tout_int_raw not triggered when received fifo_len = 120 byte and all bytes read out of fifo as result of rxfifo_full_int_raw
driver: add function uart_internal_set_always_rx_timeout() to always handle tout interrupt
examples: call uart_internal_set_always_rx_timeout() to handle tout interrupt correctly
examples: update examples to use tout feature
driver: reflect changes of uart_set_always_rx_timeout() function, change uart.c
driver: change conditions to trigger workaround for tout feature in uart.c
driver: change uart_set_always_rx_timeout()
freemodbus: fix tabs, remove commented code
driver: remove uart_ll_is_rx_idle()
tout_thr - move calculation and masking into hal layer update driver and uart_ll (add uart_ll_set_rx_tout)
move tout calculation into uart_ll
move calculation of time out in bit time for esp32s2 into low level uart_ll.h file
move uart_hal_get_symb_len() into hal
update set_rx_timeout() to warn user about incorrect value
update HAL, LL 1
fix uart_xx_set_rx_tout() to convert symbol time into bit time
update param description
update tout calculation in LL
update uart_hal_get_max_rx_timeout_thrd() and uart_ll_get_max_rx_timeout_thrd()
1. uart_wait_tx_done works incorrect when sending a byte of data.
2. uart_set_rx_timeout sets an incorrect rx timeout value when ref_tick is enabled
closes https://github.com/espressif/esp-idf/issues/3631
