<thejpster[m]>
<ckrenslehner[m]> "Is there a crate which contains..." <- Not that I know of. It could be added to the cortex-m crate but ... how often do you not know which Cortex-M CPU you are executing on at runtime?
<JamesMunns[m]>
<thejpster[m]> "Not that I know of. It could..." <- Weird M0 + M4 dual cores where you want to share a single firmware for some reason? There's probably some chip specific register for that tho
<ckrenslehner[m]>
<JamesMunns[m]> "Weird M0 + M4 dual cores where..." <- stm32wb55 is a weirdo 😆
<dirbaio[m]>
hsem detecting the current core at runtime is a bit weird though
<dirbaio[m]>
in wb55 you simply can't run custom code in the m0, so you can assume it's the m4
<dirbaio[m]>
and for chips where you can run custom code in both cores (wl55, h7) embassy-stm32 requires the user to specify which core they're compiling for via Cargo features
<dirbaio[m]>
so you could take it from there, instead of detecting at runtime
<adamgreig[m]>
you can use cortex-m-rt and a custom linker script no problem
<adamgreig[m]>
so long as the custom script provides the same symbols the c-m-rt startup routine uses, anyway
<diondokter[m]>
<adamgreig[m]> "so long as the custom script..." <- Hmmm right, I guess. It'll always provide the `link.x` file. But in your linker settings you then wouldn't use the `"link-arg=-Tlink.x"`.
<diondokter[m]>
So that's a fair point!
<thejpster[m]>
I actually wish it was called cortex-m-rt.ld but it's probably a bit late now.
<thejpster[m]>
I have an issue with an example that is optionally including either of cortex-a-rt and cortex-r-rt and the linker scripts having the same name means its a crap shoot as to which one gets used.
<adamgreig[m]>
ugh, yea
<adamgreig[m]>
hard to change as we don't control the cargo.toml/build.rs that sets the name
<thejpster[m]>
because if you cfg out the use cortex_a_rt; the build script still runs and adds the file to the linker search path.
<adamgreig[m]>
could do it in a major bump and try to communicate it, but having two runtimes optionally included is probably niche enough
<thejpster[m]>
I think it's early enough in the cortex-r-rt / cortex-a-rt lifecycle that we'd get away with it.
<thejpster[m]>
but then they wouldn't work like cortex-m-rt does
<thejpster[m]>
(the Arm Versatile Application Board is a board with an FPGA that can be loaded with an Arm Cortex-A15 or an Arm Cortex-R5 and so the example can use either run-time - the memory map is the same either way)
<diondokter[m]>
I mean... cortex-m-rt is not 1.0 yet...
<thejpster[m]>
or at least QEMU's emulation of it lets me use either
<thejpster[m]>
there are some other breaking changes we could put into cortex-m-rt - like the one about the HardFault handler taking &mut ExceptionFrame, to allow you to modify the return address.
<thejpster[m]>
actually there are a lot of sad PRs that are basically fine but we haven't merged them for two years
<thejpster[m]>
did we solve the issue with PACs depending on cortex-m-rt, thus major bumps on c-m-rt being a massive PITA?
<dirbaio[m]>
nope
JasperHarrison[m has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
so do we want to never do a release, do a 0.8 release or go for 1.0? The fundamentals of the design are fairly sound at this point. A question for Rust Week perhaps.
<JamesMunns[m]>
At this point we semver trick 0.7 into 1.0, and semver trick 0.8 into 2.0, and move on with our lives telling everyone to switch to 2.0 :p
norineko has quit [Remote host closed the connection]