00:22 <spikespaz[m]> What is the current recommendation about using `embedded_hal_bus`? Should device drivers hold an `Arc<Mutex<T>>` where `T: I2c` or just hold an `impl I2c` and use `embedded-hal-bus` in client code?

00:56 <dirbaio[m]> The latter.

05:25 <spikespaz[m]> I want to create an Instant in library code and would like to hear if there is a "best" crate that provides a platform-agnostic clock or a trait for it. I see many unpopular options, and embedded_timers looks like a thoughtful API, but has a strange license and is without an async version.

06:21 <cbjamo[m]> If you can, I strongly recommend not using instants and instead using something that impls the DelayNs trait.

06:21 <cbjamo[m]> If you can't use delays, and are using async, embassy-time is the way to go. The only painful part of using embassy-time is that there can only be one version in the dependency tree so everyone has to stay in lockstep.

09:37 <ryan-summers[m]> <spikespaz[m]> "I want to create an Instant in..." <- Both `embedded-time` and `fugit` provide valueable abstractions for managing time on embedded platforms. The actual clock implementation is going to be derived from your HAL though

09:37 <ryan-summers[m]> I'd probably go with fugit nowadays because embedded-time's maintainer disappeared after the library released

10:10 <M9names[m]> I feel like I'm missing something in this question, does Instant mean something different than a point in time? how do you have an async API around that?

11:12 <ryan-summers[m]> Maybe the desire is an async Duration::from_millis(100).await?

11:12 <ryan-summers[m]> In which case, yeah probably you want embassy or RTIC for that

16:44 <starblue[m]> In Embassy: Timer::at(instant).await

16:44 <starblue[m]> Duration and Instant themselves are just data.

19:11 <spikespaz[m]> <ryan-summers[m]> "I'd probably go with fugit..." <- What about using `embassy-time` instead, and implementing the `embassy_time_driver` myself?s

19:21 <spikespaz[m]> <M9names[m]> "I feel like I'm missing somethin..." <- The goal is to make this function `no_std`. I am focused on the sync version of this library code, but also want to create an `async` version.... (full message at <https://catircservices.org/_irc/v1/media/download/AZbuRa1zi3Qj8nwDqiBhf0qzY6-_W0zx-QX8ssvwpCc8rwSBZI_aMgfXB6DG2g5Ug2F2OPYoMLtzJ2sPRdOmPlK_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9DSUNvSkdneVhRYkVjVEVvclVpWm1EVFo>)

19:21 <spikespaz[m]> Ideally I can share a lot of code. I'm not sure how nb plays into this, it looks like a hack.

20:41 <dngrs[m]> nb used to be a popular approach for manual async programming

20:41 <dngrs[m]> haven't seen it around much in a long time

22:03 <spikespaz[m]> It describes it as a pattern to write code that can be adapted for either sync/async library code. Is that not the case anymore? I thought I would be able to create a dummy API that wraps functions returning nb::Result to behave somewhat reasonably with async, where the returned future just represents the status of nb::Error::WouldBlock as NotReady.

23:19 <M9names[m]> <spikespaz[m]> "What about using `embassy-time..." <- usually embassy_time_driver is implemented in a HAL. your library shouldn't get involved with that, but you could implement it in your binary crate.... (full message at <https://catircservices.org/_irc/v1/media/download/AT76mnIEtVBHX7oXXahJ2kWdMRl0G5zCkOl0svFkCq1TLqNQTIBCd8VtIA3GbGgZFCggIIJPgYE1oRFpXlS9cOW_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy90bEtFY1pudVhaeXJHd0Nyak9oQ1VUeWo>)

23:20 <spikespaz[m]> M9names[m]: Can `embassy_time` be used without using the Embassy executor and the rest of the framework? I just want the time features, but when I try to enable the `std` feature for the `embassy_time_driver` in my tests, I get failures for missing extern functions.

23:21 <M9names[m]> yes, you can use embassy-time without embassy-executor (with the generic-queue feature)

23:22 <M9names[m]> https://docs.rs/embassy-time/latest/embassy_time/#generic-queue