crabbedhaloablut has quit [Ping timeout: 244 seconds]
crabbedhaloablut has joined #rust-embedded
nexos has quit [Quit: Leaving]
xnor has quit [Read error: Connection reset by peer]
xnor has joined #rust-embedded
fabic has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
tokomak has joined #rust-embedded
<re_irc_> <@w​illeml:m​> Hey could someone help me figure out this code I am trying to port from C++ to do QSPI flash? I have so far gotten to this point: but I cannot figure out what I need to do in order to port...
<re_irc_> ... over because I dont understand what is happening and therefor what the rust equivalent of...
<re_irc_> <@w​illeml:m​> Any help and or other tips on QSPI flash storage on stm32 would be much appreciated
<re_irc_> <@w​illeml:m​> And I do know that the STM32F7 HAL already has some QSPI stuff, but I do not understand its implementation, or at least, how to use it for the Flash chip that I have to use
<re_irc_> <@d​irbaio:m​> StatusRegister1 seems to be a 8bit register where bit 0 indicates "busy"
<re_irc_> <@f​irefrommoonlight:m​> Hey - regrettably I haven't familiarized myself with it, but have you dove into the RM yet? There should be a section called "QUADSPI usage", ie "Indirect mode procedure", followed by a sequence of steps with exactly what you need to do
<re_irc_> <@w​illeml:m​> the RM?
<re_irc_> <@f​irefrommoonlight:m​> Reference Manual
<re_irc_> <@w​illeml:m​> dirbaio: How would I go about creating registers?
<re_irc_> <@w​illeml:m​> firefrommoonlight: Oh, thanks
<re_irc_> <@f​irefrommoonlight:m​> Use the [Peripheral Access Crate (PAC)](
<re_irc_> <@d​irbaio:m​> `wait` is sending a qspi command to read that reg from the flash chip, looping until busy=0
<re_irc_> <@f​irefrommoonlight:m​> Eg, `WB`'s starts with:
<re_irc_> <@f​irefrommoonlight:m​> ```rust
<re_irc_> <@f​irefrommoonlight:m​> 1. Specify a number of data bytes to read or write in the QUADSPI_DLR.
<re_irc_> <@f​irefrommoonlight:m​> 2. Specify the frame format, mode and instruction code in the QUADSPI_CCR.
<re_irc_> <@d​irbaio:m​> that's a register of the flash chip, not of the qspi peripheral
<re_irc_> <@d​irbaio:m​> you'll find it documented in the flash chip's datasheet
<re_irc_> <@w​illeml:m​> firefrommoonlight: Based on what I have ported so far, that sounds right
<re_irc_> <@d​irbaio:m​> no real need to "create" it, just read it as a rust u8 and then check the busy bit with `val & 1 != 0`
<re_irc_> <@d​irbaio:m​> the `class StatusRegister1` seems to be a wrapper over that u8 so you can do `.getBUSY()` instead of `& 1` but in the end it's the same
<re_irc_> <@w​illeml:m​> Oh, so that register class is just a wrapper to read from the chip?
<re_irc_> <@d​irbaio:m​> ya
<re_irc_> <@w​illeml:m​> page 10 of I believe, says that busy just says if its programming or erasing
<re_irc_> <@d​irbaio:m​> it's doing QSPI things to read 1 byte, putting the byte instide the StatusRegister1, then use `.getBUSY()` to read bit 0
<re_irc_> <@d​irbaio:m​> in an exceptionally ugly way with these `reinterpret_casts` 🤣
<re_irc_> <@w​illeml:m​> Yeah, it took me a while to figure out what those were, as I have no embedded C++ experience beyond blinky arduino
<re_irc_> <@d​irbaio:m​> embedded C++ is horrible 🤣
<re_irc_> <@w​illeml:m​> Yeah, I noticed lol, especially when you compare it to the wonderful rust embedded ecosystem
<re_irc_> <@w​illeml:m​> Also, I have no idea if any of the code I wrote is good, I mean, it passes `cargo check` but there is a lot of `unsafe` stuff in there...
<re_irc_> <@d​irbaio:m​> looks OK to me!
<re_irc_> <@d​irbaio:m​> it's normal to have lots of unsafe when using the PAC directly due to how the PAC API is generated...
<re_irc_> <@w​illeml:m​> Awesome, thanks for the help, now I just have to implement reading and writing all of that stuff lol, also if I were to make a driver crate for this chip (so that someone else could use this easily for some other project) how would I go about doing that? Because currently everything needed is in one module so...
<re_irc_> ... should be easy to separate...
<re_irc_> <@w​illeml:m​> Although, I am using alloc in one part of it, which could probably be avoided except that I don't know how to make a slice that is the right size easily without doing some super ugly code...
<re_irc_> <@w​illeml:m​> basically `[0u32; 100]` except that `100` would be a runtime variable
<re_irc_> <@d​irbaio:m​> for these usually having the caller pass you the buffer works
<re_irc_> <@d​irbaio:m​> instead of `read(..., len: usize) -> Vec<u8>`, do `read(..., buf: &mut [u8])`
<re_irc_> <@d​irbaio:m​> that reads `buf.len()` bytes into buf
<re_irc_> <@d​irbaio:m​> hopefully the caller knows the size and can stack-allocate it
<re_irc_> <@d​irbaio:m​> and if not they can still use Vec, but now the decision is on them, you're not forcing it
<re_irc_> <@w​illeml:m​> Ah ok, that makes sense I guess
<re_irc_> <@d​irbaio:m​> you don't need data_length, you can get it from `data.len()`
<re_irc_> <@d​irbaio:m​> 👌
<re_irc_> <@w​illeml:m​> yeah, that makes it nicer
<re_irc_> <@w​illeml:m​> Need to turn my old iMacs into 3rd and 4th displays
<re_irc_> <@w​illeml:m​> Any idea on why that is happening? that is bitwise and right?
<re_irc_> <@w​illeml:m​> oh nevermind...
<re_irc_> <@w​illeml:m​> Looking at it for another minute made me realise...
<re_irc_> <@w​illeml:m​> dirbaio:
<re_irc_> <@w​illeml:m​> oops
<re_irc_> <@w​illeml:m​> there any difference between these two?
<re_irc_> <@w​illeml:m​> because the second one (original) seems to be way more complicated than it needs to be...
<re_irc_> <@n​ull_ptr:k​> Story of C++ tbh
<re_irc_> <@n​ull_ptr:k​> The C++ code clears all bits in SR2 except for QE, while the rust code keeps all bits in SR2.
<re_irc_> <@n​ull_ptr:k​> Haven't looked at the data sheet though if it makes a difference here.
<re_irc_> <@w​illeml:m​> `let mut registers = [0u32, 2 & status_two[0]];` would that make them equivalent?
<re_irc_> <@w​illeml:m​> (bit 1 is QE afaik)
<re_irc_> <@n​ull_ptr:k​> Yeah, should do.
<re_irc_> <@w​illeml:m​> Thanks!
<re_irc_> <@w​illeml:m​> is C++ `~(1)` equivalent to Rust `!(1)`?
<re_irc_> <@s​ajattack:m​> yes
<re_irc_> <@s​ajattack:m​> c++ has a separate operator for bitwise and logical not, rust uses the same for both
<re_irc_> <@w​illeml:m​> Ah
<re_irc_> <@w​illeml:m​> Thanks
<re_irc_> <@w​illeml:m​> well apparently is always busy
<re_irc_> <@w​illeml:m​> Any idea on how to make probe-run not die when lots of stuff gets printed very fast?
<re_irc_> <@h​untc:m​> willeml: You might be better to ask this in the probe-rs room, but I'm wondering if it is associated with the RTT library you're using... i.e. perhaps the problem could be on the RTT side. Just a guess though.
<re_irc_> <@w​illeml:m​> Hmm, I am just using `rtt-target`
<re_irc_> <@h​untc:m​> So, by default, the buffer is 1KiB and `rprintln` is best-effort. You could try increasing that buffer size. Also, do you use `rtt_init_print` to initialise it?
<re_irc_> <@w​illeml:m​> Yes
<re_irc_> <@h​untc:m​> Perhaps flash your firmware via some other means and use the `` - just to isolate your issue.
<re_irc_> <@w​illeml:m​> Where would I find that app, and is there an STLink version?
<re_irc_> <@h​untc:m​> Ah - I had assumed JLink. Apologies.
<re_irc_> <@w​illeml:m​> No worries
<re_irc_> <@h​untc:m​> Perhaps ask in the probe-rs room. You can set up probe-rs to output debug, which may help diagnose the issue.
<re_irc_> <@w​illeml:m​> Alright, I will ask there, thanks!
fabic_ has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
fabic_ has quit [Read error: Connection reset by peer]
fabic has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic has quit [Remote host closed the connection]
cr19011 has joined #rust-embedded
cr1901 has quit [Ping timeout: 264 seconds]
fabic has joined #rust-embedded
Shell has quit [Quit: ZNC 1.8.2 -]
Shell has joined #rust-embedded
Shell has quit [Remote host closed the connection]
Shell has joined #rust-embedded
Shell has quit [Remote host closed the connection]
Shell has joined #rust-embedded
cr1901 has joined #rust-embedded
cr19011 has quit [Ping timeout: 264 seconds]
fabic has quit [Remote host closed the connection]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
SomeWeirdAnon has joined #rust-embedded
SomeWeirdAnon is now known as SomeAwayAnon
SomeAwayAnon is now known as SomeWeirdAnon
SomeWeirdAnon is now known as SomeAwayAnon
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
wose has quit [Ping timeout: 244 seconds]
wose has joined #rust-embedded
tokomak_ has joined #rust-embedded
tokomak has quit [Ping timeout: 264 seconds]
xnor has left #rust-embedded [#rust-embedded]
tokomak_ is now known as tokomak
fabic has quit [Ping timeout: 252 seconds]
xnor has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc_> <@l​achlansneff:m​> I'm using dirbaio's fork of probe-run (which has a more up-to-date version of probe-rs), but I'm getting `Operating timed out`.
<re_irc_> <@l​achlansneff:m​> When flashing an nrf9160
<re_irc_> <@l​achlansneff:m​> ❯ RUST_LOG=debug cargo rb hello 12:54:37
<re_irc_> <@l​achlansneff:m​> Running `probe-run --chip nRF9160_xxAA target/thumbv7em-none-eabihf/debug/hello`
<re_irc_> <@l​achlansneff:m​> Finished dev [optimized + debuginfo] target(s) in 0.03s
<re_irc_> <@l​achlansneff:m​> (HOST) INFO flashing program (6.64 KiB)
<re_irc_> <@l​achlansneff:m​> Any ideas for how to get this to work?
<re_irc_> <@y​atekii:m​> hmm there is not much log messages to go from :/
<re_irc_> <@l​achlansneff:m​> Yeah, no logs really :/
<re_irc_> <@l​achlansneff:m​> So I'm not even sure where it's failing
fabic has quit [Ping timeout: 258 seconds]
<re_irc_> <@d​irbaio:m​> nrf91 is `thumbv8m.main-none-eabi`, not `thumbv7em-none-eabihf`
<re_irc_> <@l​achlansneff:m​> oh, oops
<re_irc_> <@l​achlansneff:m​> Still times out :/
<re_irc_> <@d​irbaio:m​> I think that timeout is from RTT attach
<re_irc_> <@d​irbaio:m​> can you post logs with `-vv`?
<re_irc_> <@l​achlansneff:m​> Syre
<re_irc_> <@d​irbaio:m​> what ar eyou trying to run?
<re_irc_> <@l​achlansneff:m​> Just the knurling app-template hello
<re_irc_> <@l​achlansneff:m​> So using defmt and whatnot
<re_irc_> <@l​achlansneff:m​> Ah, might just be because RTT is going to work in this situation
<re_irc_> <@d​irbaio:m​> does it take ~5s to fail?
<re_irc_> <@l​achlansneff:m​> Yeah
<re_irc_> <@d​irbaio:m​> it's timing out here
<re_irc_> <@d​irbaio:m​> which means it's never hitting main
<re_irc_> <@d​irbaio:m​> ie the firmware is failing to boot
<re_irc_> <@d​irbaio:m​> who knows why
<re_irc_> <@d​irbaio:m​> have you set memory.x correctly?
<re_irc_> <@l​achlansneff:m​> Ah, there are some extra steps I need to do
<re_irc_> <@l​achlansneff:m​>
<re_irc_> <@d​irbaio:m​> ah, right
<re_irc_> <@d​irbaio:m​> you can get your firmware to run without SPM if you make it start at 0x0
<re_irc_> <@d​irbaio:m​> then it runs in secure mode
<re_irc_> <@d​irbaio:m​> but both nrf-hal and nrfxlib expect to run in NS mode
<re_irc_> <@l​achlansneff:m​> And it works!
<re_irc_> <@l​achlansneff:m​> Thanks!
Shell has quit [Quit: ZNC 1.8.2 -]
Shell has joined #rust-embedded
SomeAwayAnon has quit []
<re_irc_> <@l​achlansneff:m​> `log` should work on no_std, right?
<re_irc_> <@j​amesmunns:m​> yup
<re_irc_> <@j​amesmunns:m​> I know dirbaio also has a shim in `smoltcp` to switch between defmt and log for embedded logging.
<re_irc_> <@l​achlansneff:m​> Hmm
<re_irc_> <@l​achlansneff:m​> I'm using a no_std crate that uses log, and I get the missing std warning.
<re_irc_> <@j​amesmunns:m​> `default-features = false`?
<re_irc_> <@d​irbaio:m​> the one in smoltcp is meh, use this one
<re_irc_> <@d​irbaio:m​> sadly the weird macro resolution means it can't be a separate lib crate, you have to copypaste it into every crate
<re_irc_> <@j​amesmunns:m​> Ah, you'd need something like `$crate::feature` or something?
<re_irc_> <@d​irbaio:m​> defmt proc macros break if you try to reexport them
<re_irc_> <@j​amesmunns:m​> oh
<re_irc_> <@l​achlansneff:m​> jamesmunns: I think log doesn't have `std` by default.
<re_irc_> <@j​amesmunns:m​> If we put that shim in `defmt` itself would that work better?
<re_irc_> <@d​irbaio:m​> because they emit code that does `defmt::blah`, and `defmt` is not defined in the user crate's scope
<re_irc_> <@j​amesmunns:m​> like, just change the defmt macros themselves to be able to swap over to log as a general backend?
<re_irc_> <@j​amesmunns:m​> and maybe even handle the syntax diffs in the defmt proc macros?
<re_irc_> <@j​amesmunns:m​> not sure if you can mess with the strings tho
<re_irc_> <@d​irbaio:m​> very tricky
<re_irc_> <@j​amesmunns:m​> (syntax diff I mean the `{u8:}` Format stuff)
<re_irc_> <@d​irbaio:m​> for example, printing something with `{:?}` requires `defmt::Format` or `core::fmt::Debug` impl depending on what's enabled
<re_irc_> <@j​amesmunns:m​> whew
<re_irc_> <@d​irbaio:m​> it gets ugly fast
<re_irc_> <@j​amesmunns:m​> makes sense
<re_irc_> <@d​irbaio:m​> also another advantage of having it in-crate is
<re_irc_> <@d​irbaio:m​> if you do `macro_rules! panic {..}`, that'll override `panic!` in the entire crate
<re_irc_> <@j​amesmunns:m​> oh THATS fancy
<re_irc_> <@d​irbaio:m​> so you don't miss panic messages because in one file you forgot to `use defmt::panic`
<re_irc_> <@j​amesmunns:m​> 👍️
<re_irc_> <@d​irbaio:m​> so you plop in your crate, do `mod fmt` FIRST in (did you know mod order matters for in-crate macro resolution? it sucks)
<re_irc_> <@d​irbaio:m​> and it Just Works
<re_irc_> <@j​amesmunns:m​> dirbaio: Yeah, MBEs are one (maybe THE only?) thing where order matters.
<re_irc_> <@d​irbaio:m​> what I hate is order matters for in-crate macros but not for macros imported from other crates (declarative or proc)
<re_irc_> <@d​irbaio:m​> it's like
<re_irc_> <@d​irbaio:m​> WTF
<re_irc_> <@d​irbaio:m​> WHY
<re_irc_> <@j​amesmunns:m​> I mean, order even matters within a single file
<re_irc_> <@j​amesmunns:m​> like, you can't use a macro before you declare it
<re_irc_> <@j​amesmunns:m​> it's like we're in C or something
<re_irc_> <@d​irbaio:m​> but you can call an out-of-crate macro before you `use` it
<re_irc_> <@d​irbaio:m​> out-of-crate macros work mostly like normal items
<re_irc_> <@d​irbaio:m​> but not in-crate >_<
<re_irc_> <@l​achlansneff:m​> It turned out that the `log` dependency was being unified with `log` from build-dependencies
<re_irc_> <@l​achlansneff:m​> Had to turn on resolver 2
<re_irc_> <@j​amesmunns:m​> ahhh
<re_irc_> <@j​amesmunns:m​> yeah, that'll do it
<re_irc_> <@l​achlansneff:m​> :/
tokomak has quit [Read error: Connection reset by peer]
<re_irc_> <@y​atekii:m​> has anyone ever experienced that zola syntax highlighting does not work?
<re_irc_> <@f​irefrommoonlight:m​> Going back to the QSPI talk earlier: Is there a good reason why only indirect mode was implemented on the F7 module? Ie an obstacle making memory-mapped mode tough? It seems like memory-mapped mode would be a good default
<re_irc_> <@f​irefrommoonlight:m​> Since it should act more like the built in Flash peripheral interaction for STM32
<re_irc_> <@f​irefrommoonlight:m​> (I'm working on a QSPI module now)
<re_irc_> <@f​irefrommoonlight:m​> While indirect acts more like... normal SPI I suppose
<cr1901> Why is phantomdata used so pervasively throughout the GPIO HAL impl for STM32F4? What happens if you just have MODE owned directly by each struct?
<re_irc_> <@d​irbaio:m​> since modes are ZSTs it'd be exactly thesame
<re_irc_> <@t​halesfragoso:m​> It's mostly because they don't need it, but still need to be generic over it
<re_irc_> <@d​irbaio:m​> maybe PhantomData helps the reader understand it's only for type hacks, it doesn't contain actual data
<cr1901> Hmmm
<re_irc_> <@d​irbaio:m​> in this case it's exactly the same with and without
<cr1901> phantom_data is a lang item, so I thought maybe there might be something special about using it even w/ ZSTs
<re_irc_> <@y​ruama_lairba:m​> hi, is there a way to know the amount of flash and ram used by a program ?
<re_irc_> <@t​halesfragoso:m​> several ways, easy way is probably to install `cargo-binutils` and use `cargo size --release`
<re_irc_> <@t​halesfragoso:m​> note that doesn't try to calculate stack usage
<re_irc_> <@f​irefrommoonlight:m​> IMO in that and other cases embedded I've seen, phantom data is obfuscation
<re_irc_> <@f​irefrommoonlight:m​> It mades the lib tougher to understand, and doesn't provide much value
<re_irc_> <@t​halesfragoso:m​> it's just a easy zero sized type, and it's very useful
<re_irc_> <@d​irbaio:m​> it's useful (needed?) if you want your struct to have a lifetime without actually storeing a pointer
<re_irc_> <@t​halesfragoso:m​> if you want generics without really using it then you need PhantomData
<re_irc_> <@t​halesfragoso:m​> type state are full of these use cases
<re_irc_> <@f​irefrommoonlight:m​> Thank you for the explanation
<re_irc_> <@d​irbaio:m​> struct Uart<'a, T: Instance> {
<re_irc_> <@d​irbaio:m​> _phantom: PhantomData<&'a mut T>,
<re_irc_> <@d​irbaio:m​> ```rust
<re_irc_> <@d​irbaio:m​> }
<re_irc_> <@d​irbaio:m​> where T is for example UART1, UART2...
<re_irc_> <@d​irbaio:m​> `UART1` is zero-sized, but `&'a mut UART1` is 4 bytes
<re_irc_> <@d​irbaio:m​> and since you're not storing anything in the `UART1`, having a pointer to it is useless
<re_irc_> <@f​irefrommoonlight:m​> [Here's the official Rust docs page]( ,although it doesn't necessarily explain why it's used here
<re_irc_> <@f​irefrommoonlight:m​> It includes several example uses
<re_irc_> <@f​irefrommoonlight:m​> dirbaio: How would you access the uart reg blocks using that struct?
<re_irc_> <@d​irbaio:m​> `T::regs()`
<re_irc_> <@f​irefrommoonlight:m​> How does it know which methods are avail?
<re_irc_> <@d​irbaio:m​> just by knowing the type you can get the reg pointer since it's constant
<re_irc_> <@t​halesfragoso:m​> the Instance trait
<re_irc_> <@f​irefrommoonlight:m​> Thank you
<re_irc_> <@f​irefrommoonlight:m​> Would that allow you to be generic over all `UART` etcs, even if they don't deref to the same? Eg:
<re_irc_> <@f​irefrommoonlight:m​> impl<U> Usart<U>
<re_irc_> <@f​irefrommoonlight:m​> ```rust
<re_irc_> <@f​irefrommoonlight:m​> where
<re_irc_> <@d​irbaio:m​> impl macro is called from here
<re_irc_> <@d​irbaio:m​> all `regs()` has to return the same PAC type yeah
<re_irc_> <@d​irbaio:m​> if they don't, you have to cast raw pointers
<re_irc_> <@f​irefrommoonlight:m​> dirbaio: When would you do this, for example?
<re_irc_> <@d​irbaio:m​> that Uart struct is one example
<re_irc_> <@f​irefrommoonlight:m​> I've been adhering consistently to the "periph struct owns its reg block" model, which is perhaps why it doesn't come up
<re_irc_> <@d​irbaio:m​> in embassy drivers can own or borrow the regblock
<re_irc_> <@d​irbaio:m​> so Uart has a lifetime
<re_irc_> <@d​irbaio:m​> it's `'static` if it owns, and non-static if it borrows
<re_irc_> <@f​irefrommoonlight:m​> It looks like this quote from the Rust docs is relevant here:
<re_irc_> <@f​irefrommoonlight:m​> Adding a field of type PhantomData<T> indicates that your type owns data of type T. This in turn implies that when your type is dropped, it may drop one or more instances of the type T. This has bearing on the Rust compiler’s drop check analysis.
<re_irc_> <@f​irefrommoonlight:m​> If your struct does not in fact own the data of type T, it is better to use a reference type, like PhantomData<&'a T> (ideally) or PhantomData<*const T> (if no lifetime applies), so as not to indicate ownership.
<re_irc_> <@d​irbaio:m​> but when borrowing you don't want to physically store a pointer to the borrowed UART2, it has no useful info
<re_irc_> <@d​irbaio:m​> so with PhantomData you save 4 bytes of RAM
<re_irc_> <@d​irbaio:m​> you don't want the pointer, but you do want the generic lifetime so the borrow checker will check stuff for you
<re_irc_> <@f​irefrommoonlight:m​> Is that to handle buses, with generic drivers that expect ownership over the bus struct?
<re_irc_> <@t​halesfragoso:m​> it's just a design, and gets rid of weird free methods
<re_irc_> <@t​halesfragoso:m​> if you want to re-use, use the driver borrowing, otherwise pass the owned struct
<re_irc_> <@f​irefrommoonlight:m​> This is starting to make sense, in regards to generic APIs, expectations of generic drivers etc... ie what thalesfragoso opened with
<re_irc_> <@f​irefrommoonlight:m​> I've been moving away from generic drivers in my own code to simplify things and have tighter control over what code I'm relying on, which is perhaps another reason I haven't encountered a use
<re_irc_> <@f​irefrommoonlight:m​> I appreciate the info; this is making more sense
<cr1901> I don't see a way around this, but... to implement Parts, it seems STM32 HAL consumes the GPIO Register block to return a Parts struct, after which point the Parts struct unsafely accesses the GPIO register directly via deref a pointer
<cr1901> I guess the idea is "if you have created a Parts struct, it's as-if you still had access to the GPIO reg block, so you're not doing any more unsafe things than you were already
<re_irc_> <@f​irefrommoonlight:m​> Of note, you also need the pointer access of GPIO if you want a `Pin` abstraction, which is IMO useful
<re_irc_> <@d​irbaio:m​> this is because the PACs insist on having per-peripheral ownership
<re_irc_> <@d​irbaio:m​> which in some cases, like GPIO, is wrong
<re_irc_> <@f​irefrommoonlight:m​> Otherwise your set APIs would look something like this:
<re_irc_> <@f​irefrommoonlight:m​> gpiob.set_high(5);
<re_irc_> <@f​irefrommoonlight:m​> ```rust
<re_irc_> <@f​irefrommoonlight:m​> Instead of
<re_irc_> <@t​halesfragoso:m​> cr1901: it's a bit harder than that because the gpio shares some regs between pins, but yeah, it took ownership of the singleton, so nobody else can `safely` use it
<re_irc_> <@d​irbaio:m​> stm32-metapac doesn't have singletons, it's up to the HALs to create the singletons
<re_irc_> <@d​irbaio:m​> so it can create a GPIOA singleton or one per pin like PA0, PA1, PA2..
<re_irc_> <@f​irefrommoonlight:m​> dirbaio: Yea - this is inherently a mismatch between hardware layout and the desired abstraction
<cr1901> GPIO is a singleton?
<cr1901> I thought the entire Peripherals struct was a single
<re_irc_> <@d​irbaio:m​> there's more cases of the PAC ownership model being wrong
<cr1901> ton*
<re_irc_> <@d​irbaio:m​> for example
<re_irc_> <@d​irbaio:m​> nrf52840-pac has SPI0, SPIM0, SPIS0, TWI0, TWIM0, TWIS0 singletons
<re_irc_> <@d​irbaio:m​> but they're all the same physical peripheral, so you can only really use one at the same time
<re_irc_> <@f​irefrommoonlight:m​> Oh that's surprising
<re_irc_> <@d​irbaio:m​> but with the per-peripheral ownership model you can go and use SPIM0 and TWIM0 at the same time with nrf-hal and things explode in fun ways
<cr1901> thalesfragoso:
<cr1901> Can you elaborate on why that makes things harder?
<cr1901> >it's a bit harder than that because the gpio shares some regs between pins
<re_irc_> <@t​halesfragoso:m​> cr1901: because the HAL does that to separate the pins, so you can use just a single pin instead of going to the regblock to use each pin
<re_irc_> <@d​irbaio:m​> embassy just defines a `TWISPI0` singleton :P
<re_irc_> <@t​halesfragoso:m​> but in stm32 land the pins share some regs
<re_irc_> <@t​halesfragoso:m​> cr1901: yep, but you can partially move fields of structs
<re_irc_> <@f​irefrommoonlight:m​> thalesfragoso: The code example I posted above shows both approaches; and I think we'd agree the pin abstraction matches better with our reasoning
<re_irc_> <@t​halesfragoso:m​> yeah, and you can have the pin type stated so it optimizes better
<cr1901> t​halesfragoso: Well, I guess that counts as a singleton as well thanks to move semantics
<cr1901> Seems like you and dirbaio are using different definitions of singleton
<re_irc_> <@t​halesfragoso:m​> sure, it's a singleton of singletons
<re_irc_> <@f​irefrommoonlight:m​> In my HAL, I have this specification explicitly listed:
<re_irc_> <@f​irefrommoonlight:m​> > Wrap PAC register blocks in structs that represent the applicable peripheral, and access features of these peripherals using public methods [1]
<re_irc_> <@f​irefrommoonlight:m​> I notably break this for GPIO
<re_irc_> <@d​irbaio:m​> it's singletons all the way down
<cr1901> The Peripherals singleton is more obvious to make because of the take() method
<re_irc_> <@t​halesfragoso:m​> cr1901: But you want to treat the things inside it separated, otherwise you could pass the gpio singleton to a driver and the uart to another one
<re_irc_> <@t​halesfragoso:m​> so, indeed the whole struct is a singleton by itself, but we usually are interested in the fields separated
<re_irc_> <@t​halesfragoso:m​> which are also singletons
<cr1901> you couldn't* pass?
<re_irc_> <@d​irbaio:m​> I wouldn't say `Peripherals` is a singleton, it's just a convenience struct that gives you all the singletons
<re_irc_> <@t​halesfragoso:m​> yeah, edited
<cr1901> Then what do you mean by this? stm32-metapac doesn't have singletons, it's up to the HALs to create the singletons
<cr1901> PACs will have singleton register blocks
<re_irc_> <@y​ruama_lairba:m​> hi again, i tried cargo size --release but it show only the flash size. I'd like to know the amount of used ram
<re_irc_> <@t​halesfragoso:m​> cr1901: metapack is weird...
<re_irc_> <@t​halesfragoso:m​> it's a whole need design, very good and very weird imo
<re_irc_> <@d​irbaio:m​> yeah we're doing it differently
<re_irc_> <@d​irbaio:m​> because the "one singleton per peripheral" is broken IMO
<re_irc_> <@d​irbaio:m​> see above for reasons
<cr1901> I'd like to add that the GPIO singleton is imported into scope from the PAC
<cr1901> So I really don't understand what is meant by "the HAL must implement the singletons"
<re_irc_> <@d​irbaio:m​> stm32-metapac is a different project
<cr1901> oooooh
<cr1901> my mistake
<re_irc_> <@d​irbaio:m​> single pac for all STM32s, with some different design decisions
<re_irc_> <@d​irbaio:m​> rationale for most differences here ->
<re_irc_> <@d​irbaio:m​> rustdoc for a different pac using chiptool here
<re_irc_> <@d​irbaio:m​> (docs for stm32-metapac aren't up yet)
<cr1901> Well, a HAL crate does not, in fact, exist for what I'm trying to do (msp430 code golf)
<cr1901> so there's no reason I can't do what metapac does or take inspiration from it
<cr1901> I just linked the stm32 crates since that's the best supported
<re_irc_> <@y​atekii:m​> Hmm how do I make an entry on the next newsletter? Normally there was an open draft PR I think but this is not the case now. Do we have a release date already and should I make a new PR or how does this go?
<re_irc_> <@a​damgreig:m​> it's same as usual, there's a draft file that you can PR
<re_irc_> <@y​atekii:m​> Ah, I thought this was already in the past since it says may, sorry :/