00:17 <sajattack[m]1> Is there a better way to share data between interrupts than static mut or not really?

00:17 <sajattack[m]1> Rtic probably has something fancy I guess

00:18 <adamgreig[m]> RTIC is the something fancy, really

00:18 <sajattack[m]1> Ok thx

00:18 <adamgreig[m]> if you just want to share little data, Atomics are really nice

00:18 <adamgreig[m]> like, up to a u32

00:19 <sajattack[m]1> It's funny I've done a lot on the hal side but not a lot on the applications side and I finally have a good excuse to learn all this stuff

00:19 <adamgreig[m]> you can use a critical_section::Mutex<RefCell<T>> in a `static` to avoid needing a literal `static mut`, too https://docs.rs/critical-section/latest/critical_section/struct.Mutex.html

00:23 <sajattack[m]1> And suppose I have a driver struct that defines the structs, data, and methods it needs, how do I work that into rtic? Like I vaguely recal rtic apps have resources or something. How does it work for a generic driver to define what it wants from rtic? Or is it just a matter of making the resource a parameter of the ISR?

00:27 <adamgreig[m]> if you have a driver struct and the user wants to interact with it from both an interrupt and some other interrupt or the main thread, the user can put that driver struct into a resource and rtic will allow them to access it from those different places

00:27 <adamgreig[m]> so the driver just has one struct and maybe it has a method like "call me from this interrupt" and "call me in your main loop" or whatever

00:31 <sajattack[m]1> yeah that's kinda what I was thinking too - but what I'm thinking about is how to define the shared mutable state. Maybe it can just be part of the struct. But usually static mut's can't be part of a struct.

00:31 <adamgreig[m]> can't you just put it directly inside the struct?

00:32 <sajattack[m]1> probably that's what I'm asking

00:32 <adamgreig[m]> you can't put a static mut inside the struct, but you can just put data inside the struct

00:32 <sajattack[m]1> yeah nevermind I'm dumb

00:32 <adamgreig[m]> there's potentially some downsides if it's like 1kB+ of data, because it might end up moved around on the stack a bit to get to its final place

00:33 <adamgreig[m]> if you don't want to store the data inside the driver struct, take a `&'static mut Data` in your constructor, and let the user worry about providing it somehow (rtic can help)

00:33 <sajattack[m]1> thanks

01:43 <JamesMunns[m]> <adamgreig[m]> "if you don't want to store the..." <- Or the singleton macro in cmrt, or StaricCell

01:43 <JamesMunns[m]> s/StaricCell/StaticCell/

07:44 <Dr_Viper[m]> I want to learn rust

09:49 <JamesMunns[m]> Any Tools team members around? Could I poke anyone into doing a release of cargo-binutils when they get a chance? Just got a ping on https://github.com/rust-embedded/cargo-binutils/issues/139#issuecomment-1818519665 which seems to be fixed but not released

10:30 <jamwaffles[m]> Hey all, is there an `async` equivalent of [embedded-io](https://docs.rs/embedded-io/latest/embedded_io/)? Maybe something in Embassy? I'd like to provide an async reader trait bound to something so I can abstract over a real device or a mock in my unit tests. Nightly is ok.

10:30 <dirbaio[m]> embedded-io-async

10:31 <diondokter[m]> It's in the same repo: https://github.com/rust-embedded/embedded-hal

10:31 <jamwaffles[m]> Ah I knew I'd seen it somewhere. Thank you!

11:07 <rukai[m]> <M9names[m]> "https://github.com/dlkj/usbd-..."; <- This was exactly what I needed, thanks! I swapped out keyberons USB keyboard parts with this crate and then was able to add a mouse device and got it all working together.

14:52 <ducks2788[m]> Hi. I have a question: If I try to deserialize invalid json with serde and use `unwrap`, my app panics and prints a message. Instead of panic'ing, I want print this error message:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VNpoaqUjXMykUsGtuysSlGcM>)

14:56 <JamesMunns[m]> https://defmt.ferrous-systems.com/format discusses this

15:27 <ducks2788[m]> I'll have a look on this. Thank you.