00:44 <Kert[m]> <correctalex[m]> "I assume things are left in an..." <- These issues will keep biting people, i remember logging this a long time ago https://github.com/stm32-rs/stm32l0xx-hal/issues/160

00:45 <Kert[m]> Kert[m]: Is there ever a reason for infinite wait in a call like master_write(..) ?

10:09 <RobinMueller[m]> Is there some crate out there that provides something like a raw buffer slice:... (full message at <https://catircservices.org/_irc/v1/media/download/Aaf6sC_tbwxxm-CKcm_ocKRiVdwG26mvoNNlAn3lI-PAy3MvayI1Pg-cGFntsBjRnW1dBCUQxGwvV6tuBNgG5Bm_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9KSkFGZlViRlNkSWZQbFNvdWRyenZzUkc>)

10:10 <RobinMueller[m]> * I basically use a shared

10:46 <RobinMueller[m]> this might be horribly unrusty 😅? I basically circumvented lifetimes here. I could use ring buffers, but this is how I commonly solved this in C/C++ for the TX side of non-blocking serial transmissions. I used it with a peripheral which works using FIFOs + Half-empty Interrupts, but this could probably used with DMA as well with a mutable variant and by implementing https://docs.rs/embedded-dma/0.2.0/embedded_dma/ for those

10:46 <RobinMueller[m]> types..

10:47 <RobinMueller[m]> * this might be horribly unrusty 😅? I basically circumvented lifetimes here. I could use ring buffers, but this is how I commonly solved this in C/C++ for the TX side of non-blocking serial transmissions. I used it with a peripheral which works using FIFOs + Half-empty Interrupts, but this could probably used with DMA as well, additionally implementing https://docs.rs/embedded-dma/0.2.0/embedded_dma/ traits for the raw

10:47 <RobinMueller[m]> slice

10:49 <RobinMueller[m]> * this might be horribly unrusty 😅? I basically circumvented lifetimes here. I could use ring buffers, but this is how I commonly solved this in C/C++ for the TX side of non-blocking serial transmissions. I used it with a peripheral which works using FIFOs + Half-empty Interrupts, but this could probably used with DMA as well, additionally implementing https://docs.rs/embedded-dma/0.2.0/embedded_dma/trait.ReadBuffer.html

10:49 <RobinMueller[m]> traits for the raw slice

12:28 <thejpster[m]> Ugh, Element has a stuck notification but I can’t see for what

14:16 <JamesMunns[m]> thejpster let's see if adding and clearing a new one helps :D

14:28 <thejpster[m]> weirdly, yes?

17:07 <JamesMunns[m]> Happy to help :D

18:36 <adamgreig[m]> Sorry, have been held up and will be about ten minutes late to the meeting!

19:10 <adamgreig[m]> ok, sorry to keep you all waiting @room , meeting time again! agenda is https://github.com/rust-embedded/wg/discussions/825, we can start right away

19:10 <adamgreig[m]> does anyone have any announcements they'd like to make? or if there's anything you want to discuss please add to the agenda

19:12 <adamgreig[m]> couple of things from me: first, welcome thejpster back to the wg and to the Arm team!

19:13 <adamgreig[m]> and second, another reminder that if you're interested in coming to Rust Week in Utrecht in May, not only does the conference have a bunch of interesting embedded talks, but we're having the embedded unconf there in the days just after the conference, please let me know if you'd like to come to the unconf! the conference also has some travel grant support available, let me know if that's of interest

19:13 <i509vcb[m]> More of an announcement, I am working on upstreaming a new embassy hal upstream for the MSPM0 MCUs from TI. For the curious https://github.com/embassy-rs/embassy/pull/3966 and https://github.com/mspm0-rs exists for all the pac stuff

19:13 <i509vcb[m]> Still quite WIP as only GPIO and a time driver exist currently

19:14 <adamgreig[m]> MSPM0 👀 do they have any fram versions?

19:14 <i509vcb[m]> No FRAM unfortunately

19:14 <adamgreig[m]> I guess they lost the hand drawings or whatever lol

19:15 <JamesMunns[m]> they are in fact itty bitty :D

19:15 <therealprof[m]> You wanted to bring up the talk?

19:15 <i509vcb[m]> Yes the HAL does support the tinest part, although I don't have that package to test with

19:15 <adamgreig[m]> call me when they're 0402-sized :P

19:17 <bartmassey[m]> Are they smaller than the chip-directly-on-PCB ones? (What's that called again?)

19:17 <adamgreig[m]> "chip-on-board" usually

19:18 <adamgreig[m]> looks like they could be! that's gotta just be a die with bump pins or something

19:19 <bartmassey[m]> Oh, I have an announcement of sorts!

19:20 <bartmassey[m]> I got permission to run an Academic Mini-Track at Rustconf. I haven't announced it publicly yet, so…

19:20 <bartmassey[m]> I am looking for a Program Committee. If you know a RustConf person who has a PhD and a recent research record who might be willing to serve, please put them in touch with me.

19:21 <bartmassey[m]> Sorry, "RustConf person" → "Rust Person"

19:22 <adamgreig[m]> oh, cool! like a little academic conf with papers?

19:22 <bartmassey[m]> Yeah, basically a chance to have academics get some professional credit for participating in RustConf.

19:22 <bartmassey[m]> Refereeing is intended to be fairly light, but real and credible.

19:22 <adamgreig[m]> great plan

19:22 <bartmassey[m]> Have done this before in other open source settings: it's good for both sides.

19:24 <therealprof[m]> Adam? 😉

19:24 <bartmassey[m]> Yeah, was thinking 😀

19:25 <adamgreig[m]> ah yep, bartmassey volunteered to give a talk at rustweek, shall we discuss your topic ideas?

19:25 <bartmassey[m]> Sure! I had several, but the one I mentioned last is probably plan A, so maybe try that first?

19:25 <adamgreig[m]> s/volunteered/was volunteered/

19:25 <bartmassey[m]> Naw. Happy to do it.

19:26 <adamgreig[m]> yep, will do! I don't think there's anything else we need to discuss in the meeting unless there's anything you want wider feedback on

19:26 <bartmassey[m]> Not yet! I'll ask next week or sometime before. Oh, wait…

19:27 <therealprof[m]> What was the one you mentioned last again?

19:27 <bartmassey[m]> The secret plan 😀. I'll let everyone know more soon.

19:27 <bartmassey[m]> In the meantime if you have any things you think should be our talk, please PM me!

19:30 <therealprof[m]> The organizers are getting nervous to see some kind of title/outline rather soonish...

19:30 <adamgreig[m]> leftover from last week we have the request for heapless 0.9 which I think is mainly waiting on https://github.com/rust-embedded/heapless/pull/502 though there's a bunch of other on-the-go PRs too, and for feedback on https://github.com/rust-embedded/critical-section/pull/58

19:30 <bartmassey[m]> Good to know. Can do it in days not weeks

19:32 <JamesMunns[m]> Oh small note, website updates are going on: https://github.com/rust-lang/team/pull/1691

19:32 <JamesMunns[m]> but we already have a page, so probably won't affect us?

19:33 <adamgreig[m]> yea, looks like that's adding pages for all the teams that didn't have them before

19:34 <jannic[m]> I had a look at https://github.com/rust-embedded/heapless/pull/502 and it LGTM. As noted in the ticket comment, it doesn't help much as I'm not a member of the libs team, but perhaps that give one of the members more confidence to approve it?

19:35 <therealprof[m]> I'm looking.

19:38 <therealprof[m]> Merged.

19:40 <adamgreig[m]> ok! the final thing on the agenda today is this comment about some sort of camera HAL layer: https://github.com/rust-embedded/wg/discussions/825#discussioncomment-12516570

19:41 <adamgreig[m]> I don't think the comment author is here nor many of the hal team so maybe best to discuss on the comment thread if anyone has thoughts. probably the best option is to prototype something and see if it works for a couple of cameras first..

19:42 <adamgreig[m]> there is already https://crates.io/crates/mipidsi which is a similar sort of purpose

19:42 <adamgreig[m]> (but more about the control channel than data)

19:43 <therealprof[m]> Sounds very tricky to me.

19:45 <therealprof[m]> ... but hey, if someone wants a good challenge. 😉

19:51 <adamgreig[m]> yea.. lots of cameras and lots of tricky high-speed interfaces

19:52 <adamgreig[m]> ok, anything else anyone wanted to discuss this week?

19:53 <JamesMunns[m]> Looking forward to seeing everyone in person :D

19:54 <JamesMunns[m]> If anyone is interested in hardware design, I'm going to be bringing the hardware rack I put together for Embedded World.

19:54 <adamgreig[m]> I'm looking forward to seeing that in person too :P and everyone, of course!

19:54 <JamesMunns[m]> Open offer to anyone who designs a card in my totally-just-invented "BERLINER" standard: https://github.com/jamesmunns/BERLINER, happy to have it as a demo at RustWeek as well :D

19:55 <danielb[m]> JamesMunns[m]: just wondering, did you call it BERLINER because you're designing for the wurst case?

19:56 <JamesMunns[m]> I needed a silly name, and @marmrt was the one with the quick wit :D

20:03 <adamgreig[m]> (that's all for this week then, thanks all!)

20:18 <therealprof[m]> Holy cow. The Pebble is coming back. 😍

20:20 <adamgreig[m]> yea!!! the clock's running on first to get rust on it

20:20 <adamgreig[m]> nRF52840 so should be easy enough right

20:21 <CarlosvanRooijen> ?

20:21 <CarlosvanRooijen> adamgreig[m]: Is it running on that

20:22 <adamgreig[m]> https://ericmigi.com/blog/introducing-two-new-pebbleos-watches

20:22 <CarlosvanRooijen> Damn

20:22 <CarlosvanRooijen> I might buy this just to write rust for it

20:24 <therealprof[m]> There're cheaper ways to get a smart watch with nRF chip but the Pebble is special.

20:25 <therealprof[m]> Parts of the firmware are now Open Source... https://github.com/pebble-dev/pebble-firmware

20:25 <therealprof[m]> They managed to resurrect some from the Google Graveyard.

22:24 <vollbrecht[m]> <danielb[m]> "just wondering, did you call..." <- why did i expect a round design, or should it otherwise be called "pfannkuchen" or "krapfen"?

23:27 <zeenix[m]> Hi, does anyone know of a way/API like `futures::stream::SelectAll` that doesn't require alloc? I just need to run an arbitrary/dynamic number of streams together.

23:27 <zeenix[m]> Perhaps something based on heapless