diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
AlexandervanSaas has quit [Quit: Idle timeout reached: 172800s]
AdamHorden has quit [Ping timeout: 244 seconds]
ilya-epifanov[m] has joined #rust-embedded
<ilya-epifanov[m]>
TIL { unsafe STATIC_MUT_VARIABLE }.some_mut_function(..) copies the STATIC_MUT_VARIABLE
<ilya-epifanov[m]>
* TIL unsafe { STATIC_MUT_VARIABLE }.some_mut_function(..) copies the STATIC_MUT_VARIABLE
<ilya-epifanov[m]>
So if you want to call a method, do `unsafe { STATIC_MUT_VARIABLE.some_mut_function(..) }` or `unsafe { &mut STATIC_MUT_VARIABLE }.some_mut_function(..)`
PedroFerreira[m] has joined #rust-embedded
<PedroFerreira[m]>
<ilya-epifanov[m]> "TIL { unsafe STATIC_MUT_VARIABL..." <- I guess that's because `.some_mut_function()` consumes self?
jxsl has joined #rust-embedded
<JamesMunns[m]>
Yeah, static mut for T: Copy types is another static mut footgun :/
<JamesMunns[m]>
It only copies if T: Copy, not for all T.
<JamesMunns[m]>
Careful with this outside of statics too: I've written unsafe FFI code that accidentally copied to the stack and then took a pointer to that
<JamesMunns[m]>
basically: be real careful with T: Copy types and any unsafe code :p
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
JomerDev[m] has quit [Quit: Idle timeout reached: 172800s]
pflanze_ has quit [Ping timeout: 252 seconds]
zeenix[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
which is entirely reasonable when you think that unsafe blocks are just blocks
<JamesMunns[m]>
yeah, it's not wrong, it's easy to misuse
<thejpster[m]>
what else was it supposed to do? Magically take a reference and transport it outside of the block? References are generated by the . operator, which is outside the block.
<thejpster[m]>
although I accept, that is non-obvious to most
<JamesMunns[m]>
this is "didn't have enough coffee and the compiler didn't complain and you didn't realize the implications" kind of stuff.
<thejpster[m]>
the real problem is &mut self methods on Copy types
<JamesMunns[m]>
tbh I feel like you should get a warning any time the compiler inserts a copy in an unsafe context
<thejpster[m]>
they should probably be fn(self) -> Self
<thejpster[m]>
then you'd get a warning for unused result
<JamesMunns[m]>
I had a static array inside of a mutex or something, accidentally made a copy onto the stack in an unsafe block, and returned a pointer to the *stack* and not the *static* in some FFI code
<JamesMunns[m]>
which caused Fun and Surprising behavior
badyjoke[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
<ilya-epifanov[m]>
It wasn't that dramatic in my case. I'm now tracing the usage of critical sections. So I thought I'd use static mut since I'm only accessing it inside a critical section. Noticed that the statistics didn't reset every second
<ilya-epifanov[m]>
One more reason to always wrap your statics in something. Even if it's just an UnsafeCell
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
AdamHorden has joined #rust-embedded
Gnome[m] has quit [Quit: Idle timeout reached: 172800s]
xnor has quit [Ping timeout: 252 seconds]
xnor has joined #rust-embedded
SbastiendHerbais has joined #rust-embedded
<SbastiendHerbais>
Hello everyone, anybody's got experience with the new STM32H7RS series and how to boot from external (OSPI) flash? I can get it to work in C using STM32CubeIDE but I'd much prefer to work on it in Rust. In case this is the wrong place to ask: sorry, I tried a few other channels to no avail :(
<SbastiendHerbais>
But tbf I don't really need any RoT shenanigans (at least not yet), just getting some LEDs blinking with some rust would be quite nice 😅
danielb[m] has joined #rust-embedded
<danielb[m]>
I know that probe-rs doesn't implement anything special for these devices. If they require anything different from the H7 line in terms of setting up debugging, then that needs to be added
<SbastiendHerbais>
Good to know!
<danielb[m]>
but embassy's teleprobe has a smaller H7S test board so not sure
<SbastiendHerbais>
I mean even w/o probe-rs, getting any rust to run would be a huge step forward, unfortunately even when flashing code that fits into the 64 KB of onboard flash doesn't seem to work and I end up getting a "Core is stuck" (paraphrasing) error in STM32 Cube Programmer after it so at this point any progress would be good
<M9names[m]>
I think the easiest path to Blinky would be to have a C program chainload your rust one
<SbastiendHerbais>
Yes I think so too, passing devices will likely be a bit of a pain, especially ethernet stuff. The main reason I wanted to use rust is to use smoltcp for networking as it is, imo, nicer to use than lwIP
<M9names[m]>
Once you've got your blinky you can start trying to work out what the C code does and replicate it.
<M9names[m]>
Probably also best to start flashing via ST's tools too, you can still use probe-rs via `attach` even if flashing doesn't work.
<M9names[m]>
Once you know it *should* work you can switch to flashing via probe-rs
<danielb[m]>
regarding RTT, two things can happen: either your .elf contains a _SEGGER_RTT symbol that locates the control block in RAM, or we scan the device's ram for a magic string
<SbastiendHerbais>
If things are running in external RAM, will it scan it too? (sorry for being a bit dense but most of this stuff is new to me)
<SbastiendHerbais>
Thanks for your time too ;)
<danielb[m]>
if you pass an .elf, we'll most likely know the address and not scan anything. otherwise, we'll scan all that we can (that is, memory that is listed in the target description as RAM)
<danielb[m]>
not sure about external RAM, worst case you'll need to copy-paste the device descriptor and add a memory region to it
<SbastiendHerbais>
Is there a way of getting an embassy 'runtime' within a staticlib without it creating a symbol called main?
<SbastiendHerbais>
It's also angry when linking about some defmt_panic stuff, I should probably go to bed now, Good night and thanks again :)
<dirbaio[m]>
they're fully separate firmwares that you compile and flash independently
<dirbaio[m]>
what 9names was saying I think is use an already-working bootloader firmware from ST written in pure C
<dirbaio[m]>
and just write your main application firmware in pure Rust
<dirbaio[m]>
then you can try porting the C bootloader to Rust later
<dirbaio[m]>
you don't need a hybrid project linking C and Rust together
<dirbaio[m]>
hybrid C+Rust is quite complicated and a source of abundant pain, I'd recommend staying away from it.
<dirbaio[m]>
s/./ unless you really need it/
<SbastiendHerbais>
Hey dirbaio That does indeed sound like I am over complicating things. I do have an existing bootloader that ST provides so that is taken care of, my main problem is that I have no idea how to use it, I understand that I can just set my `memory.x` to have the addresses be the memory-mapped flash & RAM, but how do I program my rust-based firmware into it? In C they use these st loader files which is fine, but do I need to
<SbastiendHerbais>
re-flash my bootloader every time? (I would hope not). And then how do I get things like `probe-rs` to run. I have tried using the ST bootloader with probe-rs and it complains that there's no memory (that it knows of) at address 0x7000... But I don't know how to "tell it" that there is, in fact, memory there
<dirbaio[m]>
> And then how do I get things like probe-rs to run. I have tried using the ST bootloader with probe-rs and it complains that there's no memory (that it knows of) at address 0x7000... But I don't know how to "tell it" that there is, in fact, memory there
<dirbaio[m]>
then the chip definition contains the list of memory regions and the list of flash algos to use
<SbastiendHerbais>
Ah right!, there's chip and then how do I select the flash algorithm? Sorry if these questions are a bit simple, it's the first time I am doing something that doesn't entirely fit within the internal Flash
<dirbaio[m]>
<dirbaio[m]> "then it looks for a flash algo..." <- this
<SbastiendHerbais>
Ah okay, so if it refuses then I'm likely doing something wrong
<adamhott[m]>
I've been playing with TLS all weekend haha
<danielb[m]>
dirbaio[m]: there's a PR pending that should make flash algos work even if there is no memory region defined. it's intended for option bytes but should work here as well