<juliand[m]>
<M9names[m]> "So... regardless of what we do..." <- Really like that idea. I always find it interesting to read what others are working on in this area. Also a great way to learn about new tools or techniques that they used or developed.
AtleoS has quit [Ping timeout: 272 seconds]
AtleoS has joined #rust-embedded
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
<M9names[m]>
sorry, llvm 18 added in RV32E codegen. I should have mentioned that part...
<SimonJohansson[m>
Is anyone aware on how to access static variables in an RTIC context? In the cortex-m-rt pre-init function I am assigning a value to a static AtomicU32 variable, but if I then try to read the value in the RTIC init function I only receive the first initialized value. I have verified that the pre-init function is running by writing some nonsense to UART that I am able to receive.
IlPalazzo-ojiisa has joined #rust-embedded
<ryan-summers[m]>
<SimonJohansson[m> "Is anyone aware on how to access..." <- My best guess is that the static is getting initialized to zero after your pre-init function executes. Have you declared it as an `Uninit()`?
<ryan-summers[m]>
Otherwise its going to get wiped in the BSS initialization process
<SimonJohansson[m>
It is not declared as an uninit. I can change the initial value, and that initial value will be carried over to RTIC. If I declare it as static mut VALUE: AtomicU32 = AtomicU32::new(3);, it is then read as the value 3 in the RTIC init function even if I set it to for example 5 in the pre-init.
<ryan-summers[m]>
Yeah, that would be entirely expected. The value is only set in memory after the _pre_init() function. That's specifically why it's called "pre-initialization". "Initialization" is the process of setting the variable to its initial value
<ryan-summers[m]>
The value of your atomic in _pre_init() is generally undefined and could be anything
<SimonJohansson[m>
Riiiiiight, makes total sense when you put it that way! How would I do to carry a value over from the pre-init function to the RTIC init function otherwise?
<ryan-summers[m]>
You would declare the variable as MaybeUninit::uninit() I believe?
<ryan-summers[m]>
And then initialize it using the MaybeUninit semantics. Although I'm not sure if you can use primitives like that in the pre-init function safely without triggering undefined behavior
<ryan-summers[m]>
The other approach would be to put the static mut variable into a custom linker section that doesn't go into .init
<ryan-summers[m]>
But generally relying on rust behaving "correctly" and in a defined manner in the pre-init function is a big ask. I don't know if it's technically valid to even have any kind of rust code in _pre_init()?
<ryan-summers[m]>
This has come up before but I don't remember exactly
<ryan-summers[m]>
Tl;dr is that essentially even writing rust code in pre_init() is likely going to be UB
<ryan-summers[m]>
What are you trying to do exactly? pre_init() may not be the right idea
<SimonJohansson[m>
The only thing I would like to do before RTIC does it's thing is reading the stack pointer and then passing that value into RTIC. The reason for this is that I am trying to measure the stack usage of RTIC, and it would be nice to get the value of the stack pointer before RTIC has had a chance to do anything.
<ryan-summers[m]>
My recommendation would be to just store it at some linker-reserved memory location and then do a raw pointer read
<ryan-summers[m]>
So write some inline asm to store the MSP at i.e. address 0x8000_0000 and then read that address from RTIC once you hit the INIT function
<ryan-summers[m]>
Or if this is a one-time thing, just drop in wiyh a debugger and manually inspect the variables at your points of interest.
<ryan-summers[m]>
s/wiyh/with/
<SimonJohansson[m>
Will try! It seems to work with MaybeUninit as well, but it would probably be better to not introduce potentially undefined behaviour
<ryan-summers[m]>
Yeah it very likely works just fine. But there's literally zero guarantees that it should
<ryan-summers[m]>
And i.e. a patched rust version or future compiler versions (or even this one on the next invocation) may not work
fooker has quit [Ping timeout: 240 seconds]
fooker has joined #rust-embedded
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
fooker has quit [Ping timeout: 268 seconds]
fooker has joined #rust-embedded
Lumpio- has quit [Quit: WeeChat 3.1-dev]
merayen has joined #rust-embedded
dj2v65fnvh[m] has quit [Quit: Idle timeout reached: 172800s]
Lumpio- has joined #rust-embedded
<sourcebox[m]>
As I mentioned yesterday, there are some synthesizers in development that use Rust. Not mentioned explicitly, but you can see something familar around 5:30 ;-)
<barnabyw[m]>
<sourcebox[m]> "As I mentioned yesterday..." <- > <@sourcebox:matrix.org> As I mentioned yesterday, there are some synthesizers in development that use Rust. Not mentioned explicitly, but you can see something familar around 5:30 ;-)
<MichaelMaitland[>
LLVM, but C itself does not have scalable vector types.
<paumanok[m]>
Quick q, what should I take into consideration if I want to make a PR to a crate to update it to Hal-1 while also supporting hal-2.x? I've seen some handle it as a feature module, but I also want to ensure whoever is using the old hal api won't have things break on them.
<paumanok[m]>
this is my first PR on a open source repo btw so I have some blindspots
<dirbaio[m]>
if it's a driver, there's no easy way to make it support both
<paumanok[m]>
dirbaio[m]: I see. My only contention is its a driver in a collection of drivers, so basically it'd be the odd one out. Maybe I'll throw the maintainer a PR and ask what they'd prefer.
diondokter[m]1 has quit [Quit: Idle timeout reached: 172800s]
xiretza[cis]1 has quit [Quit: Idle timeout reached: 172800s]
firefrommoonlig4 has quit [Quit: Idle timeout reached: 172800s]
WSalmon_ has quit [Read error: Connection reset by peer]
WSalmon has joined #rust-embedded
WSalmon has quit [Read error: Connection reset by peer]
WSalmon_ has joined #rust-embedded
khionu[m] has quit [Quit: Idle timeout reached: 172800s]