GenTooMan has quit [Ping timeout: 256 seconds]
GenTooMan has joined #rust-embedded
Amanieu has joined #rust-embedded
starblue has joined #rust-embedded
emerent has joined #rust-embedded
<re_irc> <@j​ohn_socha:m​atrix.org> henrik_alser: Thanks. I'll work on making it more idiomatic, which of course that means I have to learn what that looks like.
fabic has joined #rust-embedded
tokomak has joined #rust-embedded
<re_irc> <@j​ohn_socha:m​atrix.org> eldruin: Thanks. That's something I wanted to do, so having the link you provided will help me get there.
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
dcz has joined #rust-embedded
neceve has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 258 seconds]
<re_irc> <@j​duchniewicz:m​atrix.org> How welcome would be having `Backtrace` in core compared to current implementation in std? I am working on a RFC(https://github.com/rust-lang/rfcs/pull/3156) which tackles this and has a proposed implementation where you have to provide your own backtrace hook (akin to panic one) or you will be provided with...
<re_irc> ... a compiler generated one.
<re_irc> <@j​duchniewicz:m​atrix.org> The most important question is: where and how would be backtraces used in embedded contexts? So far we have discussed that they would be probably used for automated testing/bug reporting on platforms that can afford to allocate some memory for a backtrace and debug symbols. The discussion happens in this...
<re_irc> ... zulip stream: https://rust-lang.zulipchat.com/#narrow/stream/257204-project-error-handling/topic/core.3A.3AError.20and.20core.3A.3ABacktrace
fabic has joined #rust-embedded
<re_irc> <@e​ldruin:m​atrix.org> jduchniewicz: I think that discussion would benefit from having its own issue in the [WG repo](https://github.com/rust-embedded/wg) and probably also from discussion in our weekly meetings (Tuesdays 20:00h CEST)
<re_irc> <@e​ldruin:m​atrix.org> PSA: `embedded-hal` `0.2.6` is out: https://github.com/rust-embedded/embedded-hal/releases/tag/v0.2.6
<re_irc> <@d​irbaio:m​atrix.org> I imagine backtraces in core would add quite a bit of bloat if you need the whole unwinding code and symbol table with full strings
<re_irc> <@j​duchniewicz:m​atrix.org> they don't need to be symbolized at the time of capturing
<re_irc> <@j​duchniewicz:m​atrix.org> unwinding is a valid argument though
<re_irc> <@j​duchniewicz:m​atrix.org> also symbols could be stored in external memory and pulled in when needed
<re_irc> <@j​duchniewicz:m​atrix.org> citing nagisa from zulip:
<re_irc> <@j​duchniewicz:m​atrix.org> >With frame pointers enabled (which I believe is typically true on thumb) the unwinding is just chasing a pointer in a linked list. Along with storing the chain somewhere else that'd be a couple hundred bytes if written with care.
<re_irc> <@j​duchniewicz:m​atrix.org> so it seems like there is no big bloat entailed
<re_irc> <@d​irbaio:m​atrix.org> Ahh, just collect an array of PCs and ship it to the server
<re_irc> <@d​irbaio:m​atrix.org> That's quite Interesting
<re_irc> <@d​irbaio:m​atrix.org> In my project I'm shipping the top 8kb of stack 🤣
<re_irc> <@r​yan-summers:m​atrix.org> Don't know if already mentioned, but https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html is quite a nice read
<re_irc> <@d​irbaio:m​atrix.org> is there a way to get rustfmt to format all .rs files in a repo?
<re_irc> <@d​irbaio:m​atrix.org> `cargo fmt` starts in the crates's lib.rs/main.rs and discovers all other files from `mod` declarations
<re_irc> <@d​irbaio:m​atrix.org> but embassy is full of cfg's, and it doesn't have a single workspace for all crates
<re_irc> <@d​irbaio:m​atrix.org> so it's missing many files :|
<re_irc> <@d​irbaio:m​atrix.org> `find -name '*.rs' | grep -v stm32-data | xargs rustfmt --check --skip-children --unstable-features --edition 2018`
<re_irc> <@d​irbaio:m​atrix.org> this is horrible lol
<re_irc> <@j​beaurivage:m​atrix.org> Oof
<re_irc> <@j​beaurivage:m​atrix.org> If there isn't a cargo native way to do it I would just use an Invoke task
<re_irc> <@r​icharddodd:m​atrix.org> also file an issue, I think this is a common use-case
tokomak has quit [Ping timeout: 258 seconds]
dcz has quit [Ping timeout: 245 seconds]
fabic has quit [Ping timeout: 258 seconds]
<re_irc> <@d​irbaio:m​atrix.org> https://github.com/rust-lang/rustfmt/issues/2426
<re_irc> <@d​irbaio:m​atrix.org> "Rustfmt formats programs rather than files" 🤷‍♂️
<re_irc> <@r​yan-summers:m​atrix.org> I would comment on that issue with your usecase. It seems to me like the original person that closed the issue didn't really give it a lot of thought. The other alternative is to run rustfmt with all configurations
<re_irc> <@r​yan-summers:m​atrix.org> Which would likely be very un-fun
<re_irc> <@r​yan-summers:m​atrix.org> But I think rustfmt may actually not work if your code doesn't compile - it may very well _require_ that the rs files be part of the build to format them properly
<re_irc> <@d​khayes117:m​atrix.org> I use IntelliJ Idea Community with the rust plug-in to handle my reformatting. Several configurations possible and works well. https://www.jetbrains.com/help/idea/reformat-and-rearrange-code.html
fabic has joined #rust-embedded
<re_irc> <@n​ewam:m​atrix.org> ryan-summers: Oooo that is so exciting.
<re_irc> <@n​ewam:m​atrix.org> I have been dabbling with async, but the big incomplete warning on GATs turned me off of async traits.
<re_irc> <@n​ewam:m​atrix.org> I'll have to try it out again 😀
<re_irc> <@n​ewam:m​atrix.org> Are there any plans for async traits in `embedded-hal` when it can be done without nightly?
<re_irc> <@l​achlansneff:m​atrix.org> Tada! https://github.com/rust-embedded/embedded-hal/pull/285
<re_irc> <@n​ewam:m​atrix.org> That's excellent!
<re_irc> <@n​ewam:m​atrix.org> it would be nice to have an `async` RNG trait, IIRC `rand_core` has no plans for `async`.
<re_irc> <@l​achlansneff:m​atrix.org> Really, they don't?
<re_irc> <@l​achlansneff:m​atrix.org> Huh
<re_irc> <@n​ewam:m​atrix.org> Hmmm, that might be me misremembering though, I can't find any recorded conversation of that, no mention of `async` on github.
<re_irc> <@e​ldruin:m​atrix.org> haha nice turn of events. We are removing the rng traits in `e-h` 1.0 in favor of `rand_core`
<re_irc> <@n​ewam:m​atrix.org> I'll open up an issue asking what the plans are for `rand_core` with `async`.
<re_irc> <@e​ldruin:m​atrix.org> awesome, I was going to suggest that
fabic has quit [Ping timeout: 258 seconds]
neceve has quit [Ping timeout: 258 seconds]
<re_irc> <@d​irbaio:m​atrix.org> What's the use case for async rng?
<re_irc> <@d​irbaio:m​atrix.org> HW rng is not that slow
<re_irc> <@n​ewam:m​atrix.org> fair point.
<re_irc> <@n​ewam:m​atrix.org> Let me get some numbers on the STM32WL RNG.
<re_irc> <@d​irbaio:m​atrix.org> And you can also seed a csprng from the hwrng and then use that, so you wait for cpu instead of for hw
<re_irc> <@d​irbaio:m​atrix.org> Not sure which would be faster
<re_irc> <@n​ewam:m​atrix.org> is that secure enough for cryptographic use? Not an expert in that area.
<re_irc> <@d​irbaio:m​atrix.org> Yeah it's secure as long as you seed it properly
<re_irc> <@n​ewam:m​atrix.org> huh, good to know!
<re_irc> <@d​irbaio:m​atrix.org> Cs in csprng stands for Cryptograpically Secure after all 😜
<re_irc> <@n​ewam:m​atrix.org> Yeah the STM32WL RNG is pretty slow, 2662-2692 CPU cycles to generate one block of 4x u32, CPU at 48MHz, RNG at 48MHz (both max)
<re_irc> <@n​ewam:m​atrix.org> wait... not release mode, let me re-run
<re_irc> <@n​ewam:m​atrix.org> mmm same results
<re_irc> <@l​achlansneff:m​atrix.org> Is that instruction blocking?
<re_irc> <@l​achlansneff:m​atrix.org> Or rather, does it stall the cpu
<re_irc> <@n​ewam:m​atrix.org> Yup.
<re_irc> <@n​ewam:m​atrix.org> Though that is also the cold-boot numbers, it is a lot faster on the second block.
<re_irc> <@n​ewam:m​atrix.org> that's more reasonable, at steady state it goes at the advertised 412 cycles per block.
<re_irc> <@n​ewam:m​atrix.org> Still HW limited in that case though
<re_irc> <@l​achlansneff:m​atrix.org> How could it be made async in that case?
<re_irc> <@n​ewam:m​atrix.org> There's a hardware interrupt that fires when a new block of entropy is available.
<re_irc> <@n​ewam:m​atrix.org> https://github.com/rust-random/rand/issues/1155
<re_irc> <@n​ewam:m​atrix.org> Opened an issue there, hopefully I explained it well.
<re_irc> <@d​irbaio:m​atrix.org> heh, for non-embedded users it's a tough sell, RNGs are usually cpu-bound
<re_irc> <@d​irbaio:m​atrix.org> CSPRNGs are just cpu calculations, reading from /dev/urandom (or the new getrandom()) never blocks..
<re_irc> <@d​irbaio:m​atrix.org> embedded is quite unique in having a "coprocessor" that can do RNG while the core does other things
<re_irc> <@n​ewam:m​atrix.org> Speaking of that do you have any suggestions for a `#![no_std]` CSPRNG crate?
<re_irc> <@n​ewam:m​atrix.org> I am curious how many cycles it takes vs HW
<re_irc> <@n​ewam:m​atrix.org> Oh, huh, `rand` is actually `no_std` compatible.
<re_irc> <@n​ewam:m​atrix.org> I always thought it was `std`, and `rand_core` was the only `no_std` crate.
<re_irc> <@d​irbaio:m​atrix.org> for pure SW I guess https://docs.rs/chacha20/0.7.2/chacha20/struct.ChaCha20Rng.html
<re_irc> <@d​irbaio:m​atrix.org> that's the one I'm using
fabic has joined #rust-embedded
<re_irc> <@d​irbaio:m​atrix.org> There's also ChaCha8/ChaCha12, there's a [paper](https://eprint.iacr.org/2019/1492.pdf) claiming 20 rounds are overkill and 8 should be enough but I think it's somewhat debated (?)
<re_irc> <@d​irbaio:m​atrix.org> not sure if even chacha8 will beat 412cycles/block
<re_irc> <@d​irbaio:m​atrix.org> and it certainly won't win in code size :P
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <@n​ewam:m​atrix.org> CPU cycles to generate 1 block (`[u32; 4]`)
<re_irc> <@n​ewam:m​atrix.org> Cha12: 22,646
<re_irc> <@n​ewam:m​atrix.org> Cha20: 35,329
<re_irc> <@n​ewam:m​atrix.org> Cha8: 16,304
<re_irc> <@d​irbaio:m​atrix.org> oh wow, RIP
<re_irc> <@d​irbaio:m​atrix.org> HW is sooo much faster haha
<re_irc> <@n​ewam:m​atrix.org> Yeah, that's quite a bit more than I was expecting
<re_irc> <@d​irbaio:m​atrix.org> built with release, lto, flash cache/accelerators enabled?
<re_irc> <@j​orgeig:m​atrix.org> dirbaio: bare metal ftw!
<re_irc> <@n​ewam:m​atrix.org> OH, good point, my dev build doesn't have all the acceleration enabled and this is entirely CPU, one sec.
<re_irc> <@n​ewam:m​atrix.org> New numbers with all the optimizations (whoops):
<re_irc> <@n​ewam:m​atrix.org> Cha8: 1,093
<re_irc> <@n​ewam:m​atrix.org> Cha20: 2,568
<re_irc> <@n​ewam:m​atrix.org> Cha12: 1,585
<re_irc> <@d​irbaio:m​atrix.org> ahh :)
<re_irc> <@d​irbaio:m​atrix.org> when you want RNG for crypto networky shit you usually want only 32-64 bytes (so 2-4 blocks)
<re_irc> <@d​irbaio:m​atrix.org> and an async context switch probably takes more than 1000-2000 cycles
<re_irc> <@d​irbaio:m​atrix.org> so blocking is probably faster than async
<re_irc> <@n​ewam:m​atrix.org> dirbaio: I actually have not measured this yet; does async take longer than a normal RTOS?
<re_irc> <@n​ewam:m​atrix.org> I was guessing that it would be a lot faster since there is usually less to save/restore without preemption.
<re_irc> <@d​irbaio:m​atrix.org> I haven't measured anything, no
<re_irc> <@n​ewam:m​atrix.org> I guess this also depends on the executor and how feature-rich it is though. Adding task priority can eat up quite a few cycles.
<re_irc> <@d​irbaio:m​atrix.org> when awaiting the entire "call stack" returns, and has to be "called" again when polling the future again
<re_irc> <@d​irbaio:m​atrix.org> so for very deep call stacks it might be slower than rtos
<re_irc> <@d​irbaio:m​atrix.org> lke
<re_irc> <@d​irbaio:m​atrix.org> if you have a deep future stack
<re_irc> <@d​irbaio:m​atrix.org> f1, f2, ... f99
<re_irc> <@d​irbaio:m​atrix.org> when polling, f1.poll() calls f2.poll() calls f3.poll() ... calls f99.poll()
<re_irc> <@d​irbaio:m​atrix.org> and if f99 awaits something then the entire stack returns Poll::Pending and has to be called again on next poll
<re_irc> <@d​irbaio:m​atrix.org> while a stackful RTOS would "jump" directly into f99 code when resuming a thread
<re_irc> <@d​irbaio:m​atrix.org> OTOH for shallow future stacks async might be faster
<re_irc> <@d​irbaio:m​atrix.org> it'd be cool to measure
<re_irc> <@d​irbaio:m​atrix.org> and also if futures in the stack are "dumb" the compiler will probably inline them, so dunno
<re_irc> <@n​ewam:m​atrix.org> What is a good way to measure this on a Cortex-M?
<re_irc> <@n​ewam:m​atrix.org> Hmmm, now I am curious.
<re_irc> <@n​ewam:m​atrix.org> When I have done this in the past it has been with a high speed trace.
<re_irc> <@n​ewam:m​atrix.org> probably adding some code to the executor and sampling the cycle counter at a few key places?
<re_irc> <@d​irbaio:m​atrix.org> maybe
<re_irc> <@d​irbaio:m​atrix.org> or queue 2 futures, sample cycle counter at one, then yield, then at the other
<re_irc> <@d​irbaio:m​atrix.org> that'd measure the entire "end-to-end" cycles of a switch
neceve has joined #rust-embedded
<re_irc> <@n​ewam:m​atrix.org> Wow, that is a lot more cycles than I expected to switch.
<re_irc> <@n​ewam:m​atrix.org> ```rs
<re_irc> <@n​ewam:m​atrix.org> 2075 cycles for two empty tasks.
<re_irc> <@n​ewam:m​atrix.org> static mut ONE: u32 = 0;
<re_irc> <@d​irbaio:m​atrix.org> huh
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> tasks: BTreeMap<TaskId, Task>,
<re_irc> <@d​irbaio:m​atrix.org> task_queue: Arc<ArrayQueue<TaskId>>,
<re_irc> <@d​irbaio:m​atrix.org> pub struct Executor {
<re_irc> <@d​irbaio:m​atrix.org> no surprises, it uses BTreeMap and Arc
<re_irc> <@n​ewam:m​atrix.org> I did say less than optimal 😀
<re_irc> <@d​irbaio:m​atrix.org> what mcu are you testing on?
<re_irc> <@n​ewam:m​atrix.org> STM32WL5x, using the Cortex-M4 (it has a CM0+ as well) at 48MHz
<re_irc> <@e​ldruin:m​atrix.org> newam: Very interesting numbers! have you had a look at [wyrand](https://crates.io/crates/wyhash)?
<re_irc> <@d​irbaio:m​atrix.org> that's not cryptographically secure though
<re_irc> <@n​ewam:m​atrix.org> Yeah unfortunately this is for generating a nonce, so I need it to be secure
<re_irc> <@n​ewam:m​atrix.org> That looks neat though, I'll save it for later 😀
<re_irc> <@n​ewam:m​atrix.org> async context switch performance round 2
<re_irc> <@n​ewam:m​atrix.org> Please correct me if I am using this wrong, have not used embassy much.
<re_irc> <@n​ewam:m​atrix.org> ```rs
<re_irc> <@n​ewam:m​atrix.org> This time with embassy.
<re_irc> <@n​ewam:m​atrix.org> Also for good measure the non-async version (running both functions after each other) is 4 cycles.
<re_irc> <@d​irbaio:m​atrix.org> 62 only? yay :D
<re_irc> <@d​irbaio:m​atrix.org> you're using the raw task API, the highlevel one is `#[embassy::task] async fn sample1() {..` then you can spawn them with `spawner.spawn(sample1_task())`
<re_irc> <@d​irbaio:m​atrix.org> but it should be equally fast
<re_irc> <@n​ewam:m​atrix.org> dirbaio: Ran it again with the changes, 62 cycles again.
<re_irc> <@n​ewam:m​atrix.org> That's rather impressive.
<re_irc> <@d​irbaio:m​atrix.org> :D
<re_irc> <@d​irbaio:m​atrix.org> it's the best case though, cycle count will increase as you nest futures
<re_irc> <@n​ewam:m​atrix.org> Yeah, it's a good benchmark for minimum overhead though.
<re_irc> <@n​ewam:m​atrix.org> I'm glad I measured, going to stay far, far away from that BTree executor.
<re_irc> <@n​ewam:m​atrix.org> Huh, 62 cycles actually really good on the do-nothing benchmark scale.
<re_irc> <@n​ewam:m​atrix.org> FreeRTOS quotes 84 for a minimum context switch on an M3. [source](https://freertos.org/FAQMem.html#ContextSwitchTime)
<re_irc> <@n​ewam:m​atrix.org> Anecdotally Zephyr was low hundreds last time I used it (though they have been working on improving performance)
<re_irc> <@r​iskable:m​atrix.org> Is there a way to `cargo embed` without flashing first?
<re_irc> <@j​amesmunns:m​atrix.org> You mean view the rtt logs?
<re_irc> <@r​iskable:m​atrix.org> Yeah
<re_irc> <@j​amesmunns:m​atrix.org> there's a CLI tool for that, I think in the rtt-println repo
<re_irc> <@j​amesmunns:m​atrix.org> looking for it now...
<re_irc> <@j​amesmunns:m​atrix.org> `rtthost`
<re_irc> <@j​amesmunns:m​atrix.org> I can't remember where it lives...
<re_irc> <@j​amesmunns:m​atrix.org> https://github.com/probe-rs/probe-rs-rtt
<re_irc> <@j​amesmunns:m​atrix.org> `rtthost` folder
<re_irc> <@j​amesmunns:m​atrix.org> example usage:
<re_irc> <@j​amesmunns:m​atrix.org> ```bash
<re_irc> <@j​amesmunns:m​atrix.org> rtthost --chip nRF52832_xxAA --scan-region 0x20000000..0x2000FC00
<re_irc> <@j​amesmunns:m​atrix.org> though, nowadays you might be able to just make cargo embed do this without another tool :D
<re_irc> <@j​amesmunns:m​atrix.org> yatekii would know better :)
<agg> With embed you can disable flashing in embed.toml
<agg> (or make a second profile that just does rtt etc)
<re_irc> <@j​amesmunns:m​atrix.org> 🤦‍♂️
<re_irc> <@r​icharddodd:m​atrix.org> Right I'm going on holiday next week. My holiday project is to write a blog post about why Rust embedded is so awesome/how it will be even more awesome in the future/how accessible it is. Posting this here in the vain hope that it will make me feel accountable and therefore more likely to actually complete...
<re_irc> ... it.
<re_irc> <@a​lmindor:m​atrix.org> what's the process for fixing something in a PAC when the SVD is missing ? e.g. in this case the reset value is not defined in the SVD, should I add it in code, expand the svd itself?
<re_irc> <@a​lmindor:m​atrix.org> s/SVD is missing/SVD is missing the part/
<re_irc> <@n​ewam:m​atrix.org> For the STM32 SVD the `stm32-rs` repo contains a TON of patches to fix bugs in the vendor SVD, you add in in a YAML file and it gets applied when the SVD is generated.
<re_irc> <@n​ewam:m​atrix.org> Find your device in that directory and go from there. There is some shared patches for things that impact multiple devices.
<re_irc> <@f​irefrommoonlight:m​atrix.org> You need to edit the YAMLs using a donain-specific language. I'm new to it, but may be able to help if you have questions
<re_irc> <@f​irefrommoonlight:m​atrix.org> As you've found out, the SVDs are full of errors
<re_irc> <@n​ewam:m​atrix.org> firefrommoonlight: datasheets too ;)
<re_irc> <@n​ewam:m​atrix.org> for the STM32WL there is a completely undocumented block-encryption feature; but they have code for it in their HAL which sets some registers to "reserved" values.
<re_irc> <@a​lmindor:m​atrix.org> no such luxury here just the svd: https://github.com/riscv-rust/e310x
<re_irc> <@n​ewam:m​atrix.org> I would recommend starting something similar; even the good vendors are not perfect.
<re_irc> <@n​ewam:m​atrix.org> Oh, hm, that repo just commits the XML directly. Shouldn't be too bad to edit that directly then.
<re_irc> <@f​irefrommoonlight:m​atrix.org> newam: Yikes
<re_irc> <@f​irefrommoonlight:m​atrix.org> Often the reserved values are to keep parity with different MCUs, eg skipping features a given one doesn't have
neceve has quit [Ping timeout: 272 seconds]
<re_irc> <@a​lmindor:m​atrix.org> hmm is it expected that svd2rust will generate uncompilable code?
<re_irc> <@a​lmindor:m​atrix.org> I removed all the custom stuff from the update.sh in e310x so it just does the svd2rust, using latest version and it generated a reader with pub(crate) new that's unused
<re_irc> <@a​lmindor:m​atrix.org> oh wait, i had some ancient svd2rust version from pacman installed, nvm
tokomak has joined #rust-embedded