10:19 <diondokter[m]> Ugh, naming things is hard...... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/obqHEfDFelLkIwinYHMVpPhh>)

10:23 <BenPh[m]> what would the usage be? `thing.....(???)`

10:23 <BenPh[m]> i asume `thing` implements the `SpiDevice` trait. what is the shape of the argument? `& impl ???`, `embedded_hal::SpiCommandEnum::Foo(...)`?

10:23 <BenPh[m]> is the context "im putting together something that implements `SpiDevice` and this is my struct specific method" or is the context more "making changes to the e-hal spi module"?

10:24 <diondokter[m]> It'd be something like device.give_command(Foo)

10:24 <BenPh[m]> and device is a project specific implementor of e-hal SpiDecive trait, I'm assuming?

10:25 <diondokter[m]> No, it uses the SpiDevice trait

10:25 <BenPh[m]> ...and Foo is a project-specific type?

10:25 <diondokter[m]> Just a normal device driver

10:25 <diondokter[m]> Yes

10:25 <diondokter[m]> Also part of the device driver

10:28 <BenPh[m]> so under the hood, something, somewhere, implements the SpiDevice trait so that somewhere SpiDevice::write(...) is used using a buff loaded up by some sort of serialisation of Foo. Do I understand the context to a close enough level?

10:29 <diondokter[m]> Yes

10:35 <BenPh[m]> I would probably consider `dispatch_command`, `fire_and_forget_command`, or `send_command`, depending on what the typical use-case is intended, and what self-documenting fits.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/rBdsZjncUmFZETpoFXjuIiOv>)

10:38 <BenPh[m]> out of scope of your question, and perhaps a pathalogical approach for your use case, so appologies if it's doesn't fit: Perhaps consider command.send(device), where device is something that can send. Could be spi, could be a tx/rx channel, usb device, etc.

10:39 <BenPh[m]> I hope that helps.

10:40 <diondokter[m]> Thanks! Dispatch isn't bad.

10:41 <diondokter[m]> BenPh[m]: I don't think this inversion would work well here

17:17 <andar1an[m]> Has anyone bumped into any oss Rust projects to do with high pressure aeroponics using either arduino or raspberry pi for hobbiest use?

17:17 <andar1an[m]> * arduino or some SBC like raspberry pi

18:56 <Amit[m]> diondokter: big ups on the optimize_for_size PR in libs! We're going to use it for Tock as soon as it lands in a nightly. Will be exciting to see it start getting used for real inside the core lib

18:57 <diondokter[m]> Amit[m]: Thanks! Yes, tomorrow I think I'll submit two PRs that actually use the flag

18:59 <Amit[m]> Curious if/how people are using `panic_immediate_abort` in bare-metal embedded scenarios. It's a big for size (~4kB compared to an empty panic handler in my brief experiments), but presumably something needs to handle the hard fault that inevitably might occur. Are you checking for this in, say, a hard fault ISR?

19:00 <Amit[m]> (the relationship is that I learned about that from diondokter's PR referencing it :) )

19:00 <diondokter[m]> Any panic will just become a `udf` instruction. So yeah, you'll likely want to do something with the hardfault handler.

19:00 <diondokter[m]> But in production hopefully you already did that :P

19:01 <Amit[m]> Sure, the expectation is a bit different with a normal panic handler handing explicit panics vs other sources of hard faults

19:01 <diondokter[m]> Some of the binary size savings come from not having to generate the panic branches.

19:01 <diondokter[m]> But a lot of it comes from not having to save the panic info (messages and file paths)

19:03 <Amit[m]> Right, so in development settings, I care about having those for sure, and the use is much much larger than 4kB, but in production might be fine to just note the faulting context (e.g. dumping the PC and other registers to flash and restarting)

19:03 <diondokter[m]> Yep, pretty much the same as with a panic really

19:03 <diondokter[m]> Log and reboot

19:04 <diondokter[m]> Though, apparently you can recover from many faults in cortex-m.

19:04 <diondokter[m]> But ehh... you have to know what you're doing to make that work well

19:09 <Amit[m]> diondokter[m]: If you wanted to get very very fancy and extremely expensive, you could use memory faults to emulate virtual memory in software. Which would be a fun demo if you wanted to turn a 20MHz CPU into a, in practice, ~2KHz CPU.

19:23 <JamesMunns[m]1> Hey, I mean if esp-rs could use it for emulating atomics... :D

19:25 <JamesMunns[m]1> <Amit[m]> "Right, so in development..." <- Yeah, I know dirbaio uses it in production, he logs to an in-mem ring buffer, so after panic+reboot it's still retrievable. you can save a HUGE amount using P-I-A, like 10-40% of the whole codesize of your program, depending on how many panics you and your deps have.

19:37 <danielb[m]> <JamesMunns[m]1> "Hey, I mean if esp-rs could..." <- not anymore

19:41 <JamesMunns[m]1> yeah, I know :D