<re_irc>
It's an STM32F0 rtic project using defmt.
<re_irc>
< (@thejpster:matrix.org)> OK, so this fixes it:
<re_irc>
< (@thejpster:matrix.org)> OK, so this fixes it:
<re_irc>
-cortex-m = { version = "0.7.5", features = ["inline-asm"] }
<re_irc>
+cortex-m = { version = "0.7.5", features = ["inline-asm", "critical-section-single-core"] }
<re_irc>
Unsure how a breaking change got picked up with a cargo update.
<re_irc>
< (@adamgreig:matrix.org)> You're using defmt-rtt 0.3 which depended on critical-section 0.2 which had a soundness issue that's been fixed in a new 0.2.8 release that internally uses critical-section 1.0 which requires an implementation such as the one you enabled with the cortex-m feature
<re_irc>
< (@adamgreig:matrix.org)> defmt-rtt 0.4 already uses c-s 1.0 so that would be the best thing to update
<re_irc>
< (@adamgreig:matrix.org)> If you scroll back to the meeting on Tuesday you can read all about it
<re_irc>
< (@jannic:matrix.org)> But even with updating defmt-rtt you'd need to provide a c-s implementation somewhere.
<re_irc>
That's basically the core of the issue: There's no good way to provide a default implementation without risking unsoundness. So the user (or some BSP crate which knows enough about the actual hardware the firmware will be deployed to) needs to select an appropriate implementation.
<re_irc>
< (@thejpster:matrix.org)> Is there anything we can do to make people aware of this? Doing a cargo update and getting linker errors is not great.
<re_irc>
< (@thejpster:matrix.org)> Like, I was in the meeting and I watched all the discussion, and I still fell right into the bear trap.
<re_irc>
< (@jannic:matrix.org)> Doing some SEO so search engine results are more useful?
<re_irc>
< (@thejpster:matrix.org)> A weak symbol that produces a better compile error? IDK.
<re_irc>
< (@thejpster:matrix.org)> I guess linker errors are better than silently building unsound code.
<re_irc>
< (@thejpster:matrix.org)> There was some talk of putting out an advisory so bots would find users of the crates and open a ticket for them.
<re_irc>
< (@adamgreig:matrix.org)> A post on our blog which we can also link to from twitter and etc would be nice too, I can try and draft something this evening
<re_irc>
< (@adamgreig:matrix.org)> Wonder what's up with that. Annoyingly updating the docs on docs.rs requires a new release...
<re_irc>
< (@thejpster:matrix.org)> MIght be flip link?
<re_irc>
< (@thejpster:matrix.org)> Or I'm using rust-lld and not GNU ld? idk.
<re_irc>
< (@thejpster:matrix.org)> Or it's the macOS version of rust-lld.
<re_irc>
< (@adamgreig:matrix.org)> rust-lld is the default but I don't know what generated those messages
<re_irc>
< (@thejpster:matrix.org)> Actually the errors were in my GHA, so that's just Linux.
<re_irc>
< (@adamgreig:matrix.org)> * the docs
<re_irc>
< (@adamgreig:matrix.org)> It does seem like the defmt-rtt 0.3 fallout zone is bigger than hoped; the other main concern was atomic-polyfill via heapless but that will only break when locking types are used which should be much rarer
<re_irc>
< (@thejpster:matrix.org)> If I was on Twitter, and you tweeted about it, I would retweet for reach.
<re_irc>
< (@thejpster:matrix.org)> I've tooted about it instead.
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
loki_val has joined #rust-embedded
<re_irc>
< (@henrikssn:matrix.org)> I have a realtime application where I'd want to rx/tx from UART with a Raspberry Pi (4). Does anyone know of an example of using the PL011 UART in blocking mode (without buffers/interrupts)?
<re_irc>
< (@henrikssn:matrix.org)> I need round trip time in the O(100us) so going through the kernel drives is a no go for me
causal has quit [Quit: WeeChat 3.7.1]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
cr1901_ is now known as cr1901
<re_irc>
< (@xgroleau:matrix.org)> What's your feeling for typestates in drivers? (sleep, fifo, onshot, etc). Just migrated with typestates since I was updating for AFIT anyway. Error handling becomes a bit of mess since you need to return the "current" state with the error. I guess there are some things which can become "too safe" it becomes unwieldy
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<stinkysink> How can i hack my phone
<re_irc>
< (@thejpster:matrix.org)> Typestates are great if you only need them within one function - like to get through some set up process. As soon as you have to persist them across function calls you have to wrap them in an enum and it gets messy.
<re_irc>
<riskable> : Trying to use your Monotonic timer crate and having an issue with the latest version (1.2.0):
<re_irc>
< (@thejpster:matrix.org)> Do a cargo tree
<re_irc>
<riskable> ("aliases::MonotonicTimer" is just an alias to "Rp2040Monotonic")
<re_irc>
< (@thejpster:matrix.org)> I suspect you have multiple versions of the same crate
<re_irc>
<riskable> : Yeah it looks like "rp2040_hal" uses "rp2040-pac v0.3.0". What do I do about this though?
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc>
<riskable> OK this is special: I have "rp2040-monotonic = "1.1"" in my "Cargo.toml" but even after "cargo clean" it's still trying to compile "rp2040-monotonic" version 1.2