-
Notifications
You must be signed in to change notification settings - Fork 201
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
Tracking issue for watchdog traits #360
Comments
What's the use case for a HAL-independent watchdog trait? HAL-independent drivers for external chips have no use for the watchdog. Watchdog is something inherently MCU-wide (it forces a whole MCU reset when expired). Therefore, it's something that the main bin crate will do. In the main binary, you know which HAL you're using, so you can just use a HAL-specific API (inherent methods, no trait). |
While not the primary goal of this crate, in my opinion it is also useful if |
HALs implement the traits to tick boxes. "The chip has a watchdog and EH has a watchdog trait, so I should impl it". Then users use it because many HALs don't offer an API with inherent methods at all. There's no HAL independent code out there using the traits. Also, I would argue the traits are failing at providing a unified API as well:
|
The watchdog traits available on the 0.2.x versions have been removed ahead of the 1.0.0 release. See: #357
This issue servers as a tracking issue until we add them back. The open (breaking) problems should be reasonably-well solved and all associated types should have appropriate bounds that enable generic code use.
Timer traits as of the 0.2.7 release:
Relevant issues/PRs:
Please feel free to participate, highlight your current use cases, problems and provide solutions.
The text was updated successfully, but these errors were encountered: