05:37 <i509vcb[m]> For embedded, has anyone found some reasonable way to write both an async and blocking API in such a fashion that you are not literally duplicating all the code. Something somewhat like maybe-async used over in std land would be interesting for embedded: https://github.com/fMeow/maybe-async-rs

05:39 <i509vcb[m]> However embedded I assume is complicated here a bit because something like embedded-hal (non async) has no way to wait nessecarily which would involve writing the code twice...

05:59 <i509vcb[m]> embedded-hal-nb seems to be closest to that

10:42 <GuineaWheek[m]> i really wish cargo supported having different runners based on feature flags -- target triple isn't sufficient

10:53 <Gnome[m]> Is there any blockers for a new release to riscv-rt-macros? There was a merged PR from a little bit ago that swapped over to syn 2 and I'm on a crusade to remove syn 1 from my dependency tree... even though I'm using an xtensa chip it still shows up in my Cargo.lock (I know, silly, but that's my motivation).

12:24 <dirbaio[m]> you know something being in Cargo.lock doesn't mean it's getting compiled, right?

12:24 <dirbaio[m]> Cargo.lock locks the versions of every potential dep, even those that are disabled due to Cargo features not being enabled, or due to being target-specific for another target.

12:25 <dirbaio[m]> to view your real dependency tree use cargo tree with the right --target and --features.

13:03 <JamesMunns[m]> <dirbaio[m]> "Cargo.lock locks the versions of..." <- Man I had that one bite me recently. I was hoping I could handle multiple versions of embassy-usb (0.2 and 0.3) for postcard-rpc, but it wasn't possible to get the usbd stuff to resolve so I ended up just dropping 0.2 support

13:15 <GrantM11235[m]> There is a new generic integer RFC https://github.com/rust-lang/rfcs/pull/3686

13:16 <thejpster[m]1> I wrote a thing about Embedded Rust for Raspberry Pi

13:16 <thejpster[m]1> https://www.raspberrypi.com/news/rust-on-rp2350/

13:17 <thejpster[m]1> Amazed they left this line in:

13:17 <thejpster[m]1> > Maybe if you all ask nicely enough, we’ll see some more top-tier silicon vendors offering official Rust support for their chips (hint, hint)!

13:17 <thejpster[m]1> * Amazed they left this line in:

13:17 <thejpster[m]1> > I will note, though, that with the exception of some lovely folks at Espressif, pretty much all of the open-source Embedded Rust so far has been done by individuals working for free in their spare time. Maybe if you all ask nicely enough, we’ll see some more top-tier silicon vendors offering official Rust support for their chips (hint, hint)!

13:18 <thejpster[m]1> mabez I got Espressif onto the Raspberry Pi blog. You're welcome ;)

15:50 <AugustoRoman[m]> Is there a recommended approach for logging in a library that will be used both on an embedded device AND on my mac running locally and using embedded_graphics_simulator? I normally use defmt for embedded but couldn't figure out how to get that to log to the terminal in local mode.

16:05 <dirbaio[m]> <AugustoRoman[m]> "Is there a recommended approach..." <- Embassy uses this to support both defmt and log, feel free to copy-paste https://github.com/embassy-rs/embassy/blob/main/embassy-usb/src/fmt.rs

16:06 <dirbaio[m]> (Due to reasons of how the macros work it cant be made into a reusable crate, it must be copy-pasted...)

16:07 <AugustoRoman[m]> that's perfect, thanks!

16:09 <AugustoRoman[m]> dirbaio[m]: I just found https://lib.rs/crates/defmt-or-log and was looking through it. It seems like it's similar, but I don't understand the fine points of rust to determine why it's a crate vs the usb solution.

16:15 <dirbaio[m]> From a quick reading of the code it still needs your crate to have defmt/log features and conditionally depend on defmt

16:16 <dirbaio[m]> And if the user depends on two libs that use defmt-or-log and enables defmt only in one, the other will break

16:16 <dirbaio[m]> Same issues I ran into when I tried to make that fmt.rs into a crate

16:17 <dirbaio[m]> I think they're unfixable

16:22 <AugustoRoman[m]> I briefly tried to look into making a logger for defmt that would log to the terminal instead of exporting over some other transport, but I quickly got lost. Seems like it should be relatively straightforward, at least conceptually.

16:23 <dirbaio[m]> Due to The elf hacks it does it might be hard to get working on windows, Mac

16:27 <PeterKrull[m]> Hey, anyone here who have done "routing" of signals within the firmware, or have any ideas on how to do so? I use embassy, and I have some logic that determines how my different tasks inputs and outputs (essentially SPMC channels) connect to each other based on some state. With my current implementation I have a task that is... (full message at

16:27 <PeterKrull[m]> <https://catircservices.org/_matrix/media/v3/download/catircservices.org/fkKSvoPXzJhBfIOWvLfprkic>)

16:31 <PeterKrull[m]> * Hey, anyone here who have done "routing" of async channel values within the firmware, or have any ideas on how to do so? I use embassy, and I have some logic that determines how my different tasks inputs and outputs (essentially SPMC channels) connect to each other based on some state. With my current... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HeaEjKkpSRprTKzxRibZUiDz>)

16:38 <PeterKrull[m]> * Hey, anyone here who have done "routing" of async channel values within the firmware, or have any ideas on how to do so effectively? I use embassy, and I have some logic that determines how my different tasks inputs and outputs (essentially SPMC channels) connect to each other based on some state. With my... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/JideOFvGwVbJxRTJUKqYUUTA>)

16:40 <d3zd3z[m]> I am finding that `Arc::new(MyThing::new()) as Arc<dyn MyTrait>` works with alloc's Arc, but gives a non-primitive cast error when trying to use the portable-atomic-util Arc.

16:43 <JamesMunns[m]> d3zd3z[m]: probably either an API gap (that could be fixed), or it might be a behavior that is only available to the real Arc, which might not be fixable.

16:43 <JamesMunns[m]> (that's probably not helpful, but just a heads up it could be the latter case, at least)

16:44 <d3zd3z[m]> ChatGPT suggested `Arc<Box<...>>` as a workaround, and also suggested the util's Arc might need an UnsizedCoerce impl.

16:45 <JamesMunns[m]> As a human, I can't comment on suggestions by statistical models :)

16:49 <JamesMunns[m]> <PeterKrull[m]> "Hey, anyone here who have done..." <- > <@peterkrull_:matrix.org> Hey, anyone here who have done "routing" of async channel values within the firmware, or have any ideas on how to do so effectively? I use embassy, and I have some logic that determines how my different tasks inputs and outputs (... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zbUlrGSJEPTqsgeYHgBbvVue>)

16:49 <JamesMunns[m]> JamesMunns[m]: like, it doesn't answer your question, but there are likely other ways to potentially structure the code, that doesn't require one central "message bus" of events

17:05 <PeterKrull[m]> I just find channels (a no_std re-impl of https://docs.rs/tokio/latest/tokio/sync/watch/index.html to be exact) extremely intuitive and a nice abstraction for what I am doing, which is a flight controller. There are many signals being updated constantly at different rates, and receivers should, as much as possible, be immediately awaken when some input signal changes. This is mostly relevant for my filters (controllers,

17:05 <PeterKrull[m]> estimators, etc.) which are implemented as tasks, the inputs and outputs of which should be configurable depending on the flight mode. Implementing the filters as tasks means I can put the most timing-sensitive stuff in an interrupt executor. I essentially want the tasks to now know where their input came from, since that is handled somewhere else, which is the routing task in my case.

17:07 <JamesMunns[m]> As an example: You could instead model that as a Mutex and a WaitQueue, meaning that only the latest value is kept, and any waiting task can be awoken when the value is updated.

17:08 <JamesMunns[m]> then each task would just be awaiting the data it is interested in, and doing one "step" each time any of it's inputs change, and then effect an output.

17:08 <JamesMunns[m]> Sorry - this probably isn't helpful, "just do something else instead" is kind of a lame answer to your question

17:09 <JamesMunns[m]> but on no-std systems where we don't have things like LocalSet or heap allocated channels or broadcast channels, it often IS awkward to do channel multiplexing like this, even though it seems like a good idea to reach for, conceptually.

17:10 <JamesMunns[m]> But - I'll leave it there if that answer isn't interesting, happy to chat if you're interested tho.

17:10 <d3zd3z[m]> <d3zd3z[m]> "ChatGPT suggested `Arc<Box<...>>..." <- Digging through the code a bit, there is both a comment as to why UnsizedCoerce is unstable and therefore not implemented, and a pointer to a woraround

17:11 <d3zd3z[m]> s/woraround/workaround. Basically, Allocate a Box first, and then use `Arc::from` to turn that into an Arc. The coercion happens with the box, which supports it./

17:11 <Gnome[m]> <dirbaio[m]> "you know something being in..." <- > I know, silly, but that's my motivation

17:12 <PeterKrull[m]> JamesMunns[m]: No, its fine! I want to consider all options. I also just want to make sure what I am doing is not completely idiotic, but maybe just a bit awkward to implement.

22:31 <thejpster[m]1> I had a chat with Arm today about ROPI and RWPI. They are going to send a fix to LLD to get rid of the error about unsupported relocation type in a debug section. But they said ROPI and RWPI only work on C and aren’t supported for C++ so we might have trouble with trait objects (because the vtable can’t live at a static address). Also statics can’t contain the address of another static.

22:31 <thejpster[m]1> If you are running code from RAM, PIC might work ok. Apparently the fixups are fairly easy.