-
Notifications
You must be signed in to change notification settings - Fork 344
Add HW DTR support (port of #2994) #3796
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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
Submission Checklist 📝
cargo xtask fmt-packages
command to ensure that all changed code is formatted correctly.CHANGELOG.md
in the proper section.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