Hi Erik, That is right, AFAIK all RS485 implementations on NuttX use this approach (even for ESP32).
This solution was created by Freddie Chopin many years ago for STM32. I think this approach is similar to the way NuttX supports SPI CS pins, so you have more flexibility to use any pin you want. Unfortunately this approach doesn't work on Raspberry Pi Pico boards (original one and Pico 2), because ARM PL011 doesn't have Transfer Complete interruption (thanks ARM!!! :-/ ) It is possible to use a timer and generate a timed interrupt X us after beginning of the transfer, but it needs to consider baud-rate, number of bits, parity, etc. BR, Alan On Tue, Feb 18, 2025 at 4:35 PM Erik Englund <erik.engl...@gmail.com> wrote: > Hi Alan! > > Native hw-controlled rts would ofcourse be the cleanest solution, but this > project is not very timing critical so the software solution you suggest > will most likely be sufficient! > Thanks for pointing that out, i´ll just do it that way instead, to get > going. > > But this also raises the question of rs485 support in any ESP32 chip, is > this just not supported? > > *"The legacy implementation theoretically supports RS485"* > So not really supported? > Just for my own understanding and peace of mind, i dont really care - just > seems a bit odd. > But then again, lots of chips out there lacks features that it is supposed > to include. > > Den tis 18 feb. 2025 kl 16:08 skrev Alan C. Assis <acas...@gmail.com>: > >> Hi Erik, >> >> Do you want to implement it using the native HW from serial controller to >> support RS485 or do you just want RS485 and it could be implemented as in >> other MCUs where after detecting transfer complete we control the DE/RE pin? >> >> If the later is OK for you, then please take a look how it was >> implemented to ESP32 (arch/xtensa/src/esp32/esp32_serial.c), just search >> for CONFIG_ESP32_UART0_RS485 >> >> BR, >> >> Alan >> >> On Tue, Feb 18, 2025 at 11:47 AM Erik Englund <erik.engl...@gmail.com> >> wrote: >> >>> 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? >>>>> >>>>> >>>>> >>>>>
