feat: uart tx software break

[zpg6]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

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 API guidelines

Extra:

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

Pull Request Details 📖

Description

Accidentally closed #2872 trying to update my fork --

Adding ability to send a software break on the UART TX line. This is achieved by inverting the TX line, waiting some time, and then reverting the line back. The duration to leave it inverted (the break duration) is kept in bit time - the time it takes to send one bit at the current baud rate.

Testing

Ongoing

[zpg6]

As in #2872 - I would like to add a send_break_async function, but I don't think there is precedence for async delays within one of the HAL drivers. But I think better if saved for another PR later.

In the meantime this and #2858 can be reviewed as a pair.

[MabezDev]

Thanks for sticking with this! It's closer to ready, but still needs some changes.

Regarding async break, I'm not sure how to handle it. This way of breaking, which I now understand is required thanks to your comment in the old PR, isn't that friendly to async as we can't set an interrupt to detect when the break is done. Not sure how to go about this just yet, so I think you're right to leave the async version out for now.

Regarding the separate PRs, I suggest you fold the RX side of this (#2858) into here. Along with the test suggestions I've already made, it'll be good to test that each side can transmit and receive a break from the same uart peripheral.

[MabezDev]

This test is inadequate, we need something to check the signals coming from the UART TX line. We usually use PCNT or RMT for this purpose, check out some of the other tests.

[zpg6]

This is just for the examples/ to demonstrate the usage, where would the test go?

[MabezDev]

Ah sorry, I didn't quite release what I was looking at 😅 . Take a look at the hil-test package, writing tests there will run them on the esp's we have in our server room. The README in there should explain most things, and looking at the tests for inspiration should help too.

[zpg6]

When I fold the break interrupt PR into this, I'll HIL test the two together as well.

[zpg6]

TODO

• Fold feat: uart break detection interrupt #2858 (receiving breaks) into this PR
• HIL test sending a break and receiving on the same UART
• Investigate additional HIL tests to indirectly verify the break
• Consolidate the examples/ (total of 4) for best demonstration of the new features for send/recv breaks.
• Mark any functions as unstable as needed

[bugadani]

I would strongly prefer not emulating this with a delay and flipping TXD. The hardware is capable of generating at least a limited length of break condition, we should try to get that working.

• If you use 1Mbaud or above, send_break just returns immediately
• There is no good way to implement this asynchronously.
• You need to read back the original value of txd_inv instead of assuming it started from false.
• Depending on external factors, the break may be MUCH longer than you want. Is that okay in general?

[zpg6]

@bugadani

• If you use 1Mbaud or above, send_break just returns immediately
  • Good point, let me revisit that impl
• There is no good way to implement this asynchronously
  • I agree
• You need to read back the original value of txd_inv instead of assuming it started from false.
  • I hadn't considered this, would you like to see this change made?
• Depending on external factors, the break may be MUCH longer than you want. Is that okay in general?
  • The simple answer is "probably depends on the use case for breaking". But can you provide some examples of the external factors you mean?