You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Erik Englund <er...@gmail.com> on 2025/02/17 19:48:22 UTC
ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
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?
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by "Alan C. Assis" <ac...@gmail.com>.
Sorry my typo, it was: "the interrupt shouldn't be disabled"
On Fri, Feb 21, 2025 at 12:06 PM Erik Englund <er...@gmail.com>
wrote:
> No, I haven't checked with any other chips. I´ll see if I can do a test
> with stm32 or nrf52
>
> Den fre 21 feb. 2025 kl 15:42 skrev Alan C. Assis <ac...@gmail.com>:
>
>> Hi Erik,
>>
>> Thank you for explaining the issue! And for opening the issue to track it.
>>
>> I agree with you, the interrupt should be disabled just after
>> transmitting a character.
>>
>> BTW, did you check if this same side effect affects the STM32? I think
>> so, because I remember the DE/RE was enabled/disabled per character
>> transmitted.
>>
>> BR,
>>
>> Alan
>>
>> On Fri, Feb 21, 2025 at 11:36 AM Erik Englund <er...@gmail.com>
>> wrote:
>>
>>> Hi.
>>> I posted a Github Issue, to make it easier to track.
>>>
>>> The UART TX Interrupt is disabled by the serial driver (
>>> drivers/serial/serial.c ) after its done filling the txfifo, and thus we
>>> can never receive the UART_TX_DONE_INT_ST after the fifo has been filled by
>>> the driver.
>>> It only works by catchen an interrupt while we are still filling the
>>> fifo and then looping in the interrupt handler until all bytes are sent,
>>> essentially a busy loop in interrupt context.
>>>
>>> I guess that's why in arch/xtensa/src/esp32/esp32_serial.c, the logic is
>>> to loop for a maximum of 256 times before returning from the interrupt
>>> handler.
>>> It detects the TX_DONE interrupt, but thats just for one of the
>>> characters, not the complete transfer and requires the driver to loop until
>>> completion.
>>>
>>> Im using 9600 baud for communicating with an industrial device, so
>>> busylooping will take a considerable amount of the available cpu time.
>>>
>>> The serialblaster was just a test for transferring a bunch of data. The
>>> same behaviour is seen when just simply sending a string from nsh ( echo
>>> "test" > /dev/ttyS1 )
>>>
>>> In my head, the serialdriver should keep tx-interrupts enabled until a
>>> TX_DONE interrupt is received or closing the file descriptor.
>>>
>>>
>>>
>>>
>>> Den fre 21 feb. 2025 kl 15:07 skrev Alan C. Assis <ac...@gmail.com>:
>>>
>>>> Hi Erik,
>>>>
>>>> Could you please explain exactly what issue you are facing?
>>>>
>>>> AFAIK the software implementation just detects the UART_TX_DONE_INT_ST
>>>> interrupt and enables a GPIO to control the DE/RE pin of RS485 transceiver.
>>>>
>>>> I remember using it with FreeModbus and everything worked as expected,
>>>> but I never used it with "serialblaster" so not sure that could happen in
>>>> this case.
>>>>
>>>> If I understand correctly I think ttyS1 waveform is correct, probably
>>>> what seems slow is because normally we are using 38400 bps instead of
>>>> 115200 bps, what baud-rate are you using?
>>>>
>>>> BR,
>>>>
>>>> Alan
>>>>
>>>> On Fri, Feb 21, 2025 at 7:12 AM Erik Englund <er...@gmail.com>
>>>> wrote:
>>>>
>>>>> Sorry, meant the Xtensa ESP32, not C6.
>>>>>
>>>>> fre 21 feb. 2025 kl. 11:00 skrev Erik Englund <erik.englund@gmail.com
>>>>> >:
>>>>>
>>>>>> Allright!
>>>>>>
>>>>>> We tried the solution from ESP32-C6 but didnt manage to get it to
>>>>>> work correctly, i didnt like the part where it loops over and over again in
>>>>>> the interrupt until characters are sent (ofcourse it works when looping
>>>>>> until the buffer is empty, but we waste lots of cpu cycles, especially with
>>>>>> lower baudrates)
>>>>>> 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, while enabling/disabling interrupts for UART1.
>>>>>> Where ^ marks Enabling interrupts and _ marks disabling.
>>>>>> nsh> serialblaster /dev/ttyS1 100
>>>>>> Sending 100 bytes of data to /dev/ttyS1 (fd=3)
>>>>>> _^__^__^__^_nsh>
>>>>>>
>>>>>> It looks quite correct from the console but when checking the logic
>>>>>> analyzer we can see that it happens immediately after putting the data into
>>>>>> the txfifo and leaving with tx interrupts disabled.
>>>>>> 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 would require any modifications.
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>>
>>>>>> Den tis 18 feb. 2025 kl 21:01 skrev Alan C. Assis <acassis@gmail.com
>>>>>> >:
>>>>>>
>>>>>>> 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 <er...@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 <
>>>>>>>> acassis@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.englund@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.medicci@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.englund@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?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Erik,
If you want to test STM32F4Discovery I wrote a tutorial here:
https://embeddedrelated.com/showarticle/1715.php
BR,
Alan
On Fri, Feb 21, 2025 at 12:06 PM Erik Englund <er...@gmail.com>
wrote:
> No, I haven't checked with any other chips. I´ll see if I can do a test
> with stm32 or nrf52
>
> Den fre 21 feb. 2025 kl 15:42 skrev Alan C. Assis <ac...@gmail.com>:
>
>> Hi Erik,
>>
>> Thank you for explaining the issue! And for opening the issue to track it.
>>
>> I agree with you, the interrupt should be disabled just after
>> transmitting a character.
>>
>> BTW, did you check if this same side effect affects the STM32? I think
>> so, because I remember the DE/RE was enabled/disabled per character
>> transmitted.
>>
>> BR,
>>
>> Alan
>>
>> On Fri, Feb 21, 2025 at 11:36 AM Erik Englund <er...@gmail.com>
>> wrote:
>>
>>> Hi.
>>> I posted a Github Issue, to make it easier to track.
>>>
>>> The UART TX Interrupt is disabled by the serial driver (
>>> drivers/serial/serial.c ) after its done filling the txfifo, and thus we
>>> can never receive the UART_TX_DONE_INT_ST after the fifo has been filled by
>>> the driver.
>>> It only works by catchen an interrupt while we are still filling the
>>> fifo and then looping in the interrupt handler until all bytes are sent,
>>> essentially a busy loop in interrupt context.
>>>
>>> I guess that's why in arch/xtensa/src/esp32/esp32_serial.c, the logic is
>>> to loop for a maximum of 256 times before returning from the interrupt
>>> handler.
>>> It detects the TX_DONE interrupt, but thats just for one of the
>>> characters, not the complete transfer and requires the driver to loop until
>>> completion.
>>>
>>> Im using 9600 baud for communicating with an industrial device, so
>>> busylooping will take a considerable amount of the available cpu time.
>>>
>>> The serialblaster was just a test for transferring a bunch of data. The
>>> same behaviour is seen when just simply sending a string from nsh ( echo
>>> "test" > /dev/ttyS1 )
>>>
>>> In my head, the serialdriver should keep tx-interrupts enabled until a
>>> TX_DONE interrupt is received or closing the file descriptor.
>>>
>>>
>>>
>>>
>>> Den fre 21 feb. 2025 kl 15:07 skrev Alan C. Assis <ac...@gmail.com>:
>>>
>>>> Hi Erik,
>>>>
>>>> Could you please explain exactly what issue you are facing?
>>>>
>>>> AFAIK the software implementation just detects the UART_TX_DONE_INT_ST
>>>> interrupt and enables a GPIO to control the DE/RE pin of RS485 transceiver.
>>>>
>>>> I remember using it with FreeModbus and everything worked as expected,
>>>> but I never used it with "serialblaster" so not sure that could happen in
>>>> this case.
>>>>
>>>> If I understand correctly I think ttyS1 waveform is correct, probably
>>>> what seems slow is because normally we are using 38400 bps instead of
>>>> 115200 bps, what baud-rate are you using?
>>>>
>>>> BR,
>>>>
>>>> Alan
>>>>
>>>> On Fri, Feb 21, 2025 at 7:12 AM Erik Englund <er...@gmail.com>
>>>> wrote:
>>>>
>>>>> Sorry, meant the Xtensa ESP32, not C6.
>>>>>
>>>>> fre 21 feb. 2025 kl. 11:00 skrev Erik Englund <erik.englund@gmail.com
>>>>> >:
>>>>>
>>>>>> Allright!
>>>>>>
>>>>>> We tried the solution from ESP32-C6 but didnt manage to get it to
>>>>>> work correctly, i didnt like the part where it loops over and over again in
>>>>>> the interrupt until characters are sent (ofcourse it works when looping
>>>>>> until the buffer is empty, but we waste lots of cpu cycles, especially with
>>>>>> lower baudrates)
>>>>>> 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, while enabling/disabling interrupts for UART1.
>>>>>> Where ^ marks Enabling interrupts and _ marks disabling.
>>>>>> nsh> serialblaster /dev/ttyS1 100
>>>>>> Sending 100 bytes of data to /dev/ttyS1 (fd=3)
>>>>>> _^__^__^__^_nsh>
>>>>>>
>>>>>> It looks quite correct from the console but when checking the logic
>>>>>> analyzer we can see that it happens immediately after putting the data into
>>>>>> the txfifo and leaving with tx interrupts disabled.
>>>>>> 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 would require any modifications.
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>>
>>>>>> Den tis 18 feb. 2025 kl 21:01 skrev Alan C. Assis <acassis@gmail.com
>>>>>> >:
>>>>>>
>>>>>>> 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 <er...@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 <
>>>>>>>> acassis@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.englund@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.medicci@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.englund@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?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by Erik Englund <er...@gmail.com>.
No, I haven't checked with any other chips. I´ll see if I can do a test
with stm32 or nrf52
Den fre 21 feb. 2025 kl 15:42 skrev Alan C. Assis <ac...@gmail.com>:
> Hi Erik,
>
> Thank you for explaining the issue! And for opening the issue to track it.
>
> I agree with you, the interrupt should be disabled just after transmitting
> a character.
>
> BTW, did you check if this same side effect affects the STM32? I think so,
> because I remember the DE/RE was enabled/disabled per character transmitted.
>
> BR,
>
> Alan
>
> On Fri, Feb 21, 2025 at 11:36 AM Erik Englund <er...@gmail.com>
> wrote:
>
>> Hi.
>> I posted a Github Issue, to make it easier to track.
>>
>> The UART TX Interrupt is disabled by the serial driver (
>> drivers/serial/serial.c ) after its done filling the txfifo, and thus we
>> can never receive the UART_TX_DONE_INT_ST after the fifo has been filled by
>> the driver.
>> It only works by catchen an interrupt while we are still filling the fifo
>> and then looping in the interrupt handler until all bytes are sent,
>> essentially a busy loop in interrupt context.
>>
>> I guess that's why in arch/xtensa/src/esp32/esp32_serial.c, the logic is
>> to loop for a maximum of 256 times before returning from the interrupt
>> handler.
>> It detects the TX_DONE interrupt, but thats just for one of the
>> characters, not the complete transfer and requires the driver to loop until
>> completion.
>>
>> Im using 9600 baud for communicating with an industrial device, so
>> busylooping will take a considerable amount of the available cpu time.
>>
>> The serialblaster was just a test for transferring a bunch of data. The
>> same behaviour is seen when just simply sending a string from nsh ( echo
>> "test" > /dev/ttyS1 )
>>
>> In my head, the serialdriver should keep tx-interrupts enabled until a
>> TX_DONE interrupt is received or closing the file descriptor.
>>
>>
>>
>>
>> Den fre 21 feb. 2025 kl 15:07 skrev Alan C. Assis <ac...@gmail.com>:
>>
>>> Hi Erik,
>>>
>>> Could you please explain exactly what issue you are facing?
>>>
>>> AFAIK the software implementation just detects the UART_TX_DONE_INT_ST
>>> interrupt and enables a GPIO to control the DE/RE pin of RS485 transceiver.
>>>
>>> I remember using it with FreeModbus and everything worked as expected,
>>> but I never used it with "serialblaster" so not sure that could happen in
>>> this case.
>>>
>>> If I understand correctly I think ttyS1 waveform is correct, probably
>>> what seems slow is because normally we are using 38400 bps instead of
>>> 115200 bps, what baud-rate are you using?
>>>
>>> BR,
>>>
>>> Alan
>>>
>>> On Fri, Feb 21, 2025 at 7:12 AM Erik Englund <er...@gmail.com>
>>> wrote:
>>>
>>>> Sorry, meant the Xtensa ESP32, not C6.
>>>>
>>>> fre 21 feb. 2025 kl. 11:00 skrev Erik Englund <er...@gmail.com>:
>>>>
>>>>> Allright!
>>>>>
>>>>> We tried the solution from ESP32-C6 but didnt manage to get it to work
>>>>> correctly, i didnt like the part where it loops over and over again in the
>>>>> interrupt until characters are sent (ofcourse it works when looping until
>>>>> the buffer is empty, but we waste lots of cpu cycles, especially with lower
>>>>> baudrates)
>>>>> 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, while enabling/disabling interrupts for UART1.
>>>>> Where ^ marks Enabling interrupts and _ marks disabling.
>>>>> nsh> serialblaster /dev/ttyS1 100
>>>>> Sending 100 bytes of data to /dev/ttyS1 (fd=3)
>>>>> _^__^__^__^_nsh>
>>>>>
>>>>> It looks quite correct from the console but when checking the logic
>>>>> analyzer we can see that it happens immediately after putting the data into
>>>>> the txfifo and leaving with tx interrupts disabled.
>>>>> 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 would require any modifications.
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>>
>>>>> Den tis 18 feb. 2025 kl 21:01 skrev Alan C. Assis <ac...@gmail.com>:
>>>>>
>>>>>> 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 <er...@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 <acassis@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.englund@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.medicci@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.englund@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?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Erik,
Thank you for explaining the issue! And for opening the issue to track it.
I agree with you, the interrupt should be disabled just after transmitting
a character.
BTW, did you check if this same side effect affects the STM32? I think so,
because I remember the DE/RE was enabled/disabled per character transmitted.
BR,
Alan
On Fri, Feb 21, 2025 at 11:36 AM Erik Englund <er...@gmail.com>
wrote:
> Hi.
> I posted a Github Issue, to make it easier to track.
>
> The UART TX Interrupt is disabled by the serial driver (
> drivers/serial/serial.c ) after its done filling the txfifo, and thus we
> can never receive the UART_TX_DONE_INT_ST after the fifo has been filled by
> the driver.
> It only works by catchen an interrupt while we are still filling the fifo
> and then looping in the interrupt handler until all bytes are sent,
> essentially a busy loop in interrupt context.
>
> I guess that's why in arch/xtensa/src/esp32/esp32_serial.c, the logic is
> to loop for a maximum of 256 times before returning from the interrupt
> handler.
> It detects the TX_DONE interrupt, but thats just for one of the
> characters, not the complete transfer and requires the driver to loop until
> completion.
>
> Im using 9600 baud for communicating with an industrial device, so
> busylooping will take a considerable amount of the available cpu time.
>
> The serialblaster was just a test for transferring a bunch of data. The
> same behaviour is seen when just simply sending a string from nsh ( echo
> "test" > /dev/ttyS1 )
>
> In my head, the serialdriver should keep tx-interrupts enabled until a
> TX_DONE interrupt is received or closing the file descriptor.
>
>
>
>
> Den fre 21 feb. 2025 kl 15:07 skrev Alan C. Assis <ac...@gmail.com>:
>
>> Hi Erik,
>>
>> Could you please explain exactly what issue you are facing?
>>
>> AFAIK the software implementation just detects the UART_TX_DONE_INT_ST
>> interrupt and enables a GPIO to control the DE/RE pin of RS485 transceiver.
>>
>> I remember using it with FreeModbus and everything worked as expected,
>> but I never used it with "serialblaster" so not sure that could happen in
>> this case.
>>
>> If I understand correctly I think ttyS1 waveform is correct, probably
>> what seems slow is because normally we are using 38400 bps instead of
>> 115200 bps, what baud-rate are you using?
>>
>> BR,
>>
>> Alan
>>
>> On Fri, Feb 21, 2025 at 7:12 AM Erik Englund <er...@gmail.com>
>> wrote:
>>
>>> Sorry, meant the Xtensa ESP32, not C6.
>>>
>>> fre 21 feb. 2025 kl. 11:00 skrev Erik Englund <er...@gmail.com>:
>>>
>>>> Allright!
>>>>
>>>> We tried the solution from ESP32-C6 but didnt manage to get it to work
>>>> correctly, i didnt like the part where it loops over and over again in the
>>>> interrupt until characters are sent (ofcourse it works when looping until
>>>> the buffer is empty, but we waste lots of cpu cycles, especially with lower
>>>> baudrates)
>>>> 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, while enabling/disabling interrupts for UART1.
>>>> Where ^ marks Enabling interrupts and _ marks disabling.
>>>> nsh> serialblaster /dev/ttyS1 100
>>>> Sending 100 bytes of data to /dev/ttyS1 (fd=3)
>>>> _^__^__^__^_nsh>
>>>>
>>>> It looks quite correct from the console but when checking the logic
>>>> analyzer we can see that it happens immediately after putting the data into
>>>> the txfifo and leaving with tx interrupts disabled.
>>>> 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 would require any modifications.
>>>>
>>>> [image: image.png]
>>>>
>>>>
>>>> Den tis 18 feb. 2025 kl 21:01 skrev Alan C. Assis <ac...@gmail.com>:
>>>>
>>>>> 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 <er...@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 <acassis@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.englund@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.medicci@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.englund@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?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by Erik Englund <er...@gmail.com>.
Hi.
I posted a Github Issue, to make it easier to track.
The UART TX Interrupt is disabled by the serial driver (
drivers/serial/serial.c ) after its done filling the txfifo, and thus we
can never receive the UART_TX_DONE_INT_ST after the fifo has been filled by
the driver.
It only works by catchen an interrupt while we are still filling the fifo
and then looping in the interrupt handler until all bytes are sent,
essentially a busy loop in interrupt context.
I guess that's why in arch/xtensa/src/esp32/esp32_serial.c, the logic is to
loop for a maximum of 256 times before returning from the interrupt handler.
It detects the TX_DONE interrupt, but thats just for one of the characters,
not the complete transfer and requires the driver to loop until completion.
Im using 9600 baud for communicating with an industrial device, so
busylooping will take a considerable amount of the available cpu time.
The serialblaster was just a test for transferring a bunch of data. The
same behaviour is seen when just simply sending a string from nsh ( echo
"test" > /dev/ttyS1 )
In my head, the serialdriver should keep tx-interrupts enabled until a
TX_DONE interrupt is received or closing the file descriptor.
Den fre 21 feb. 2025 kl 15:07 skrev Alan C. Assis <ac...@gmail.com>:
> Hi Erik,
>
> Could you please explain exactly what issue you are facing?
>
> AFAIK the software implementation just detects the UART_TX_DONE_INT_ST
> interrupt and enables a GPIO to control the DE/RE pin of RS485 transceiver.
>
> I remember using it with FreeModbus and everything worked as expected, but
> I never used it with "serialblaster" so not sure that could happen in this
> case.
>
> If I understand correctly I think ttyS1 waveform is correct, probably what
> seems slow is because normally we are using 38400 bps instead of 115200
> bps, what baud-rate are you using?
>
> BR,
>
> Alan
>
> On Fri, Feb 21, 2025 at 7:12 AM Erik Englund <er...@gmail.com>
> wrote:
>
>> Sorry, meant the Xtensa ESP32, not C6.
>>
>> fre 21 feb. 2025 kl. 11:00 skrev Erik Englund <er...@gmail.com>:
>>
>>> Allright!
>>>
>>> We tried the solution from ESP32-C6 but didnt manage to get it to work
>>> correctly, i didnt like the part where it loops over and over again in the
>>> interrupt until characters are sent (ofcourse it works when looping until
>>> the buffer is empty, but we waste lots of cpu cycles, especially with lower
>>> baudrates)
>>> 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, while enabling/disabling interrupts for UART1.
>>> Where ^ marks Enabling interrupts and _ marks disabling.
>>> nsh> serialblaster /dev/ttyS1 100
>>> Sending 100 bytes of data to /dev/ttyS1 (fd=3)
>>> _^__^__^__^_nsh>
>>>
>>> It looks quite correct from the console but when checking the logic
>>> analyzer we can see that it happens immediately after putting the data into
>>> the txfifo and leaving with tx interrupts disabled.
>>> 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 would require any modifications.
>>>
>>> [image: image.png]
>>>
>>>
>>> Den tis 18 feb. 2025 kl 21:01 skrev Alan C. Assis <ac...@gmail.com>:
>>>
>>>> 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 <er...@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 <ac...@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 <er...@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.medicci@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.englund@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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Erik,
Could you please explain exactly what issue you are facing?
AFAIK the software implementation just detects the UART_TX_DONE_INT_ST
interrupt and enables a GPIO to control the DE/RE pin of RS485 transceiver.
I remember using it with FreeModbus and everything worked as expected, but
I never used it with "serialblaster" so not sure that could happen in this
case.
If I understand correctly I think ttyS1 waveform is correct, probably what
seems slow is because normally we are using 38400 bps instead of 115200
bps, what baud-rate are you using?
BR,
Alan
On Fri, Feb 21, 2025 at 7:12 AM Erik Englund <er...@gmail.com> wrote:
> Sorry, meant the Xtensa ESP32, not C6.
>
> fre 21 feb. 2025 kl. 11:00 skrev Erik Englund <er...@gmail.com>:
>
>> Allright!
>>
>> We tried the solution from ESP32-C6 but didnt manage to get it to work
>> correctly, i didnt like the part where it loops over and over again in the
>> interrupt until characters are sent (ofcourse it works when looping until
>> the buffer is empty, but we waste lots of cpu cycles, especially with lower
>> baudrates)
>> 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,
>> while enabling/disabling interrupts for UART1.
>> Where ^ marks Enabling interrupts and _ marks disabling.
>> nsh> serialblaster /dev/ttyS1 100
>> Sending 100 bytes of data to /dev/ttyS1 (fd=3)
>> _^__^__^__^_nsh>
>>
>> It looks quite correct from the console but when checking the logic
>> analyzer we can see that it happens immediately after putting the data into
>> the txfifo and leaving with tx interrupts disabled.
>> 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 would require any modifications.
>>
>> [image: image.png]
>>
>>
>> Den tis 18 feb. 2025 kl 21:01 skrev Alan C. Assis <ac...@gmail.com>:
>>
>>> 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 <er...@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 <ac...@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 <er...@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.medicci@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.englund@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?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by Erik Englund <er...@gmail.com>.
Sorry, meant the Xtensa ESP32, not C6.
fre 21 feb. 2025 kl. 11:00 skrev Erik Englund <er...@gmail.com>:
> Allright!
>
> We tried the solution from ESP32-C6 but didnt manage to get it to work
> correctly, i didnt like the part where it loops over and over again in the
> interrupt until characters are sent (ofcourse it works when looping until
> the buffer is empty, but we waste lots of cpu cycles, especially with lower
> baudrates)
> 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,
> while enabling/disabling interrupts for UART1.
> Where ^ marks Enabling interrupts and _ marks disabling.
> nsh> serialblaster /dev/ttyS1 100
> Sending 100 bytes of data to /dev/ttyS1 (fd=3)
> _^__^__^__^_nsh>
>
> It looks quite correct from the console but when checking the logic
> analyzer we can see that it happens immediately after putting the data into
> the txfifo and leaving with tx interrupts disabled.
> 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
> would require any modifications.
>
> [image: image.png]
>
>
> Den tis 18 feb. 2025 kl 21:01 skrev Alan C. Assis <ac...@gmail.com>:
>
>> 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 <er...@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 <ac...@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 <er...@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.medicci@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.englund@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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by Erik Englund <er...@gmail.com>.
Allright!
We tried the solution from ESP32-C6 but didnt manage to get it to work
correctly, i didnt like the part where it loops over and over again in the
interrupt until characters are sent (ofcourse it works when looping until
the buffer is empty, but we waste lots of cpu cycles, especially with lower
baudrates)
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,
while enabling/disabling interrupts for UART1.
Where ^ marks Enabling interrupts and _ marks disabling.
nsh> serialblaster /dev/ttyS1 100
Sending 100 bytes of data to /dev/ttyS1 (fd=3)
_^__^__^__^_nsh>
It looks quite correct from the console but when checking the logic
analyzer we can see that it happens immediately after putting the data into
the txfifo and leaving with tx interrupts disabled.
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
would require any modifications.
[image: image.png]
Den tis 18 feb. 2025 kl 21:01 skrev Alan C. Assis <ac...@gmail.com>:
> 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 <er...@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 <ac...@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 <er...@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.medicci@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.englund@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?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by "Alan C. Assis" <ac...@gmail.com>.
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 <er...@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 <ac...@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 <er...@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.medicci@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.englund@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?
>>>>>
>>>>>
>>>>>
>>>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by Erik Englund <er...@gmail.com>.
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 <ac...@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 <er...@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.medicci@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.englund@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?
>>>>
>>>>
>>>>
>>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by "Alan C. Assis" <ac...@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 <er...@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.medicci@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.englund@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?
>>>
>>>
>>>
>>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by Erik Englund <er...@gmail.com>.
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.medicci@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 <er...@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?
>>
>>
>>
>>
Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol
Posted by Tiago Medicci Serrano <ti...@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 <er...@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?
>
>
>
>