<JamesMunns[m]>
I don't think so, if you need to return something that is `'static`, then having the input be `'static` is about all you can do without heap allocation
<JamesMunns[m]>
most of the time, that just requires that the error is owned, so unless you're borrowing any of the input or part of the device itself, that won't be too big of a deal
davidmpye[m] has quit [Quit: Idle timeout reached: 172800s]
ska has joined #rust-embedded
<mrpashapg[m]>
If I modify two libraries that currently use embedded-hal::i2c and reimplement them using embedded-hal-async::i2c, would I be able to provide them with an instance of embassy-embedded-hal::shared_bus::asynch::i2c::I2cDeviceWithConfig?
<mrpashapg[m]>
What raised my doubt is that while embedded-hal-async has SpiDevice and SpiBus structures, I noticed it doesn't have corresponding I2cDevice and I2cBus implementations!
KevinPFleming[m] has quit [Quit: Idle timeout reached: 172800s]
DominicFischer[m has joined #rust-embedded
<DominicFischer[m>
(There's an embassy room to ask this in). Yes, I2c can be shared without the whole bus/device split.
<M9names[m]>
also: if you're not familiar with rust, lots of crates take a long time to get to 1.0. and are basically stable for years before that happens.
<M9names[m]>
i think it's not as bad as it used to be but it used to be a bit of a meme that the most depended on crates were never 1.0
<andreas-leitner[>
Thats good to know :D - thanks alot.
<andreas-leitner[>
So I will implement the embedded-io traits, and ignore the embedded-hal-nb traits :)
<diondokter[m]>
Yeah, I've become more chill about marking things 1.0
<diondokter[m]>
Even though it doesn't matter in semver, but the first 2.0 always hurts a little bit :P
<diondokter[m]>
s/but//
jason-kairos[m] has quit [Quit: Idle timeout reached: 172800s]
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #rust-embedded
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #rust-embedded
jfsimon1981 has quit [Remote host closed the connection]
phycrax[m] has quit [Quit: Idle timeout reached: 172800s]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
jfsimon has quit [Max SendQ exceeded]
jfsimon has joined #rust-embedded
GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]>
<andreas-leitner[> Thats good to know :D - thanks alot....
<Ralph[m]>
just FYI: `embassy-stm32` implements the `embedded-io` traits; you might want to look into that rather than the `stm32h7xx-hal` (i'm not familiar with the latter - i've used `stm32f4xx-hal` before, though) - and the pros/cons of different HALs partially feel like religious discussions now 🤷)
wassasin[m] has quit [Quit: Idle timeout reached: 172800s]
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
sroemer has quit [Quit: WeeChat 4.5.2]
HumanG331 has quit [Ping timeout: 248 seconds]
<M9names[m]>
<Ralph[m]> just FYI: `embassy-stm32` implements the `embedded-io` traits; you might want to look into that rather than the `stm32h7xx-hal` (i'm not familiar with the latter - i've used `stm32f4xx-hal` before, though) - and the pros/cons of different HALs partially feel like religious discussions now 🤷)
<M9names[m]>
Have you considered that maybe the way you're talking about these projects here is contributing to that "us and them" situation?