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
When writing a driver for some device (say a motor driver) and attempt to program against the trait's in the embedded-hal you can run into issues when using a peripheral that requires types defined in time.rs.
Because of this the driver now has a dependency on the stm32f3xx-hal device crate.
This of course is unwanted as it would be nice to create a generic device driver that doesn't depend on any specific device crate.
Example:
pub struct Driver<T>
where
T: CountDown
{
timer: T,
}
impl<T> Driver<T>
where
T: CountDown
{
pub fn new( timer: T ) -> Self { Driver { timer } }
pub fn start( &self ) {
self.timer.start( /* This requires Hertz which is defined in time.rs of the stm32f3xx-hal crate */ );
}
}
Instead of using the units/functionality defined in time.rs could the units/functionality defined in embedded-time be used instead? This would allow for a truly generic driver (assuming other device crates got on board).
This is probably more of community issue as a lot of device crates use their own custom time.rs implementation.
Below are two issues regarding this for the embedded-hal crate.
It sounded like the consensus was to have device crates get on board with using some centralized source for using time based units and functionality.
When writing a driver for some device (say a motor driver) and attempt to program against the
trait
's in the embedded-hal you can run into issues when using aperipheral
that requires types defined in time.rs.Because of this the driver now has a dependency on the
stm32f3xx-hal
device crate.This of course is unwanted as it would be nice to create a
generic
device driver that doesn't depend on any specific device crate.Example:
Instead of using the units/functionality defined in time.rs could the units/functionality defined in embedded-time be used instead? This would allow for a truly generic driver (assuming other device crates got on board).
This is probably more of community issue as a lot of device crates use their own custom
time.rs
implementation.Below are two issues regarding this for the embedded-hal crate.
It sounded like the consensus was to have device crates get on board with using some centralized source for using time based units and functionality.
embedded-hal #221
embedded-hal #59
The text was updated successfully, but these errors were encountered: