Closed jhodapp closed 2 years ago
Hmmm, you might be right that i went too fast witth the EH version. Would something like this get you out of trouble for now?
pub struct MyDelay(cortex_m::delay::Delay);
impl embedded_hal::delay::blocking::DelayUs for MyDelay {
type Error = core::convert::Infallible;
fn delay_us(&mut self, us: u32) -> Result<(), Self::Error> {
self.0.delay_us(us);
Ok(())
}
fn delay_ms(&mut self, ms: u32) -> Result<(), Self::Error> {
self.0.delay_ms(ms);
Ok(())
}
}
And then:
let mut delay = MyDelay(cortex_m::delay::Delay::new(cx.core.SYST, 10000000)); Whatever your clock is
Thanks a good suggestion. Let me try this out and I'll let you know if it'll work as a solution for now.
@VersBinarii This works well for me, thank you for suggesting it. This is no longer an issue for me using the latest bme280 crate in my project.
In trying to bring along an embedded Rust application that I'm working on to the latest bme280-rs crate version, I can no longer get this working due to the particular DelayUs trait required by the rp2040-hal.
So my suggestion is to have the crate still utilize embedded-hal-0.2.7 but then have an experimental feature flag to utilize the 1.0.0-alpha.X series, at least until the 1.0.0 releases.
I'm running into the following issue that I can't quite seem to resolve otherwise. If there is a way to work around this I'd love to know, otherwise I submit my suggestion above which is exactly the approach that the rp2040-hal project has gone with.