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
sroemer has joined #rust-embedded
_whitelogger has joined #rust-embedded
pcs38 has joined #rust-embedded
Ralph[m] has joined #rust-embedded
<Ralph[m]> what panic handlers are y'all using? i usually use `panic-probe`, but that's just because most of my projects are test projects where i'm connected with a probe (i.e. i use a dev board with an integrated probe, e.g. an ESP32C6 or STM32). however now i'm writing a firmware for an RP Pico (RP2040) where i don't have a debugger attached and which "just has to work". i've checked the
<Ralph[m]> [panic-handler](https://crates.io/keywords/panic-handler) crates and korken89s [panic-reset](https://github.com/korken89/panic-reset) sounds nice since rebooting will always be safe for my setup (it's just reading some sensors and doesn't need to keep a state - it just reports everything via postcard-rpc). while i see that it has quite a few regular downloads it's also stuck on version 0.1 with no updates since 3+ years. is that
<Ralph[m]> because "it just works" (for cortex-m, anyway) and nobody bothered bumping it to 1.0 to indicate so or is it because you are using other things in production?
korken89[m] has joined #rust-embedded
<korken89[m]> Ralph[m]: panic-persist is nice if you want to send the panic message somewhere after reboot
<thejpster[m]> <korken89[m]> "panic-persist is nice if you..." <- I have a custom panic handler which forcibly writes to the VGA console.
<thejpster[m]> A bunch of messages above are just replies to:
<thejpster[m]> > Unable to load event that was replied to, it either does not exist or you do not have permission to view it.
<thejpster[m]> Good old element.
<thejpster[m]> maybe something to bring up with the cargo team next week, as an embedded pain-point? I suspect most people don't rely on RUSTFLAGS like we do.
<JamesMunns[m]> If you want to add it to the discussion item from last week I still plan on compiling a list
<Ralph[m]> <thejpster[m]> "I lost 30 minutes of my life..." <- might that be why some projects like `embassy-template` use `build.rs` to set the link args instead? https://github.com/lulf/embassy-template/blob/main/build.rs
<thejpster[m]> I suspect so
<thejpster[m]> <JamesMunns[m]> "If you want to add it to the..." <- added
RobinMueller[m] has joined #rust-embedded
<RobinMueller[m]> who do I need to ping for embedded-hal PRs/updates? I think a I2C clock low timeout error variant would be useful. I saw this feature in multiple I2C peripherals now: https://github.com/rust-embedded/embedded-hal/pull/666
sroemer has quit [Quit: WeeChat 4.5.2]
<jason-kairos[m]> in a no_std environment, are there any ergonomic ways to propagate multiple error types in a function result/return?
<JamesMunns[m]> thiserror can help you make wrapper enums for it
patrickh[m] has joined #rust-embedded
<JamesMunns[m]> yeah, check out thiserror
<patrickh[m]> hm, thiserror sounds smarter, need to test that
<JamesMunns[m]> tbh I do what you typed by hand like 90% of the time, but thiserror is pretty popular for doing the boilerplate, for the cost of a proc macro
<JamesMunns[m]> (the other useful part is `impl From<IoError> for CombinedError` so `?` Just Works
<JamesMunns[m]> (that's one of the thing thiserror does for you)
<patrickh[m]> there is to much stuff on the "need to check that out"-list :D
pcs38 has quit [Quit: leaving]
U007D[m] has joined #rust-embedded
<jason-kairos[m]> I speculate it should only be ~3 clock cycles per load or store below ~70MHz for most ARM cores - but not sure
<jason-kairos[m]> maybe ~30 clock cycles to modify a register
<jason-kairos[m]> * or store (instruction) below ~70MHz
<JamesMunns[m]> @U007D you could also use `cargo-show-asm` to see the assembly for that function. emulated 64-bit calls are usually a bit slow, but 115 cycles for an add seems a little excessive
<JamesMunns[m]> you could also be running into flash wait states if you are calling the function and the icache is cold.
<JamesMunns[m]> well, I guess it's not "wait states" with external flash, just "cache misses"
<U007D[m]> <jason-kairos[m]> "I speculate it should only be ~3..." <- yes, my expectations too. This core is running at 150MHz, but seeing that many clock cycles surprised me too.
<U007D[m]> <JamesMunns[m]> "@U007D you could also use `cargo..." <- Agreed.
<JamesMunns[m]> I'd check the asm, count the instructions (most are single cycle-ish when well pipelined, outside of jumps and more esoteric ones), if it seems far off, it's probably flash latency, which you can verify by running from RAM
<U007D[m]> JamesMunns[m]: Ah, XIP may be the culprit too--good thinking.
<U007D[m]> * too--good thinking. 🙏
<jason-kairos[m]> this often comes up in custom protocols and the like
pcs38 has joined #rust-embedded
<JamesMunns[m]> if they are space separated, there's a "split whitespace" method on str
<JamesMunns[m]> that can give you an iterator
<jason-kairos[m]> they aren't - contemplating parser combinator or something
<jason-kairos[m]> * they aren't unfortunately - contemplating
<JamesMunns[m]> yeah, honestly, I almost never hand-write parsers, I just use postcard/serde stuff
<JamesMunns[m]> but there's `nom` and a bunch of other parser combinators you can use, a lot of them are no-std friendly
<JamesMunns[m]> asking "how should I parse data" is like asking "whats the best kind of pizza" tho, if you ask 10 people you'll get 12 answers
jistr_ has quit [Remote host closed the connection]
jistr has joined #rust-embedded
<KevinPFleming[m]> mmm... pizza.
zeenix[m] has joined #rust-embedded
<zeenix[m]> <JamesMunns[m]> "but there's `nom` and a bunch of..." <- winnow is significantly faster than nom
<zeenix[m]> I'd recommend that these days
<jason-kairos[m]> I've never heard of it before - I suppose I should look. I was under the impression that nom was the "gold standard" - very popular for some reason
<jason-kairos[m]> what trickery does winnow use to get so fast?
<zeenix[m]> winnow is a fork of nom. I switched my crates from nom to winnow and benchmarks showed 30% performance gain
pcs38 has quit [Quit: leaving]
<dngrs[m]> nice
ivche_ has joined #rust-embedded
ivche has quit [Ping timeout: 260 seconds]
ivche_ is now known as ivche