06:41 <dngrs[m]> <dirbaio[m]> "but it still feels dirty to have..." <- I don't know if what you're doing would run on macos too, in that case pay attention to the osx handling in defmt. Symbol names in mach-o have different rules

13:42 <Beregond[m]> newbie question - how to set proper size for buffer? I need to read and deserialize json file, but is there any smart way for to calculate "enough" buffer size on compilation time? Or some "right hand rule" for this?

14:03 <JamesMunns[m]> Little announcement: I'm gunna do a quick preview stream of Poststation (the "reverse proxy for embedded systems" tool I've been working on), talking about what it is and what it does, about 1h15m from now (16:15 CET/Berlin time), feel free to come hang out and ask any questions!

14:03 <JamesMunns[m]> https://youtube.com/live/Sl6LnErNKk4

14:04 <JamesMunns[m]> (recording will stay up, in case you can't make it live!)

14:04 <diondokter[m]> Cool! Might put it up on the side

16:28 <RyanSlawson[m]> Question for anyone here who knows a thing or two about `riscv-rt` - I'm currently using this for a `riscv32imfc-unknown-none-elf` target, but I'm having some issues. First one was that the floating point stuff wasn't... (full message at

16:28 <RyanSlawson[m]> <https://catircservices.org/_irc/v1/media/download/Aacx-JmOHugV8otzeYZ4QZxNzThQo8K0EA7XNnnP68H1T4wNUmhx8bnY4uQbxnGmLvPWRgu1Lc8DIq2GHQG9KPq_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9DY0NuY09ucFFoYkhSU3N2VmdycHpmaWc>)

17:23 <thejpster[m]> I want to create a wrapper for `critical_section::Mutex<core::cell::RefCell<Option<T>>>`. What should I call it?

17:23 <JamesMunns[m]> You could use https://docs.rs/mutex/latest/mutex/struct.BlockingMutex.html instead, if you want

17:23 <JamesMunns[m]> (it's that, basically)

17:25 <thejpster[m]> uh, OK. Without any examples that might take a while to reverse engineer. But I'll look into it.

17:27 <JamesMunns[m]> Ah, sorry, it gives you access to the inner item, mutably, inside of a closure

17:27 <JamesMunns[m]> (rather than as a guarded lock)

17:27 <thejpster[m]> Hmm:

17:27 <thejpster[m]> > // NOTE: `raw` must be FIRST

17:27 <thejpster[m]> does drop order apply to the order it's written in the struct, or the order it exists in memory (which might be different due to padding)?

17:27 <JamesMunns[m]> guarded locks are hard to do with critical sections

17:28 <JamesMunns[m]> it's lexical order

17:28 <thejpster[m]> I mean the correct answer is 'use RTIC', but I need a few pages of examples of 'doing it the hard way' before I show them 'use RTIC'

17:39 <JamesMunns[m]> tbf, this crate was my attempt to have "better tools" for people NOT using RTIC or Embassy, I think we should have a better story for things like this, instead of pushing people towards static mut or having to do very verbose "critical section refcell option" dances.

17:57 <danielb[m]> <JamesMunns[m]> "tbf, this crate was my attempt..." <- but you can still use embassy-sync even if you don't otherwise use embassy 👀

17:57 <JamesMunns[m]> yep! This crate is basically taking the blocking mutex from embassy sync, the plan is/was to then make an intrusive async mutex on top of this

17:58 <danielb[m]> taking, as in it uses the same traits, or do I still have to implement essentially the same thing multiple times as a hal author?

17:59 <JamesMunns[m]> it's not re-exporting it, but you don't need to do it per HAL, the critical section one just uses the critical section crate

17:59 <danielb[m]> but I have more specialized locks that I implement embassy-sync traits for

17:59 <JamesMunns[m]> (it is a copy and paste, I made this when I attempted to make embassy-sync use intrusive collections, with the hope to then "rebase" embassy-sync on top of it)

18:00 <danielb[m]> and apparently I'd have to do the same thing for the scoped mutex trait as well

18:00 <JamesMunns[m]> then yes, for now it is totally separate. The hope was/is to eventually base embassy-sync on top of this, but that hasn't happened yet

18:00 <danielb[m]> until then, let there be fragmentation 🙃

18:00 <JamesMunns[m]> :/

18:01 <danielb[m]> alright thanks, I'm looking forward to what you're cooking actually

18:01 <JamesMunns[m]> you're not wrong, but it's kinda a bummer of a phrasing.

18:02 <JamesMunns[m]> I did have a PR to merge it into embassy-sync, but the larger data structures broke some HALs, which was either a bug in my refactoring, or just actual unsoundness in some of them

18:02 <JamesMunns[m]> but yeah, the hope is to unify. Just... time. You know.

18:02 <danielb[m]> yeah I understand

18:03 <JamesMunns[m]> Context: https://github.com/embassy-rs/embassy/pull/3175

18:05 <JamesMunns[m]> But yeah, this whole effort is to get around the fact that most embassy-sync items are "atomicwaker/waitcell" shaped (e.g. you can never have multiple tasks waiting on the same mutex without waker churn), and not "waitqueue" shaped

18:17 <JamesMunns[m]> Either way, very much so "help wanted" in getting embassy sync switched over, using this crate or not :)

18:18 <danielb[m]> so I see the C031 having too little memory and probably ending up with a stack overflow I guess, but I also see your time driver mention (which may change considerably and we may end up removing alarms, and alarm callbacks) but I'm not seeing any other failures, so what exactly went wrong?

18:20 <danielb[m]> (also, I don't see what grew to eat up extra ram in the C031 case :/ )

18:22 <JamesMunns[m]> I'd have to look at the old ci builds, some of the buffered UART tests were failing semi consistently iirc

18:28 <danielb[m]> I'm fairly sure it's just that one device with the 6K RAM. So probably if we can find a few bytes, this wouldn't be a hard change to make?

18:36 <JamesMunns[m]> I did shrink the buffers way down to like 16B each, iirc

18:36 <JamesMunns[m]> idk, it was 6mo ago, so I have very little persisting state :)

18:37 <danielb[m]> fair 👍️

21:33 <M9names[m]> <RyanSlawson[m]> "Question for anyone here who..." <- > <@rslaw:matrix.org> Question for anyone here who knows a thing or two about `riscv-rt` - I'm currently using this for a `riscv32imfc-unknown-none-elf` target, but I'm having some... (full message at

21:33 <M9names[m]> <https://catircservices.org/_irc/v1/media/download/AaM40Uj75OjjEXF4Tbsq0rvdKbhpBzo1r4hB_srBv6ve8j2WgDEs4I1ch2eW461w3hHz5A078YbG9BJz8_saI2y_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy94QkpYTklyRkpsbEpvVHhlTkNyZ01scGc>)

22:08 <thejpster[m]> Is there a better way to handle alignment requirements in a trait?

22:08 <thejpster[m]> I copied the idea from mabez

22:08 <thejpster[m]> https://github.com/rust-embedded-community/embedded-storage/pull/59/files

22:14 <hjeldin__[m]> hey all, i'm trying to find out why a DMA transfer request gets stuck. i'm using embassy-stm32 on a stm32-f030r8 and driving a pwm ouput on a pin. i'm roughly following one of the examples (https://github.com/embassy-rs/embassy/blob/65d2dbcc3aedd241d337e17f1eb157d5927e7871/examples/stm32f4/src/bin/ws2812_pwm.rs#L95) but the call gets stuck on the await and the loop never continues. if i connect a logic analyzer i can actually see

22:14 <hjeldin__[m]> the pwm being driven, but all my tasks get stuck. any (unsafe) pointers?

22:22 <hjeldin__[m]> * hey all, i'm trying to find out why a DMA transfer request gets stuck. i'm using embassy-stm32 on a stm32-f030r8 and driving a pwm ouput on a pin. i'm roughly following one of the examples (https://github.com/embassy-rs/embassy/blob/65d2dbcc3aedd241d337e17f1eb157d5927e7871/examples/stm32f4/src/bin/ws2812\_pwm.rs#L95) but the call gets stuck on the await and the loop never continues. if i connect a logic analyzer i can actually

22:22 <hjeldin__[m]> see the pwm being driven, but all my tasks get stuck. any (unsafe) pointers? i'm a total noob, so like stuff to be aware of when dealing with pwm/dma or even the basic gotchas