ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
Foxyloxy has joined #rust-embedded
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
agodard has quit [Ping timeout: 252 seconds]
agodard has joined #rust-embedded
agodard has joined #rust-embedded
ivche has quit [Read error: Connection reset by peer]
ivche has joined #rust-embedded
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has joined #rust-embedded
pcs38 has quit [Ping timeout: 260 seconds]
pcs38 has joined #rust-embedded
kaoD has quit [Quit: Ping timeout (120 seconds)]
kaoD has joined #rust-embedded
sroemer has quit [Ping timeout: 276 seconds]
sroemer has joined #rust-embedded
ckrenslehner[m] has joined #rust-embedded
thejpster[m] has joined #rust-embedded
<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
<dirbaio[m]> ckrenslehner: ^
<thejpster[m]> Has anyone tried ELD as a linker?
<ckrenslehner[m]> dirbaio: good idea
diondokter[m] has joined #rust-embedded
<diondokter[m]> <thejpster[m]> "Has anyone tried ELD as a linker..." <- If the linker is as slow as the web page, I don't want it :P
<diondokter[m]> It seems to be gnu compatible (so no real upgrade there) and the extended features don't really interest me...... (full message at <https://catircservices.org/_irc/v1/media/download/ATAOksmefDeQUX3v7K1aL0jI9lDJNHg8BJUpzAHCxDiYeZ-NoQefhVC5hMBn1SBcsNbfwXlFzcdzFL386_BG9Eu_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9BaU9XaFlQaU1yV3JNRnhSbGdaV1BRR20>)
<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]
norineko has joined #rust-embedded
dav1d has quit [Quit: Ping timeout (120 seconds)]
dav1d has joined #rust-embedded
pcs38 has quit [Quit: leaving]
zeenix[m] has joined #rust-embedded
<zeenix[m]> Hi, didn't we say that heapless 0.9 could be punished once https://github.com/rust-embedded/heapless/issues/529 is merged?
<zeenix[m]> We as in, I don't remember anymore who said it to me here when I asked for it several weeks ago 😊
<dirbaio[m]> punished :D
pcs38 has joined #rust-embedded
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
cinemaSundays has joined #rust-embedded
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
LachlanIkeguchi[ has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
cinemaSundays has quit [Quit: Connection closed for inactivity]
pcs38 has quit [Quit: leaving]
mathu has quit [Ping timeout: 260 seconds]
mathu has joined #rust-embedded