mchodzikiewicz[m has quit [Quit: Idle timeout reached: 172800s]
<tiwalun[m]>
<dirbaio[m]> "Ooo got the code somewhere?..." <- Yeah, I can share it later
cinemaSundays has quit [Quit: Connection closed for inactivity]
jsolano has quit [Quit: leaving]
<tiwalun[m]>
<tiwalun[m]> "Yeah, I can share it later" <- Might take some more time than expected, it's not blinking anymore 😕 It worked 3 months ago 😅
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
From the TI simplelink parts there is what they call the "Sensor Controller" but it uses some proprietary architecture.
<diondokter[m]>
If so, how do you share a flag between two cores? (While also being hardware-agnostic)
<diondokter[m]>
The problem is not initializing it, but the other reading core may race the initializing core
<JamesMunns[m]>
Ideally your init code would initialize it to a known value
<FreeKill[m]>
You can't have both cores do that
<diondokter[m]>
FreeKill[m]: Yeah that's the problem
<JamesMunns[m]>
Ideally you'd have a predictable boot sequence
<JamesMunns[m]>
Like how core1 on the rp2040 halts until started.
<diondokter[m]>
This is for embassy dual core code. So we don't really know what the user does
<JamesMunns[m]>
Failing that, putting it into an unsafe cell and using fences is likely to deter the optimizer from assuming things it shouldn't about the code
<diondokter[m]>
And STM32, so both cores start at the same time
<FreeKill[m]>
How do peripheral registers work at the end of the day? Those don't get initialised
<JamesMunns[m]>
FreeKill[m]: Those use volatile access of memory outside of the abstract machine.
<FreeKill[m]>
Isn't that kind of the same?
<diondokter[m]>
FreeKill[m]: Right now they do volatile reads and writes. But that only works by the grace of the project.
<diondokter[m]>
At some point they want to introduce separate operations for mmio memory
<diondokter[m]>
FreeKill[m]: Well this is in the abstract machine
<JamesMunns[m]>
FreeKill[m]: This is where you get into "poorly specified and frequently misunderstood bits of Rust" :)
<JamesMunns[m]>
JamesMunns[m]: And yeah, if it's a static, it's inside the abstract machine
<diondokter[m]>
So right now the dual core code has `init_primary` and `init_secondary` where the user gives both a reference to a `MaybeUninit<SharedData>`.
<diondokter[m]>
The `init_secondary` needs to wait until `init_primary` is done, so there's an atomic int in the `SharedData` that once it's set to a specific value signals that `init_primary` is done. The second core does a spinloop on the value.
<JamesMunns[m]>
You almost definitely want an unsafe cell if it can be modified outside of a single core
<FreeKill[m]>
That sounds very exciting during a soft reboot situation
<diondokter[m]>
JamesMunns[m]: Aren't atomics made for that though?
<JamesMunns[m]>
Ah, but atomics are unsafecells
<diondokter[m]>
Yeah
<JamesMunns[m]>
I mean: it's Christmas and I've had a beer or two, so my answer is that atomics and things in unsafecells are likely to work, but I don't know if reading a "potentially uninit" atomic is sound or well specified
<JamesMunns[m]>
* to work (and likely to keep working), but
<diondokter[m]>
Like, what's annoying is that nothing really can go wrong with the operations themselves except that it potentially makes the compiler do weird optimizations
<JamesMunns[m]>
But I'm also not sure if there IS an officially sound way to do this today. I want it for persistent data across soft resets. I put it in an unsafecell maybeuninit
<FreeKill[m]>
JamesMunns[m]: The persistence of data across soft reset makes me scared of the sentence "once it's set to a specific value" :D
<diondokter[m]>
Yeah, all other data is in extra UnsafeCells
<JamesMunns[m]>
FreeKill[m]: RAM only loses values when the ram is unpowered (sleep modes, full power off), it'll generally persist across soft resets.
<FreeKill[m]>
Exactly
<FreeKill[m]>
So spinning the second core waiting for a specific value is spooky, because that specific value may be there from the last time :D
<JamesMunns[m]>
So: yeah, you might want to unset the value as the second core acking the boot