Add HW DTR support (port of #2994)

[i404788]

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• I have added necessary changes to user code to the Migration Guide.
• My changes are in accordance to the esp-rs developer guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

This is a port of #2994 for mainline (1.0.0-beta1).

Testing

Currently test it on a board to control an RS485 transceiver chip

[bugadani]

It's somewhat unclear to me what we are supposed to do with ESP32 :/

[bugadani]

• needs to be unstable (if you keep it)
• should be called into_rs485 and there is no way to disable it, either (if you keep it).
• Maybe this function should be turned into a Config struct field? All other configuration is set there.
• I'm still not sure we want to shoehorn RS485 into the main UART driver. Given that this is pretty minor and also unstable, maybe we can, for now.

[MabezDev]

Maybe this function should be turned into a Config struct field? All other configuration is set there.

I don't know nearly enough about rs485, but I think I agree here. Especially when you think about how to turn it off. We already have options, like hardware flow control, which have a config setting and require pins to be passed. I think we should follow this pattern.

I'm still not sure we want to shoehorn RS485 into the main UART driver. Given that this is pretty minor and also unstable, maybe we can, for now.

I agree, that we can experiment with this as an unstable API and figure out if it needs to be a separate driver.

[bugadani]

Okay apparently DTR/DSR are not available in the hardware

[i404788]

All fair points, I'm currently still testing it out after porting #2994. I think putting it in the Uart driver makes sense given the reference manual, but I'm not against something like an Rs485<'a, T: Uart> but either way you need to access the Uart registers.

[github-actions]

New commits in main has made this PR unmergable. Please resolve the conflicts.

[mchodzikiewicz]

Hey,

I am very interested in reviving this branch or exposing this feature anyhow, RS485 with a decent baudrate (like a standard 115200) is basically unusable without hardware direction control when using it within embassy.

I tried a bunch of stuff, like:

• running the RS485 communication from a dedicated Interrupt executor, but flush() is completed when the FIFO is empty, so there still is one byte on the line
• adding arbitrary block_for() to prevent yielding that flushing introduces but it is very finnicky and depends on the baudrate, parity, stopbits and the length of the message

the window to change direction is about 100us for 115200 baudrate and it is not uncommon to run smaller RS485 buses with a 1Mbit and more.

Given my prior experience with RS485 on much older chips, I guess this can also be done in software if the bare interrupt handler takes responsibility for the direction (this could be any GPIO instead of DTR then), if that's the only way to create a uniform behavior across the chip family.

I'd be happy to implement this feature in my spare time as I need this for my hobby project but let me know if it should be a config or a builder.

I am leaning slightly towards the builder pattern as you need to asign the DTR pin, since RS485 is not using DTR strictly in the same way traditional serial port uses it, it would be a leaky abstraction. Given that there are .with_tx(), with_rx(), etc, I think .with_rs485_dir() would've given me the least surprise.

(not that this is a big argument, but in fact I had a small LLM ideation session on how to hotfix my issue and it hallucinated that this method is already there)