01:05 <re_irc_> <@r​ubberduck203:m​atrix.org> Looking for opinions on an API. I maintain a BSP for the STM32F3Discovery. There are 8 leds in a circle that I expose as a `Leds` struct. Right now there’s an `into_array` method that consumes the struct and gives you an array of the individual leds, owned.

01:05 <re_irc_> <@r​ubberduck203:m​atrix.org> https://docs.rs/stm32f3-discovery/0.7.0/stm32f3_discovery/leds/struct.Leds.html#method.into_array

01:07 <re_irc_> <@r​ubberduck203:m​atrix.org> I just implemented an Iterator that returns mutable references instead. I was thinking of deprecating `into_array()`, but I’m not sure.

01:13 <re_irc_> <@f​irefrommoonlight:m​atrix.org> `[Switch<PEx<Output<PushPull>>, ActiveHigh>; 8]` is complicated

01:14 <re_irc_> <@r​ubberduck203:m​atrix.org> :shrug: generic type state types

01:15 <re_irc_> <@r​ubberduck203:m​atrix.org> But yes. It is.

01:16 <re_irc_> <@f​irefrommoonlight:m​atrix.org> There's no right answer, but here's the API I'd set up:

01:16 <re_irc_> <@f​irefrommoonlight:m​atrix.org> use stm32f3_discovery::Led;

01:16 <re_irc_> <@f​irefrommoonlight:m​atrix.org> // ...

01:16 <re_irc_> <@f​irefrommoonlight:m​atrix.org> ```rust

01:16 <re_irc_> <@f​irefrommoonlight:m​atrix.org> Led::Left.set_high()

01:20 <re_irc_> <@r​ubberduck203:m​atrix.org> I’m more interested in if you think it’s useful to have both `into_array()` and `iter_mut()`.

01:21 <re_irc_> <@f​irefrommoonlight:m​atrix.org> What's the intended use case? Go from there. I'm struggling to think of one where I wouldn't use a normal GPIO abstraction

01:21 <re_irc_> <@r​ubberduck203:m​atrix.org> The latter saves about 800 bytes and I can’t think of a case where I’d want to consume the struct the way into_array does.

01:22 <re_irc_> <@r​ubberduck203:m​atrix.org> https://github.com/rubberduck203/stm32f3-discovery/blob/331b7269ddffca9234331e3a4ea143384c3ba9c5/examples/leds.rs#L43

01:23 <re_irc_> <@r​ubberduck203:m​atrix.org> This is the new way, but the use case is the same.

01:23 <re_irc_> <@r​ubberduck203:m​atrix.org> I’m trying to think of there’s a use case for consuming the struct into an array I’m not thinking of.

01:24 <re_irc_> <@f​irefrommoonlight:m​atrix.org> That's the crux of this - what's the use case. You could start by asking "Who am I building this BSP for?"

01:26 <re_irc_> <@r​ubberduck203:m​atrix.org> People who can no longer compile the F3 crate tbh.

01:37 <re_irc_> <@f​irefrommoonlight:m​atrix.org> Related questions that may help:

01:37 <re_irc_> <@f​irefrommoonlight:m​atrix.org> - Is this for people new to embedded or rust embedded following the Discovery book (which uses this board)?

01:37 <re_irc_> <@f​irefrommoonlight:m​atrix.org> - Is this for someone learning to program on STM32, but familiar with other MCUs?

01:37 <re_irc_> <@f​irefrommoonlight:m​atrix.org> - Is this for someone considering if this MCU is suitable for use in a specific project?

01:42 <re_irc_> <@f​irefrommoonlight:m​atrix.org> For context, I just picked up a different Discovery board. Goals: Learn how to use its RF capability. Surprise bonus: Has peripherals I haven't used before, like Quadspi flash, digital microphone, and RGB LED. I'm using this as an excuse to learn to program them. (eg how to use QuadSPI on that chip) In...

01:42 <re_irc_> ... this case, the abstractions I'm looking for are high-level APIs to use the peripherals the chip has, like QSPI and SAI. I'm not saying a BSP like this isn't useful, but you may wish to identify an audience.

01:45 <re_irc_> <@r​ubberduck203:m​atrix.org> > People who can no longer compile the F3 crate tbh.

01:45 <re_irc_> <@r​ubberduck203:m​atrix.org> With that in mind, it should stay to remain compatible with the F3 crate.

01:45 <re_irc_> <@r​ubberduck203:m​atrix.org> Thanks for helping me get my head on straight.

01:47 <re_irc_> <@r​ubberduck203:m​atrix.org> On a side note, you might want to consider publishing that work as a BSP for folks who are less interested in learning all of that and just want to get something working quickly.

01:48 <re_irc_> <@r​ubberduck203:m​atrix.org> Of course, then you end up agonizing over an API like 3 people use. Lol

02:28 <re_irc_> <@b​radleyharden:m​atrix.org> I feel like o might have asked this before, but I'm not sure. If a field of a struct is never read or modified after creation anywhere in the binary, will it be optimized away?

02:28 <re_irc_> <@f​irefrommoonlight:m​atrix.org> I'm going to publish HAL examples instead - that way the code is more portable

02:31 <re_irc_> <@f​irefrommoonlight:m​atrix.org> There are two facets to what this will do. 1: Other users of the present (or similar) external peripheral (eg the QSPI flash) can see how I'm interacting with the HAL abstraction, so could port it to other HALs etc. 2: Other STM32 users can see how I implemented the HAL functions used to configure the...

02:31 <re_irc_> ... MCU peipherals

02:33 <re_irc_> <@d​irbaio:m​atrix.org> bradleyharden: I don't think the compiler optimizes that, no :\

02:33 <re_irc_> <@b​radleyharden:m​atrix.org> It will just copy it around on every function call?

02:35 <re_irc_> <@d​irbaio:m​atrix.org> if the function is not inlined and you're not using LTO, probably

02:36 <re_irc_> <@r​ubberduck203:m​atrix.org> If you’re sure it will never be read, you can use PhantomData, which is zero sized.

09:52 <re_irc_> <@s​ympatron:m​atrix.org> Wouldn't a `Leak` auto trait be the other way round than `Sized`? Meaning all types are implicitly `Leak` (as with `Sized`, but all parameters would implicitly require only `?Leak`, expect for methods that can lead to leaking (`mem::forget`, `Rc`, etc.) which would explicitly require `T: Leak`. It's...

09:52 <re_irc_> ... essentially how `Sync` and `Send` work, isn't it? You would have to `unsafe impl !Leak for T`.

09:52 <re_irc_> <@s​ympatron:m​atrix.org> I know the Rust core team doesn't seem to like it, but it would solve so many problems in embedded, that I think it would be worth it.

09:53 <re_irc_> <@s​ympatron:m​atrix.org> Thinking about it, I think it would have exactly the same rules as `Send` and `Sync`. So it wouldn't be something entirely new.

11:33 <re_irc_> <@t​halesfragoso:m​atrix.org> Probably it would be a bit harder to decide which methods to have T: Leak at first

11:34 <re_irc_> <@t​halesfragoso:m​atrix.org> And they would have to take all of them before giving us a PhatomLeaked type

11:35 <re_irc_> <@t​halesfragoso:m​atrix.org> Maybe dirbaio have more concerns about it

12:25 <re_irc_> <@r​uabmbua:m​atrix.org> Random question, if anyone has ever tried it here: the esp32-c3 chips claim to have a built in USB to JTAG/serial Interface, so in theory there is no need for a debug probe.

12:25 <re_irc_> <@r​uabmbua:m​atrix.org> I can only find a reference to that in the feature list of the datasheet, but e.g. the pin table does not list the USB pins.

12:25 <re_irc_> <@r​uabmbua:m​atrix.org> Has anyone any experience with these chips. Asking here, since I am a newbie to esp32, and I guess there might be some overlap. (Also, I am going to use rust ;-)(

14:43 <re_irc_> <@d​khayes117:m​atrix.org> ruabmbua https://matrix.to/#/#esp-rs:matrix.org

14:45 <re_irc_> <@r​uabmbua:m​atrix.org> Oh thx

21:05 <re_irc_> <@r​obyoung:m​atrix.org> does anyone know when there may be a new release of `cortex-m`? I'm struggling to run the microbit doctests on my Apple M1 without this change https://github.com/rust-embedded/cortex-m/commit/a9fb68728a0b98b98da3e4215670b2f1c1b6b982#diff-8b746d78ccc78f7fccbe180d9e957fc87d1116a97c89e19f4aafe49f82ad0b4c