02:53 <ubernerd[m]> How are people feeling about the Arduino Portenta H7 board for rust? STM32H747XI is the MCU, STM32H747XIHx listed on probe-rs, close enough? Any other gotchas? Or if someone has a recommended dev board that includes the NXP SE050 or variants I would be interested to hear about alternatives.

03:07 <ubernerd[m]> I'm assuming the Arduino Portenta C33 with the Renesas R7FA6M5BH2CBG would not be recommended.

05:35 <FrreJacques[m]> Is there something like the rust api guidelines for embedded rust? Those guidelines recommend to implement a set of traits from std, but that makes no sense for an embedded driver I guess.

05:41 <andreas[m]> <FrreJacques[m]> "Is there something like the rust..." <- Something like [embedded-hal](https://github.com/rust-embedded/embedded-hal) 🤔

05:58 <FrreJacques[m]> Yeah I know that and will try to eh 1. But maybe there are some things from core or whatever. Or additional conventions that differ.

05:59 <jannic[m]> <andreas[m]> "Something like [embedded-hal](..." <- There is https://docs.rust-embedded.org/book/design-patterns/hal/index.html, but parts of it may be outdated.

06:02 <FrreJacques[m]> Ah, yes there is a chapter in that book.

06:05 <FrreJacques[m]> But it seems to be focussed on hals, not drivers. Maybe I will just try out something and ask for feedback if I have a working solution.

14:38 <glaeqen[m]> James Munns: Hey, I have a question regarding dispatcher machinery that you've built in `postcard-rpc`. Everything about it seems to be very USB specific and I wonder what's your plan for it down the line? I planned to upstream korken89 's shot at it which has a syntax similar to `tokio::select` and it leaves more details up to the user. I'll create a PR and we can have discussion if there's any room for it there :)

14:39 <JamesMunns[m]> yep, the plan is to be determined, but definitely want to do it: https://github.com/jamesmunns/postcard-rpc/issues/26

14:41 <JamesMunns[m]> Open to the other approach, I'd prefer to have it be more encapsulated "like USB but generic over transports", just haven't had time to chew on it yet.

14:42 <JamesMunns[m]> (a lot of people struggle with the "plumbing" aspect of receiving/sending, so encapsulating that makes it easier for me to help people/not have support questions)

14:44 <glaeqen[m]> I can see that, especially that you seem to want to hide away the WireContext while deprecating the HostClient::new_manual.

14:44 <JamesMunns[m]> re: the "unique" check in const context: you can also just ask the compiler to enforce no shadowed matches like I do in the USB macro: https://github.com/jamesmunns/postcard-rpc/blob/8415ea97f46a8e859fae7b828c46aa729a285c70/source/postcard-rpc/src/target_server/dispatch_macro.rs#L144

14:44 <glaeqen[m]> * I can see that, especially that you seem to want to hide away the WireContext by deprecating the HostClient::new_manual.

14:44 <JamesMunns[m]> glaeqen[m]: yep, PC side has had the refactor, I want to do something similar for the MCU side.

14:45 <glaeqen[m]> JamesMunns[m]: I tried to apply it but it does not yield any warning nor error when I duplicate the endpoint. Maybe I'm doing something wrong

14:45 <JamesMunns[m]> glaeqen[m]: 👀

14:46 <JamesMunns[m]> if you can repro that with the existing USB macro, please open an issue and I'll upstream the const check instead.

14:47 <glaeqen[m]> I duplicated the line with the PingEndpoint in the firmware/comms-02 app to test it and it didn't seem to do anything with 1.78 toolchain. I'll create an issue

14:48 <glaeqen[m]> * I duplicated the line with the PingEndpoint in the dispatcher definition in firmware/comms-02 app to test it and it didn't seem to do anything with 1.78 toolchain. I'll create an issue

14:55 <TomB[m]> https://thenewstack.io/rust-the-future-of-fail-safe-software-development/ looks nice, toyota and arm joining some consortium?

14:55 <TomB[m]> * some consortium for safety certified things and rust?

15:08 <JamesMunns[m]> Huh, I can repro that macros from other crates don't fire trigger lints

15:08 <JamesMunns[m]> TIL, thank you glaeqen!

15:11 <JamesMunns[m]> glaeqen if you can PR just the const check to the usb macro, I'd appreciate it, otherwise I'll do that this weekend and release ASAP.

15:21 <birdistheword99[> What's the accepted practice in embedded rust for dealing with Static Arrays? I have to use a static array because The data has to be placed in aspeicific RAM region on the H7 for the BDMA controller to be able to see it, but I am always getting lint warning about it being 'discouraged' and that it will be a... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/JiunYHpsZBcUxVNzlogkRCNB>)

15:21 <birdistheword99[> I'm guessing its using some kind of interior mutability?

15:21 <JamesMunns[m]> I've been working on https://docs.rs/grounded/latest/grounded/ to help with this

15:22 <birdistheword99[> * I'm guessing its using some kind of interior mutability?

15:22 <birdistheword99[> If possible I would like to avoid locks, since this will be accessed frequently and by a single function

15:23 <birdistheword99[> Ah nice, it seemed like it would be a problem for embedded. I'll have a look at your repo :)

15:23 <RobertJrdens[m]> cortex_m::singleton() in master forwards attributes.

15:23 <JamesMunns[m]> RobertJrdens[m]: the challenge is that the separate section will be uninit

15:24 <JamesMunns[m]> you could use the singleton macro with `MaybeUninit<[u8; N]>` tho

15:24 <RobertJrdens[m]> JamesMunns[m]: Exactly.

15:24 <JamesMunns[m]> yep, that'd also work!

15:26 <birdistheword99[> How would the singleton!() macro work with data that has to be linked to a specific memory region?

15:26 <birdistheword99[> Can you still use [link_section = ".sram4"] fro example?

15:27 <RobertJrdens[m]> birdistheword99[: Yes. With `cortex_m` master.

15:57 <glaeqen[m]> <JamesMunns[m]> "(a lot of people struggle with..." <- I feel like that might be actually a double edged sword. At least these low-level details should be somehow accessible with "escape-hatches" so everyone can implement their own thing if there's a need without forking a project. I'm not sure how easy it is going to be to support all kinds of protocols long-term and then be bombarded with issue reports that this topology of

15:57 <glaeqen[m]> traits is not working for someone's flavour of X :/

16:18 <JamesMunns[m]> Quick note that `postcard-rpc` v0.5.1 is now released, and I've yanked v0.5.0. There was an issue with how I was checking for duplicate endpoint keys, thanks to glaeqen for reporting and fixing!

16:18 <JamesMunns[m]> https://github.com/jamesmunns/postcard-rpc/releases/tag/v0.5.1

16:18 <JamesMunns[m]> <glaeqen[m]> "I feel like that might be..." <- yep. +1 to "defaults should be easy, custom should be possible"

16:23 <JamesMunns[m]> <JamesMunns[m]> "yep. +1 to "defaults should be..." <- My *goal* is to abstract the wire stuff behind a trait, like I did on the PC side. So anyone can impl the trait on their own wire format, and have the macro Just Work. We'll see how that goes :)

16:46 <thejpster[m]> <TomB[m]> "https://thenewstack.io/rust-the..."; <- The nice thing about them joining this public consortium is that their membership is a matter of public record, unlike my list of clients and partners.

16:46 <TomB[m]> I'd love to see that list though :-)

16:46 <TomB[m]> but yeah, its kind of the usual hill to climb it seems like

16:46 <thejpster[m]> easy! it's available to everyone who works at Ferrous Systems ;)

16:46 <TomB[m]> once you get a few big players putting their name out there tied to it... others start piling in

16:47 <TomB[m]> look at Zephyr... Intel, NXP and Nordic... now everyone has their name on it

16:47 <TomB[m]> hopefully Rust for safety goes the same route, would be cool to see