ErikkEnglund opened a new issue, #15888: URL: https://github.com/apache/nuttx/issues/15888
### Description While looking into extending Espressif esp32-c3 with rs485 rts/de control, i´ve come across a behaviour i cant really get my head around. I got heads up from Alan to checkout the RS485 implementation in arch/xtensa/src/esp32/esp32_serial.c. I did a test implementation but didnt manage to get it working as intended. I dont like the part where it loops over and over again in the interrupt until characters are sent, it looks like a fix for the issue below (i dont have a Xtensa ESP32 board for testing). The main issue i think is that the Nuttx serialdriver disables tx-interrupts after putting the characters into the txfifo, making it impossible to catch the BRK_DONE/BRK_IDLE interrupt correctly. The following is observed if we put some debug characters to the console when enabling/disabling interrupts for UART1. (in arch/risc-v/src/common/espressif/esp_serial.c - esp_txint). Where ^ marks Enabling interrupts and _ marks disabling. nsh> serialblaster /dev/ttyS1 100 Sending 100 bytes of data to /dev/ttyS1 (fd=3) _^__^__^__^_nsh> DIS_TX_IRQ ENA_TX_IRQ DIS_TX_IRQ DIS_TX_IRQ ENA_TX_IRQ DIS_TX_IRQ DIS_TX_IRQ ENA_TX_IRQ DIS_TX_IRQ DIS_TX_IRQ ENA_TX_IRQ DIS_TX_IRQ It looks quite correct from the console but when checking the logic analyzer we can see that the tx-interrupt disable happends immediately after putting the data into the txfifo and leaving with tx interrupts disabled. The result is that we cant reset the RTS/DE, until we send another character on the bus, which enables tx interrupts - which in turns imediately fires the interrupt and we can reset our pin. Is this the intended behaviour? I have´nt dug deeper into the Nuttx serial driver part, as i guess this should work as intended on other chips and wouldnt require any modifications.  Guarding the uart_hakl_disable_intr_mask() for UART1 with a uart_hal_is_tx_idle(), keeps interrupts active and the system works correctly. But as it cant disable the interrupts, the serial drivers keeps calling for disabling tx interrupts, wasting cpu cycles.  nsh> serialblaster /dev/ttyS1 100 Sending 100 bytes of data to /dev/ttyS1 (fd=3) _^___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________^__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________^__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ________________________________^_________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________nsh> I would like to be pointed in the right direction going forward and im sorry if this is a question that should be self explanatory, as im not very familiar with Nuttx. Im building in WSL2 Ubuntu 22.04 and gcc version 10.2.0 (SiFive GCC-Metal 10.2.0-2020.12.8) ### Verification - [x] I have verified before submitting the report. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
