<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.
<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.
<re_irc_> <@f​irefrommoonlight:m​atrix.org> `[Switch<PEx<Output<PushPull>>, ActiveHigh>; 8]` is complicated
<re_irc_> <@r​ubberduck203:m​atrix.org> :shrug: generic type state types
<re_irc_> <@r​ubberduck203:m​atrix.org> But yes. It is.
<re_irc_> <@f​irefrommoonlight:m​atrix.org> There's no right answer, but here's the API I'd set up:
<re_irc_> <@f​irefrommoonlight:m​atrix.org> use stm32f3_discovery::Led;
<re_irc_> <@f​irefrommoonlight:m​atrix.org> // ...
<re_irc_> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Led::Left.set_high()
<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()`.
<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
<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.
<re_irc_> <@r​ubberduck203:m​atrix.org> This is the new way, but the use case is the same.
<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.
<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?"
<re_irc_> <@r​ubberduck203:m​atrix.org> People who can no longer compile the F3 crate tbh.
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Related questions that may help:
<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)?
<re_irc_> <@f​irefrommoonlight:m​atrix.org> - Is this for someone learning to program on STM32, but familiar with other MCUs?
<re_irc_> <@f​irefrommoonlight:m​atrix.org> - Is this for someone considering if this MCU is suitable for use in a specific project?
<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...
<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.
<re_irc_> <@r​ubberduck203:m​atrix.org> > People who can no longer compile the F3 crate tbh.
<re_irc_> <@r​ubberduck203:m​atrix.org> With that in mind, it should stay to remain compatible with the F3 crate.
<re_irc_> <@r​ubberduck203:m​atrix.org> Thanks for helping me get my head on straight.
<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.
<re_irc_> <@r​ubberduck203:m​atrix.org> Of course, then you end up agonizing over an API like 3 people use. Lol
fabic has joined #rust-embedded
starblue has joined #rust-embedded
starblue3 has quit [Ping timeout: 250 seconds]
<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?
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I'm going to publish HAL examples instead - that way the code is more portable
<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...
<re_irc_> ... MCU peipherals
<re_irc_> <@d​irbaio:m​atrix.org> bradleyharden: I don't think the compiler optimizes that, no :\
<re_irc_> <@b​radleyharden:m​atrix.org> It will just copy it around on every function call?
<re_irc_> <@d​irbaio:m​atrix.org> if the function is not inlined and you're not using LTO, probably
<re_irc_> <@r​ubberduck203:m​atrix.org> If you’re sure it will never be read, you can use PhantomData, which is zero sized.
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
tokomak has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
wezm has joined #rust-embedded
wezm has quit [Remote host closed the connection]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
fabic has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
cr1901 has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
<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...
<re_irc_> ... essentially how `Sync` and `Send` work, isn't it? You would have to `unsafe impl !Leak for T`.
<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.
<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.
tokomak has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
<re_irc_> <@t​halesfragoso:m​atrix.org> Probably it would be a bit harder to decide which methods to have T: Leak at first
<re_irc_> <@t​halesfragoso:m​atrix.org> And they would have to take all of them before giving us a PhatomLeaked type
<re_irc_> <@t​halesfragoso:m​atrix.org> Maybe dirbaio have more concerns about it
<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.
<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.
<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 ;-)(
<re_irc_> <@d​khayes117:m​atrix.org> ruabmbua https://matrix.to/#/#esp-rs:matrix.org
<re_irc_> <@r​uabmbua:m​atrix.org> Oh thx
SomeWeirdAnon has joined #rust-embedded
fabic has quit [Ping timeout: 250 seconds]
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
inara has quit [Quit: Leaving]
inara has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
richbridger has joined #rust-embedded
<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
Guest6143 has joined #rust-embedded
Guest6143 has quit [Client Quit]
SomeWeirdAnon has quit []