Skip to content

Conversation

i404788
Copy link
Contributor

@i404788 i404788 commented Jul 15, 2025

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:

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

Copy link
Contributor

@bugadani bugadani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

}

/// Enable RS485 mode
pub fn with_rs485(self) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • 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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay apparently DTR/DSR are not available in the hardware

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

bugadani and others added 18 commits July 22, 2025 15:25
Adds the `rt` feature which disables `esp_hal::init` and removes
runtime symbols from the global name space.

Disabling the `rt` feature is the recommended way to use esp-hal as a
library.
* Clean up unnecessary unsafe code

* Do not print level of unhandled interrupt

* Remove transmutes

* Changelog
* Finalize crate releases

* changelog fixup

* fixup docsrs ci test

* docs fixup
* xtask: add metadata check

Adds a check for metadata changes to the xtask `update-metadata` task.

* ci: add metadata check to the `ci` workflow

Adds a check for uncommitted metadata changes to the `ci` workflow.
* Clean up unnecessary lint allows

* Clean up some unnecessary lints
* Add assign_resources

* Mark unstable
* Clean up with new PAC

* Allow configuring longer WDT periods

* Enable WDT after updating timeout
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants