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_>
<@willeml:matrix.org> 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: https://github.com/willemml/rustworks/blob/master/src/external_flash.rs but I cannot figure out what I need to do in order to port...
<re_irc_>
<@willeml:matrix.org> Any help and or other tips on QSPI flash storage on stm32 would be much appreciated
<re_irc_>
<@willeml:matrix.org> 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_>
<@dirbaio:matrix.org> StatusRegister1 seems to be a 8bit register where bit 0 indicates "busy"
<re_irc_>
<@firefrommoonlight:matrix.org> 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_>
<@dirbaio:matrix.org> that's a register of the flash chip, not of the qspi peripheral
<re_irc_>
<@dirbaio:matrix.org> you'll find it documented in the flash chip's datasheet
<re_irc_>
<@willeml:matrix.org> firefrommoonlight: Based on what I have ported so far, that sounds right
<re_irc_>
<@dirbaio:matrix.org> 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_>
<@dirbaio:matrix.org> 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_>
<@willeml:matrix.org> Oh, so that register class is just a wrapper to read from the chip?
<re_irc_>
<@dirbaio:matrix.org> it's doing QSPI things to read 1 byte, putting the byte instide the StatusRegister1, then use `.getBUSY()` to read bit 0
<re_irc_>
<@dirbaio:matrix.org> in an exceptionally ugly way with these `reinterpret_casts` 🤣
<re_irc_>
<@willeml:matrix.org> Yeah, it took me a while to figure out what those were, as I have no embedded C++ experience beyond blinky arduino
<re_irc_>
<@dirbaio:matrix.org> embedded C++ is horrible 🤣
<re_irc_>
<@willeml:matrix.org> Yeah, I noticed lol, especially when you compare it to the wonderful rust embedded ecosystem
<re_irc_>
<@willeml:matrix.org> 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_>
<@dirbaio:matrix.org> looks OK to me!
<re_irc_>
<@dirbaio:matrix.org> it's normal to have lots of unsafe when using the PAC directly due to how the PAC API is generated...
<re_irc_>
<@willeml:matrix.org> 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_>
<@willeml:matrix.org> 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_>
<@willeml:matrix.org> basically `[0u32; 100]` except that `100` would be a runtime variable
<re_irc_>
<@dirbaio:matrix.org> for these usually having the caller pass you the buffer works
<re_irc_>
<@dirbaio:matrix.org> instead of `read(..., len: usize) -> Vec<u8>`, do `read(..., buf: &mut [u8])`
<re_irc_>
<@dirbaio:matrix.org> that reads `buf.len()` bytes into buf
<re_irc_>
<@dirbaio:matrix.org> hopefully the caller knows the size and can stack-allocate it
<re_irc_>
<@dirbaio:matrix.org> and if not they can still use Vec, but now the decision is on them, you're not forcing it
<re_irc_>
<@willeml:matrix.org> well apparently qspi.sr is always busy
<re_irc_>
<@willeml:matrix.org> Any idea on how to make probe-run not die when lots of stuff gets printed very fast?
<re_irc_>
<@huntc:matrix.org> 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_>
<@willeml:matrix.org> Hmm, I am just using `rtt-target`
<re_irc_>
<@huntc:matrix.org> 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_>
<@willeml:matrix.org> Yes
<re_irc_>
<@huntc:matrix.org> Perhaps flash your firmware via some other means and use the `JLinkRTTViewer.app` - just to isolate your issue.
<re_irc_>
<@willeml:matrix.org> Where would I find that app, and is there an STLink version?
<re_irc_>
<@huntc:matrix.org> Ah - I had assumed JLink. Apologies.
<re_irc_>
<@willeml:matrix.org> No worries
<re_irc_>
<@huntc:matrix.org> Perhaps ask in the probe-rs room. You can set up probe-rs to output debug, which may help diagnose the issue.
<re_irc_>
<@willeml:matrix.org> 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]
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_>
<@lachlansneff:matrix.org> 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_>
<@lachlansneff:matrix.org> When flashing an nrf9160
<re_irc_>
<@dirbaio:matrix.org> sadly the weird macro resolution means it can't be a separate lib crate, you have to copypaste it into every crate
<re_irc_>
<@jamesmunns:matrix.org> Ah, you'd need something like `$crate::feature` or something?
<re_irc_>
<@dirbaio:matrix.org> defmt proc macros break if you try to reexport them
<re_irc_>
<@jamesmunns:matrix.org> oh
<re_irc_>
<@lachlansneff:matrix.org> jamesmunns: I think log doesn't have `std` by default.
<re_irc_>
<@jamesmunns:matrix.org> If we put that shim in `defmt` itself would that work better?
<re_irc_>
<@dirbaio:matrix.org> because they emit code that does `defmt::blah`, and `defmt` is not defined in the user crate's scope
<re_irc_>
<@jamesmunns:matrix.org> like, just change the defmt macros themselves to be able to swap over to log as a general backend?
<re_irc_>
<@jamesmunns:matrix.org> and maybe even handle the syntax diffs in the defmt proc macros?
<re_irc_>
<@jamesmunns:matrix.org> not sure if you can mess with the strings tho
<re_irc_>
<@dirbaio:matrix.org> very tricky
<re_irc_>
<@jamesmunns:matrix.org> (syntax diff I mean the `{u8:}` Format stuff)
<re_irc_>
<@dirbaio:matrix.org> for example, printing something with `{:?}` requires `defmt::Format` or `core::fmt::Debug` impl depending on what's enabled
<re_irc_>
<@jamesmunns:matrix.org> whew
<re_irc_>
<@dirbaio:matrix.org> it gets ugly fast
<re_irc_>
<@jamesmunns:matrix.org> makes sense
<re_irc_>
<@dirbaio:matrix.org> also another advantage of having it in-crate is
<re_irc_>
<@dirbaio:matrix.org> if you do `macro_rules! panic {..}`, that'll override `panic!` in the entire crate
<re_irc_>
<@dirbaio:matrix.org> so you don't miss panic messages because in one file you forgot to `use defmt::panic`
<re_irc_>
<@jamesmunns:matrix.org> 👍️
<re_irc_>
<@dirbaio:matrix.org> so you plop fmt.rs in your crate, do `mod fmt` FIRST in lib.rs (did you know mod order matters for in-crate macro resolution? it sucks)
<re_irc_>
<@dirbaio:matrix.org> and it Just Works
<re_irc_>
<@jamesmunns:matrix.org> dirbaio: Yeah, MBEs are one (maybe THE only?) thing where order matters.
<re_irc_>
<@dirbaio:matrix.org> what I hate is order matters for in-crate macros but not for macros imported from other crates (declarative or proc)
<re_irc_>
<@dirbaio:matrix.org> it's like
<re_irc_>
<@dirbaio:matrix.org> WTF
<re_irc_>
<@dirbaio:matrix.org> WHY
<re_irc_>
<@jamesmunns:matrix.org> I mean, order even matters within a single file
<re_irc_>
<@jamesmunns:matrix.org> like, you can't use a macro before you declare it
<re_irc_>
<@jamesmunns:matrix.org> it's like we're in C or something
<re_irc_>
<@dirbaio:matrix.org> but you can call an out-of-crate macro before you `use` it
<re_irc_>
<@dirbaio:matrix.org> out-of-crate macros work mostly like normal items
<re_irc_>
<@dirbaio:matrix.org> but not in-crate >_<
<re_irc_>
<@lachlansneff:matrix.org> It turned out that the `log` dependency was being unified with `log` from build-dependencies
<re_irc_>
<@lachlansneff:matrix.org> Had to turn on resolver 2
<re_irc_>
<@jamesmunns:matrix.org> ahhh
<re_irc_>
<@jamesmunns:matrix.org> yeah, that'll do it
<re_irc_>
<@lachlansneff:matrix.org> :/
tokomak has quit [Read error: Connection reset by peer]
<re_irc_>
<@yatekii:matrix.org> has anyone ever experienced that zola syntax highlighting does not work?
<re_irc_>
<@firefrommoonlight:matrix.org> 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_>
<@firefrommoonlight:matrix.org> Since it should act more like the built in Flash peripheral interaction for STM32
<re_irc_>
<@firefrommoonlight:matrix.org> (I'm working on a QSPI module now)
<re_irc_>
<@firefrommoonlight:matrix.org> 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_>
<@dirbaio:matrix.org> all `regs()` has to return the same PAC type yeah
<re_irc_>
<@dirbaio:matrix.org> if they don't, you have to cast raw pointers
<re_irc_>
<@firefrommoonlight:matrix.org> dirbaio: When would you do this, for example?
<re_irc_>
<@dirbaio:matrix.org> that Uart struct is one example
<re_irc_>
<@firefrommoonlight:matrix.org> 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_>
<@dirbaio:matrix.org> in embassy drivers can own or borrow the regblock
<re_irc_>
<@dirbaio:matrix.org> so Uart has a lifetime
<re_irc_>
<@dirbaio:matrix.org> it's `'static` if it owns, and non-static if it borrows
<re_irc_>
<@firefrommoonlight:matrix.org> It looks like this quote from the Rust docs is relevant here:
<re_irc_>
<@firefrommoonlight:matrix.org> 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_>
<@firefrommoonlight:matrix.org> 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_>
<@dirbaio:matrix.org> but when borrowing you don't want to physically store a pointer to the borrowed UART2, it has no useful info
<re_irc_>
<@dirbaio:matrix.org> so with PhantomData you save 4 bytes of RAM
<re_irc_>
<@dirbaio:matrix.org> you don't want the pointer, but you do want the generic lifetime so the borrow checker will check stuff for you
<re_irc_>
<@firefrommoonlight:matrix.org> Is that to handle buses, with generic drivers that expect ownership over the bus struct?
<re_irc_>
<@thalesfragoso:matrix.org> it's just a design, and gets rid of weird free methods
<re_irc_>
<@thalesfragoso:matrix.org> if you want to re-use, use the driver borrowing, otherwise pass the owned struct
<re_irc_>
<@firefrommoonlight:matrix.org> This is starting to make sense, in regards to generic APIs, expectations of generic drivers etc... ie what thalesfragoso opened with
<re_irc_>
<@firefrommoonlight:matrix.org> 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_>
<@firefrommoonlight:matrix.org> 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_>
<@firefrommoonlight:matrix.org> Of note, you also need the pointer access of GPIO if you want a `Pin` abstraction, which is IMO useful
<re_irc_>
<@dirbaio:matrix.org> this is because the PACs insist on having per-peripheral ownership
<re_irc_>
<@dirbaio:matrix.org> which in some cases, like GPIO, is wrong
<re_irc_>
<@firefrommoonlight:matrix.org> Otherwise your set APIs would look something like this:
<re_irc_>
<@thalesfragoso:matrix.org> 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_>
<@dirbaio:matrix.org> stm32-metapac doesn't have singletons, it's up to the HALs to create the singletons
<re_irc_>
<@dirbaio:matrix.org> so it can create a GPIOA singleton or one per pin like PA0, PA1, PA2..
<re_irc_>
<@firefrommoonlight:matrix.org> 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_>
<@dirbaio:matrix.org> there's more cases of the PAC ownership model being wrong
<re_irc_>
<@dirbaio:matrix.org> 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_>
<@thalesfragoso:matrix.org> 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_>
<@dirbaio:matrix.org> embassy just defines a `TWISPI0` singleton :P
<re_irc_>
<@thalesfragoso:matrix.org> but in stm32 land the pins share some regs
<re_irc_>
<@thalesfragoso:matrix.org> cr1901: yep, but you can partially move fields of structs
<re_irc_>
<@firefrommoonlight:matrix.org> 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_>
<@thalesfragoso:matrix.org> yeah, and you can have the pin type stated so it optimizes better
<cr1901>
thalesfragoso: 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_>
<@thalesfragoso:matrix.org> sure, it's a singleton of singletons
<re_irc_>
<@firefrommoonlight:matrix.org> In my HAL, I have this specification explicitly listed:
<re_irc_>
<@firefrommoonlight:matrix.org> > Wrap PAC register blocks in structs that represent the applicable peripheral, and access features of these peripherals using public methods [1]
<re_irc_>
<@firefrommoonlight:matrix.org> I notably break this for GPIO
<re_irc_>
<@dirbaio:matrix.org> it's singletons all the way down
<cr1901>
The Peripherals singleton is more obvious to make because of the take() method
<re_irc_>
<@thalesfragoso:matrix.org> 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_>
<@thalesfragoso:matrix.org> so, indeed the whole struct is a singleton by itself, but we usually are interested in the fields separated
<re_irc_>
<@thalesfragoso:matrix.org> which are also singletons
<cr1901>
you couldn't* pass?
<re_irc_>
<@dirbaio:matrix.org> I wouldn't say `Peripherals` is a singleton, it's just a convenience struct that gives you all the singletons
<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_>
<@yruama_lairba:matrix.org> 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_>
<@thalesfragoso:matrix.org> cr1901: metapack is weird...
<re_irc_>
<@thalesfragoso:matrix.org> it's a whole need design, very good and very weird imo
<re_irc_>
<@dirbaio:matrix.org> yeah we're doing it differently
<re_irc_>
<@dirbaio:matrix.org> because the "one singleton per peripheral" is broken IMO
<re_irc_>
<@dirbaio:matrix.org> see above for reasons
<re_irc_>
<@dirbaio:matrix.org> (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_>
<@yatekii:matrix.org> 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?