02:02 <swork[m]> I'd like to wait on change of state of any of a collection of GPIO pins. I can make a heapless::Vec of x.wait_on_any_edge() futures for each pin and select_slice() on it, but waiting on edges is racy. I want to pick .wait_for_{high,low} instead, depending on last known state for each pin. How can this be done? I'm lost in a maze of Pin/Unpin requirements: the un-awaited futures need to be Pin()'d to get .await'd later (right?), and

02:02 <swork[m]> the pin!() macro in a conditional leads to temporaries with too-short lives; but I can't pin!() the result of a conditional because the if and else clauses have different types (wait_for_high or wait_for_low). This has to be a common beginner problem, resources must be out there, but I haven't found them (or recognized them yet). Can anybody help me get oriented?

03:14 <RandomExplosion[> I'm working on my first custom stm32 board with the stm32f407, just wanted to ask what flashing method you guys recommend, (traditional USB->UART, JTAG, USB OTG etc) I can put whatever connectors on the board that I need to, I just want to know what works best with the embedded rust stack (especially rtic)

03:15 <i509vcb[m]> You probably want to expose the SWCLK and SWDIO pins on the connector

03:15 <i509vcb[m]> Unless you explicitly need JTAG for the scan chain, it's probably not worth the extra pins

03:17 <i509vcb[m]> s/scan/chaining/, s/chain/devices on the board to test/

03:18 <RandomExplosion[> I do need that anyway yeah

03:18 <RandomExplosion[> *JTAG

03:19 <i509vcb[m]> otherwise assuming your debug probe supports driving JTAG, the toolchain at least from a surface level should be able to debug the target

03:19 <RandomExplosion[> I spoke to someone earlier who mentioned that to flash over USB otg you need to flash a USB bootloader to the chip first via UART or jtag

03:19 <i509vcb[m]> Lets see what AN2606 has to say

03:20 <RandomExplosion[> Is JTAG over USB OTG a thing for stm32s like it is for the newer esp32 chips (c3, s3 etc)

03:20 <i509vcb[m]> I know what the esp32c3/c6 include a built-in JTAG debugger

03:20 <i509vcb[m]> * JTAG debugger and expose it over USB

03:22 <i509vcb[m]> AN2606 says that USB DFU should be available, but that would only really apply to a fresh chip and if you need a debugger then you need SWD or JTAG

03:22 <i509vcb[m]> * be available on the F407, but

03:22 <swork[m]> * I'd like to wait on change of state of any of a collection of GPIO pins. I can make a heapless::Vec of x.wait\_on\_any\_edge() futures for each pin and select\_slice() on it, but waiting on edges is racy. I want to pick .wait\_for\_{high,low} instead, depending on last known state for each pin. How can this be done? Cortex-M so no heapless::pool Box::pin - am I forced into using an allocator? Otherwise I'm lost in a maze of

03:22 <swork[m]> Pin/Unpin requirements: the un-awaited futures need to be Pin()'d to get .await'd later (right?), and the pin!() macro in a conditional leads to temporaries with too-short lives; but I can't pin!() the result of a conditional because the if and else clauses have different types (wait\_for\_high or wait\_for\_low). This has to be a common beginner problem, resources must be out there, but I haven't found them (or recognized them yet).

03:22 <swork[m]> Can anybody help me get oriented?

14:43 <diondokter[m]> For an application I'm trying to guestimate if all the firmware will fit in flash. Does anybody have a rough number of how much space a relatively simple UDP smolltcp/embassy-net implementation takes?

14:44 <diondokter[m]> * simple UDP/IPV4 smolltcp/embassy-net

14:44 <JamesMunns[m]> I think the last time I looked it was 40-50k? that might have been with USB (ECM) as the transport instead of a hw phy

14:44 <diondokter[m]> Ok, cool, thanks!

14:44 <diondokter[m]> This is not looking good lol

14:47 <whitequark[cis]1> i think maybe 20-30k of those may have been smoltcp, unless smoltcp got much bigger recently

14:48 <diondokter[m]> Yeah, I had that 30k number in mind

14:48 <whitequark[cis]1> (the numbers from my memory are for or1k, i think, so a bit worse than thumb)

14:49 <diondokter[m]> But the 20k isn't gonna be the problem. It's the unexpectedly 209kb big C library we need

14:49 <whitequark[cis]1> oops.

14:49 <diondokter[m]> * But the extra 20k isn't

14:54 <marmrt[m]> Rewrite it in Rust

15:05 <diondokter[m]> <marmrt[m]> "Rewrite it in Rust" <- Ha, ideally yes. But our estimation is that'd cost us almost 700 hours to do

15:05 <diondokter[m]> And it probably won't solve the flash size issue

15:53 <wassasin[m]> If it has XIP redesign the hardware with some extra NOR? :')

15:54 <diondokter[m]> It's an STM32 with an 8MB NOR already hooked up to the QSPI, so I'm looking at whether we can use that

15:54 <diondokter[m]> The qspi can do memory-map mode

15:54 <diondokter[m]> But not sure if that's enough to run code from it

15:55 <JamesMunns[m]> <whitequark[cis]1> "i think maybe 20-30k of those..." <- yeah, I forget exactly what that included. It might have also included a good chunk of embassy-usb as well

15:56 <JamesMunns[m]> (I was looking at what the baseline code size would be to do tcp/ip over usb instead of manual bulk packet handling)

15:57 <diondokter[m]> Oh!

15:57 <wassasin[m]> Nice.

15:57 <diondokter[m]> This might just work :D

16:56 <bogdan[m]> is it possible to do something like this

16:56 <bogdan[m]> ```rs

16:56 <bogdan[m]> ```

16:57 <bogdan[m]> Is it possible to do something like this without unstable?... (full message at <https://catircservices.org/_irc/v1/media/download/AYeXF1XU3MAg36o8ZyQUt6dKNuoEgtqq2hBCJeaUATAFq0KfF8xMCjgmHhIHrryy9jlbzb6rBjiAxdTTVD9PFWe_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy93TWdnQUFnUm5DSk5JekVIZlhpcFR3cEg>)

16:58 <bogdan[m]> (example based on stack overflow https://stackoverflow.com/a/76104058 )

17:06 <dirbaio[m]> you can do `const { assert!(A > B); }`

17:06 <bogdan[m]> in a where clause?!

17:07 <dirbaio[m]> no, in some expression

17:07 <dirbaio[m]> for example inside the method

17:07 <dirbaio[m]> if that method gets monomorphized, these const asserts will run for the particular values of A+B and fail at compile time if they're not right

17:07 <bogdan[m]> ah, runtime check is the thing I'd like to avoid

17:07 <dirbaio[m]> no, it fails at compile time

17:07 <bogdan[m]> no way!

17:08 <bogdan[m]> let me check :)

17:09 <bogdan[m]> you're right, as usual

17:09 <dirbaio[m]> ther'es some caveats

17:10 <dirbaio[m]> for example cargo check won't catch it, since it doesn't do monomorphization+codegen

17:10 <dirbaio[m]> this was officially accepted as intended behavior and not a bug in https://github.com/rust-lang/rfcs/blob/master/text/3477-cargo-check-lang-policy.md

17:10 <dirbaio[m]> ¯\_(ツ)_/¯

17:11 <bogdan[m]> Thank you! :)

17:13 <bogdan[m]> I wonder if these kinds of asserts would give better compile errors than just something like... (full message at <https://catircservices.org/_irc/v1/media/download/ARxZkxlESPtuvQnN-D2ONsuRjWXxO9XRAlrU9DxyFkolruSnbqO3830xpxP7J5Y6_QvyEsuE-H6Pz84-giUnpEm_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9OSVlYS0xpRVdBYmF4cXpFa1dqTFVRZHQ>)

17:16 <dirbaio[m]> lol

17:17 <dirbaio[m]> i'm not sure if it's as powerful, because you can't "inspect types" from const, just const generics values

17:17 <bogdan[m]> dirbaio[m]: good point

17:17 <dirbaio[m]> for example you can't "assert XO is not the HfXo type"

17:18 <dirbaio[m]> anyway IMO the most usable design is to not use generics like that at all

17:18 <bogdan[m]> dirbaio[m]: I know your stance on this, but I'm stubborn :)

17:19 <dirbaio[m]> 🙃

17:19 <dirbaio[m]> imagine you got multiple revisions of the board, and you encode the revision in an eeprom or with 0ohm resistors in unused pins

17:20 <dirbaio[m]> and you discover the HFXO you mounted in revision 1 is fucked up and fails randomly. you want the firmware to read the board revision at boot, then dynamically choose to use HFRC in revision 1 and HFXO in revision 2

17:20 <dirbaio[m]> with these generics designs, you simply can't

17:21 <bogdan[m]> I agree

17:21 <thejpster[m]> :tada: https://ferrous-systems.com/blog/ferrocene-achieves-iec-62304-qualification/

18:10 <JamesMunns[m]> Congrats! You'll make ryan-summers very happy with that :D

18:33 <sourcebox[m]> Not a topic for the meeting, but maybe ryan-summers and eldruin are here this evening: do we have a change to get version 0.4 of `usb-device` out somwwhere in the near future? I'm fully aware of the pain that this introduces for getting all HALs and classes updated, but the current limitation of the control buffer size is a real blocker for some future work.

19:00 <adamgreig[m]> hi @room, meeting time again! agenda is https://github.com/rust-embedded/wg/discussions/811, please add anything you'd like to announce or discuss and we'll start in a few minutes

19:04 <adamgreig[m]> ok, let's begin! the only announcement from me is about RustWeek; I'll start collecting names for people interested in joining the embedded unconf, so please let me know (here, on the github discussion, in DM, etc) if you're interested in attending

19:04 <adamgreig[m]> we can probably have about 20-25 people again

19:05 <adamgreig[m]> currently no word on whether there will be travel sponsorship/accommodation, but the hope is that there will be; it would be useful to know if you'd need this to be able to come or not

19:06 <adamgreig[m]> similarly right now you'd be buying your own ticket to the rustweek conf that's the days before the unconf (there's no cost for the unconf itself), though there may be some ticket sponsorships available if your company wouldn't cover it, please let me know if you'd want that too

19:06 <adamgreig[m]> anything else to say about that, therealprof?

19:08 <therealprof[m]> They're still looking for additional sponsors, so if your company wants to become one, please contact erikjee .

19:09 <adamgreig[m]> ah yep indeed! there's a sponsorship prospectus here: https://rustweek.org/resources/sponsorship-prospectus-rustweek-2025.pdf

19:09 <therealprof[m]> A lot of things will be happening this week including the 10 years celebration of Rust so it's going to be a ton of fun.

19:09 <JamesMunns[m]> adamgreig[m]: There is from the project, I need to double check they aren't excluding WGs, but let me find the contact info for that

19:10 <therealprof[m]> We're going to have more space than this year (which was a bit cramped but still a lot of fun).

19:10 <therealprof[m]> JamesMunns[m]: Yes, we were supposed to contact you about that. I guess that didn't happen. 😬

19:10 <adamgreig[m]> and at the same time and place will be the rust all hands

19:11 <JamesMunns[m]> https://github.com/rust-lang/leadership-council/blob/main/policies/spending/travel.md is the policy, I think we are allocating some additional funds for RustWeek specifically

19:12 <therealprof[m]> We'll also start brainstorming topics to discuss in the hopes to put an agenda up beforehand.

19:12 <JamesMunns[m]> (this is only for WG members, fyi)

19:13 <JamesMunns[m]> when in doubt, approvals go to the council for decision, so I'll see it if they aren't sure :)

19:13 <therealprof[m]> And: There's a speaking opportunity we can fill with a review of our work/achievements or highlighting one or more projects.

19:14 <therealprof[m]> (Outside of the CFP process which ends on Jan 19)

19:14 <adamgreig[m]> ah yes, thanks, that was the final thing! there's a slot in the main conference schedule for a talk from someone in the embedded unconf, so if anyone has any thoughts or is interested in that please also let us know :)

19:14 <adamgreig[m]> I left my notes for this at home and had to run today's meeting from work....

19:15 <bartmassey[m]> I definitely have thoughts and am interested 😀. Big surprise. Let me know how I can help.

19:16 <adamgreig[m]> cool, will do!

19:16 <adamgreig[m]> ok, thejpster do you wanna say anything about defmt 1.0?

19:17 <thejpster[m]> It’s coming. Please speak know if there’s anything you think I should not stabilise

19:18 <thejpster[m]> There will never be a defmt 2.0

19:18 <thejpster[m]> 1.0 is just 0.3 with a semver-trick

19:19 <newam[m]> I'm just happy to see a 1.0 coming for such an important crate.

19:20 <thejpster[m]> I just don’t want anyone to point something out post launch that’s then hard to fix

19:21 <rmsyn[m]> thejpster[m]: are there any particular places in the code where review would be helpful before launch?

19:24 <therealprof[m]> <thejpster[m]> "There will never be a defmt 2.0" <- ! say !

19:25 <bartmassey[m]> Have to go in a few minutes for class 😦. I left a thing in the minutes about Not Yet Awesome Embedded Rust. Feel free to discuss without me, or we can try it for a future meeting.

19:26 <adamgreig[m]> we can move on to that right now if you like?

19:26 <bartmassey[m]> Sure!

19:26 <adamgreig[m]> certainly it hasn't seem much love in a while 😅

19:27 <adamgreig[m]> I would say right now we have pretty good solutions for most of those things, and I'm not sure that having the list itself did much to drive solutions

19:27 <bartmassey[m]> I agree.

19:27 <bartmassey[m]> I'm torn between just archiving it and putting a disclaimer, and trying to bring it up to date. Lean toward the former.

19:28 <JamesMunns[m]> +1 to archive

19:29 <adamgreig[m]> yea, sounds fine to me

19:29 <bartmassey[m]> It would be nice to tell whatever story we currently have around sharing state with interrupts somewhere.

19:29 <bartmassey[m]> It's a confusing topic in general.

19:30 <bartmassey[m]> Maybe someone not me wants to volunteer to write a short guide? 😀

19:31 <adamgreig[m]> a more up-to-date version of the concurrency chapter in the book, sort of thing?

19:31 <adamgreig[m]> I mean the story is basically "consider rtic, embassy, or use something that is like critical_section::mutex when you squint" I think?

19:32 <adamgreig[m]> plus a handful of other crates that are neat but not as widely used

19:32 <bartmassey[m]> I guess the book has things, but I'm not sure they are the right things. Somebody more knowledgeable should check and let me know. https://github.com/rust-embedded/discovery-mb2

19:32 <bartmassey[m]> Anyhow, I will add a disclaimer and archive this week unless someone objects.

19:32 <adamgreig[m]> I'll just open an RFC issue on the repo so we can write up why and have resources members vote

19:33 <bartmassey[m]> Thanks all! 👋

19:34 <adamgreig[m]> ok, romancardenas did you want to talk about weak symbols vs lto for riscv?

19:35 <romancardenas[m]> Yes! Not riscv specific, though

19:37 <romancardenas[m]> We previously had `default_*` functions that could be overwritten via linker script with PROVIDEs.

19:37 <romancardenas[m]> This approach has the drawback of leaving default symbols in the binary

19:37 <romancardenas[m]> So, when moving to global assembly, we decides to use weak symbols directly in the assembly code

19:39 <romancardenas[m]> While this works, apparently it is not possible to perform LTOs when overriding a weak symbol. The PR I shared with you kind of follows the old approach, but I wanted to discuss with you if you have a better solution

19:40 <romancardenas[m]> * the binary even when "overriding" them

19:41 <romancardenas[m]> s/decides/decided/

19:41 <adamgreig[m]> aah, that's annoying

19:41 <adamgreig[m]> i don't know of anything better off the top of my head...

19:42 <rmsyn[m]> could we do something with traits that provide a default implementation?

19:43 <romancardenas[m]> Honestly, I have no idea

19:44 <romancardenas[m]> We can feature-gate default symbols so enabling a `no-mp-hook` removes the default MP hook function and so on

19:45 <romancardenas[m]> But I'm not a big fan of having too many features for such tricks

19:45 <adamgreig[m]> Yea, not the ideal use of features even if it's maybe better than nothing. Seems like ideally the linker should be able to figure this out somehow though huh

19:47 <romancardenas[m]> In the PR I attached (and the related issue) there are pointers for nightly features for weak symbols, but using nightly stuff on core traits is not an option

19:48 <romancardenas[m]> Also there is a .lto_discard option for LLVM, but the folk working on the PR couldn't make it work

19:49 <romancardenas[m]> I can try to investigate further

19:50 <romancardenas[m]> * it work (symbol redefinition errors when linking)

19:52 <adamgreig[m]> sorry i don't have any better ideas! we can copy whatever you do find for c-m though 👀

19:52 <romancardenas[m]> In any case, people with expertise on this stuff are more than welcome 😃

19:52 <romancardenas[m]> Will keep you posted

19:52 <adamgreig[m]> thanks! any other topics anyone wants to discuss this meeting?

19:54 <adamgreig[m]> if not let's finish here, thanks everyone!

20:47 <thejpster[m]> <rmsyn[m]> "are there any particular..." <- Mainly just looking at the API we expose to crates and in the ELF

21:02 <AndoThorNando[m]> <bartmassey[m]> "Maybe someone not me wants to..." <- I’m writing a blog post currently on multi-core which will have examples. It might be that I can get that work adapted back into a guide that works for single-core as well.

21:48 <thejpster[m]> I’m writing a training on how to make a UART a global with a ring buffer

23:06 <bartmassey[m]> That would be good! Let me know if I can help somehow