You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The clock API could potentially be completely platform-independent and live in embedded-hal. Before that can happen, we should review and improve the design.
Here are a few improvements I can think of:
Frequency should have an associated type Freq. Frequency::hz would return Self::Freq instead of u32.
There should be an additional trait, Clock, that defines an associated type, Ticks. This type would be used for value in the Ticks struct, as u32 is not appropriate for all platforms.
Maybe it would be a good idea to add some more use cases before the clock API is submitted. The current clocks are pretty simple, as they have a constant frequency. Some ideas for additional use cases:
The external WKT clock, as that's fed into the microcontroller via a pin.
The UART clock, as that needs to deal with configurable frequencies.
The text was updated successfully, but these errors were encountered:
The clock API could potentially be completely platform-independent and live in embedded-hal. Before that can happen, we should review and improve the design.
Here are a few improvements I can think of:
Frequency
should have an associated typeFreq
.Frequency::hz
would returnSelf::Freq
instead ofu32
.Clock
, that defines an associated type,Ticks
. This type would be used forvalue
in theTicks
struct, asu32
is not appropriate for all platforms.Maybe it would be a good idea to add some more use cases before the clock API is submitted. The current clocks are pretty simple, as they have a constant frequency. Some ideas for additional use cases:
The text was updated successfully, but these errors were encountered: