Open eldruin opened 2 years ago
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 embedded-hal
provides unified interfaces across the ecosystem for very common peripherals, where it makes sense.
It should be noted that these traits are implemented in many HALs, including all(?) stm32 HALs, atsamd, esp8266 and esp32, so people must have seen some value on them as well.
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:
nrf doesn't fit the model of the traits at all, so neither embassy-nrf nor nrf-hal impl the traits. nrf's watchdog has multiple "channels", you enable all channels at once with the same timeout, then have to pet all enabled channels.
esp8266 has type Time = (StageTimeout, StageTimeout);
with funny Into
impls because they want to give some flexibility to the user what to pass in because their watchdog has multiple "stages" you can enable/disable: "You can provide the time period either as a value in [Milliseconds
] or [Seconds
], a single StageTimeOut
or a pair of StageTimeout
". It would make more sense for the HAL to have a HAL-specific API exposing all the details of the hardware like nrf does, instead of doing weird stuff to fit the trait.
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:
211
122
59
24
75
Please feel free to participate, highlight your current use cases, problems and provide solutions.