Yes, i put ESP32C3 in the subject to the maillist, but maybe it was omitted?
Im building with boardconfig esp32c3-generic and the wifi config, so the common implementation is used. ( for a common build theres quite a lot of header files: arch/risc-v$ find -name uart_ll.h ./src/esp32c3/esp-hal-3rdparty/components/hal/esp32c3/include/hal/uart_ll.h ./src/esp32c3/esp-hal-3rdparty/components/hal/esp32/include/hal/uart_ll.h ./src/esp32c3/esp-hal-3rdparty/components/hal/esp32c6/include/hal/uart_ll.h ./src/esp32c3/esp-hal-3rdparty/components/hal/esp32s3/include/hal/uart_ll.h ./src/esp32c3/esp-hal-3rdparty/components/hal/esp32s2/include/hal/uart_ll.h ./src/esp32c3/esp-hal-3rdparty/components/hal/esp32h2/include/hal/uart_ll.h ./src/esp32c3/esp-hal-3rdparty/components/hal/esp32c2/include/hal/uart_ll.h ) Because RS485 mode isnt supported through kconfig i changed the driver so that when calling esp_setup on UART1, mode is set to UART_MODE_RS485_APP_CTRL instead of UART_MODE_UART. But maybe thats not enough to start RS485 mode ? arch/risc-v/src/common/espressif/esp_serial.c / esp_setup() does setup of the hw flow control (uart_hal_set_hw_flow_ctrl) , so the pins seems to be setup correctly. I can live with hardcoding it until i get something working and then start to work on a correct implementation. I´ll start an Github issue. Den mån 17 feb. 2025 kl 21:27 skrev Tiago Medicci Serrano < tiago.medi...@gmail.com>: > Hi Erik, > > Would you mind opening an issue at https://github.com/apache/nuttx/issues? > > It isn't clear which SoC you are testing, but it seems to be a > RISC-V-based Espressif SoC (ESP32-C3, perhaps). For ESP32-C3, we have two > implementations: a legacy > <https://nuttx.apache.org/docs/latest/platforms/risc-v/esp32c3-legacy/index.html> > implementation and a common > <https://nuttx.apache.org/docs/latest/platforms/risc-v/esp32c3/index.html> > implementation. The legacy implementation is intended to be deprecated as > soon as the common implementation reaches the same support level. The > so-called common implementation shares sources between all the supported > RISC-V-based devices (ESP32-C3, ESP32-C6 and ESP32-H2). > > The legacy implementation theoretically supports RS485, but it doesn't > build the `arch/risc-v/src/common/espressif/esp_serial.c` (which is used by > the common implementation). So it isn't clear how you are enabling the > RS485 mode. > > For the common implementation, neither RS485 nor hardware flow control has > been implemented yet. Can you please provide more details on issues to > track it down? > > Best regards, > > Em seg., 17 de fev. de 2025 às 16:49, Erik Englund <erik.engl...@gmail.com> > escreveu: > >> While kiddo is home from school with a fever, I thought i would give >> NuttX a go again, living mostly in the Zephyr-world for the past years. >> Great job starting to implement cmake buildsystem, as keeping out-of-tree >> build directories greatly reduces the cases where you need to reclone the >> entire project due to build system errors, especially after a git pull >> without remembering to do a clean/distclean etc! >> >> Im building from master, couldnt see any relevant changes since 12.8.0. >> >> Enabling flow control in the build instantly crashes the build as the >> function: >> esp_rxflowcontrol (arch/risc-v/src/common/espressif/esp_serial.c) is >> trying to call the function esp_lowputc_set_iflow which isnt included in >> the build. It seem to exist in: >> arch/risc-v/src/esp32c3-legacy/esp32c3_lowputc.c >> Is the entine ESP32 lineup being merged to a ton of hal/hal_ll files >> instead of the old pure implementation? >> >> Anyways, flowcontrol seem to be setup in esp_setup (esp_serial.c) so just >> using that code in esp_rxflowcontrol should fix this issue. >> >> I setup UART1 in RS485 mode: dl0 and dl1 enabled + enable rs485 mode. >> CTS blocks transmission as intended if CTS isnt pulled to GND. >> But RTS signal is just pulling the pin high for a few microseconds before >> going low again, right before transmitting the message. >> >> [image: image.png] >> >> >> The issue is seen when echoing to the serialport from nsh as when opening >> the serial device in a application and transmitting data. >> >> Is this a misconfiguration or a known issue? >> >> >> >>
