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
<re_irc> <@pwf:arcticfoxes.net> hello hello, I'm trying to implement WS2812B via rp2040 PIO, and the API I wanted for it was basically a ring buffer that's continuously pumped into the state machines via DMA that I can just overwrite occasionally. I found older code in the rp-hal examples that does this, but the example now uses double buffered DMA. I guess that's the same thing, but I'll have to keep calling a method in a loop to check if it's done and...
<re_irc> ... swap the buffers?
<re_irc> <@pwf:arcticfoxes.net> ah... just saw there's an "rp-rs" room as well, I'll move over there :)
<re_irc> <@rockboynton:matrix.org> Are there any protobuf implementations that don't require an allocator, like "nanopb"? I really like the API of prost, but it requires "alloc"
<re_irc> <@rockboynton:matrix.org> I should have used the search function lol it seems that it the answer is a no...bummer. Really seems like a good option when considering my micro running Rust will interface with another micro running C (using nanopb) and I want to maintain compatibility between versions of the message schema
<re_irc> <@tomasz.fortuna:im.jakby.co> Hello. Can someone drop me a link to a well-structured rust-embedded (hal, no rtic) project? I kinda struggle at splitting my main function while preserving all Peripherals constraints and I'm probably reinventing the wheel.
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> <@vollbrecht:matrix.org> does anyone uses the new e-hal alpha crates and have issues getting them working on github ci? i cant wrap my head around why it doesn't work
<re_irc> cargo clippy --no-deps --target riscv32imc-esp-espidf -Zbuild-std=std,panic_abort -Zbuild-std-features=panic_immediate_abort -- -Dwarnings
<re_irc> Updating crates.io index
<re_irc> error: failed to select a version for the requirement `embedded-hal-nb = "=1.0.0-alpha.2"`
<re_irc> same thing works perfectly anywhere else ...
<re_irc> candidate versions found which didn't match: 0.0.0
<re_irc> <@utku:grusbv.com> Hello, I recently started getting this error after a cargo update while trying to flash a nrf52840 chip,
<re_irc> suggestion: `cargo install` a different version of `probe-run` that supports defmt 4
<re_irc> Error: defmt wire format version mismatch: firmware is using 4, `probe-run` supports 3
<re_irc> Whats the change?
<re_irc> the defmt version is set in Cargo.toml
<re_irc> defmt = { version = "0.3.0"}
<re_irc> <@diondokter:matrix.org> Apparently that's new in 0.3.4
<re_irc> <@diondokter:matrix.org> My guess is that you can update probe-run. It's had an update 8 days ago
<re_irc> <@mehmet:grusbv.com> Evidently probe run depends on a yanked version of defmt far the moment
<re_irc> <@mehmet:grusbv.com> * for
lehmrob has joined #rust-embedded
<re_irc> <@mehmet:grusbv.com> : Ah, now I get this too.
<re_irc> <@diondokter:matrix.org> Could probably be fixed for now by pinning defmt to 0.3.3
<re_irc> <@mehmet:grusbv.com> okay, let me give that a try
<re_irc> <@mehmet:grusbv.com> I think that is yanked too?
<re_irc> <@mehmet:grusbv.com> Updating crates.io index
<re_irc> error: failed to select a version for the requirement `defmt = "=0.3.3"`
<re_irc> candidate versions found which didn't match: 0.3.4, 0.3.2, 0.3.0, ...
<re_irc> <@diondokter:matrix.org> Oh, 0.3.2 then
<re_irc> <@mehmet:grusbv.com> Yep, that worked.
ni has quit [Remote host closed the connection]
ni has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
<re_irc> embedded-hal-nb = { version = "=1.0.0-alpha.2", optional = true}
<re_irc> <@dirbaio:matrix.org> I have this in "Cargo.toml"
<re_irc> but it fails
<re_irc> [dirbaio@mars stm32l5]$ cargo run --release --bin usb_serial
<re_irc> Updating crates.io index
<re_irc> error: failed to select a version for the requirement `embedded-hal-nb = "=1.0.0-alpha.2"`
<re_irc> candidate versions found which didn't match: 0.0.0
<re_irc> location searched: crates.io index
<re_irc> required by package `embassy-stm32 v0.1.0 (/home/dirbaio/embassy/embassy/embassy-stm32)`
<re_irc> ... which satisfies path dependency `embassy-stm32` (locked to 0.1.0) of package `embassy-stm32l5-examples v0.1.0 (/home/dirbaio/embassy/embassy/examples/stm32l5)`
<re_irc> perhaps a crate was updated and forgotten to be re-vendored?
<re_irc> <@dirbaio:matrix.org> but the crate is there https://crates.io/crates/embedded-hal-nb/1.0.0-alpha.2
<re_irc> <@dirbaio:matrix.org> it does find embedded-hal-hb v1.0.0-alpha.1
<re_irc> <@dirbaio:matrix.org> and "embedded-hal-hb" is the only crate with this issue, it finds fine all the others of yesterday's release
<re_irc> <@dirbaio:matrix.org> what am I doing wrong?? 🤔
<re_irc> <@vollbrecht:matrix.org> : didn't see my msg ?
<re_irc> <@dirbaio:matrix.org> no? where
<re_irc> <@vollbrecht:matrix.org> look up @chat 5 msg back
<re_irc> <@dirbaio:matrix.org> oh
<re_irc> <@dirbaio:matrix.org> we have the same issue then :D
<re_irc> <@dirbaio:matrix.org> I'm having the issue locally, not in CI. did you figure it out?
<re_irc> <@vollbrecht:matrix.org> yeah, but its only an issue on ci .. not on my local environement ....
<re_irc> <@vollbrecht:matrix.org> nope :D
<re_irc> <@dirbaio:matrix.org> O_o
<re_irc> <@dirbaio:matrix.org> what
<re_irc> <@vollbrecht:matrix.org> has to be an caching issue of some sorts
<re_irc> <@vollbrecht:matrix.org> maybe an crates.io problem
<re_irc> <@dirbaio:matrix.org> yeah, it's very odd
<re_irc> <@dirbaio:matrix.org> if it works locally for you, can you try "mv ~/.cargo ~/.cargo-bak" and see if it breaks?
<re_irc> <@vollbrecht:matrix.org> this is the timestamp from my cargo cache
<re_irc> <@vollbrecht:matrix.org> its berlin/europe time
<re_irc> <@dirbaio:matrix.org> this seems to be what Cargo downloads https://index.crates.io/em/be/embedded-hal-nb
<re_irc> "embedded-hal-nb =1.0.0-alpha.2" is missing
<re_irc> <@vollbrecht:matrix.org> is there a way to parse the .crates file for meta data? its a binary format not just a simple container ?
<re_irc> <@dirbaio:matrix.org> it's a .tar.gz
<re_irc> <@dirbaio:matrix.org> anyway, the issue is on crates.io it seems
<re_irc> <@dirbaio:matrix.org> it's using the new sparse index protocol https://blog.rust-lang.org/inside-rust/2023/01/30/cargo-sparse-protocol.html
<re_irc> <@dirbaio:matrix.org> filed an issue, as directed there: https://github.com/rust-lang/cargo/issues/11939
<re_irc> <@dirbaio:matrix.org> not sure that's the right repo, it seems to be an issue in crates.io backend, not cargo.
<re_irc> <@dirbaio:matrix.org> and indeed using the old index protocol works: "CARGO_REGISTRIES_CRATES_IO_PROTOCOL=git cargo build"
<re_irc> <@vollbrecht:matrix.org> quote "Cargo caches the crate metadata files, and captures the ETag or Last-Modified HTTP header from the server for each entry. When refreshing crate metadata, Cargo sends the If-None-Match or If-Modified-Since header to allow the server to respond with HTTP 304 “Not Modified” if the local cache is valid, saving time and bandwidth"
<re_irc> <@vollbrecht:matrix.org> Cache Invalidation
<re_irc> If a registry is using some kind of CDN or proxy which caches access to the index files, then it is recommended that registries implement some form of cache invalidation when the files are updated. If these caches are not updated, then users may not be able to access new crates until the cache is cleared.
<re_irc> <@vollbrecht:matrix.org> ah i can check my lockfire, and look if there is a difference in the registry
<re_irc> <@vollbrecht:matrix.org> * lockfile,
<re_irc> <@dirbaio:matrix.org> it's not a client-side caching issue, if you do a fresh download of https://index.crates.io/em/be/embedded-hal-nb the alpha2 isn't there
<re_irc> <@vollbrecht:matrix.org> what is your output for "curl -I --header 'If-Modified-Since: DATE-FORMAT-HERE' https://index.crates.io/em/be/embedded-hal-nb"
<re_irc> <@dirbaio:matrix.org> these headers are optional, if you don't specify them you just get the current version of the file
<re_irc> <@vollbrecht:matrix.org> but i got the correct response with this:
<re_irc> <@vollbrecht:matrix.org> last-modified timestamp checks out here
<re_irc> <@dirbaio:matrix.org> O_o
<re_irc> <@dirbaio:matrix.org> yes, but the file contents are still wrong
<re_irc> <@dirbaio:matrix.org> alpha2 isn't there
<re_irc> <@vollbrecht:matrix.org> hmm i moved the registry and run cargo build again ->
<re_irc> <@vollbrecht:matrix.org> did work what can i say :D
<re_irc> <@vollbrecht:matrix.org> can you download it with curl -I -L https://crates.io/api/v1/crates/embedded-hal-nb/1.0.0-alpha.2/download --output "file.crate" ? or without the output option you should get two responses. A 302 and a 200
<re_irc> <@vollbrecht:matrix.org> this is working for me
<re_irc> <@vollbrecht:matrix.org> the funny thing is that on ci 4 from 6 jobs worked only 2 never want to work :D
<re_irc> <@dirbaio:matrix.org> probe-run is also broken due to the defmt shenanigans... aaaargh :D
<re_irc> <@dirbaio:matrix.org> today is brokeness day
<re_irc> <@dirbaio:matrix.org> git cloned probe-run, changed it to use the updated defmt-decoder... and now it's failing with "Error: unable to determine reset handler"
<re_irc> <@dirbaio:matrix.org> wtf?
<re_irc> <@vollbrecht:matrix.org> my youtube music player also dont work duo to some wired problem in ytdl-core out of the blue 😅 networks are falling apart 💥
<re_irc> <@dirbaio:matrix.org> probe-rs-cli works
<re_irc> <@dirbaio:matrix.org> 🤷
<re_irc> <@vollbrecht:matrix.org> cargo only eveluates the "etag" and not the Last-Modified Header. For any given release is the etag stays always the same?
<re_irc> <@vollbrecht:matrix.org> * does
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc> <@yatekii:matrix.org> : we should really make sure it has feature-parity :/
<re_irc> <@dirbaio:matrix.org> +10000
<re_irc> <@dirbaio:matrix.org> yes
<re_irc> <@yatekii:matrix.org> can we get some issues open?
<re_irc> <@yatekii:matrix.org> I don't even know what's missing
<re_irc> <@dirbaio:matrix.org> backtrace on crash or control+c
<re_irc> <@dirbaio:matrix.org> stop target on control+c
<re_irc> stack usage analysis
<re_irc> backtrace on crash or control+c
<re_irc> <@diondokter:matrix.org> : I've got some time tomorrow. I could see if I could throw stackdump into the cli. But I can also imagine that you'd rather have something based on the probe-rs debugger code.
<re_irc> (Also, stackdump only works for Cortex-M so far)
<re_irc> <@dirbaio:matrix.org> yeah, the debugger already knows how to unwind
<re_irc> <@dirbaio:matrix.org> not sure how reusable it is
<re_irc> <@diondokter:matrix.org> Don't know either 😋
<re_irc> Well, my day starts in ~9 hours, so if I get confirmation that it'd be welcome before that, then I'll put in some work 🙂
<re_irc> <@dirbaio:matrix.org> I think it'd make more sense to try reusing the existing probe-rs impl, not sure
<re_irc> <@diondokter:matrix.org> Yeah makes sense, that's what I would do tbh
<re_irc> <@diondokter:matrix.org> Well, that's what I would do if I was a probe-rs maintainer I mean
<re_irc> <@diondokter:matrix.org> Actually, using the probe-rs code should be quite easy. There's an unwind function you can call: https://docs.rs/probe-rs/latest/probe_rs/debug/debug_info/struct.DebugInfo.html#method.unwind
<re_irc> <@yatekii:matrix.org> yup, should be easy :)
<re_irc> <@yatekii:matrix.org> also your code looked very advanced. maybe we can use that in the debugger as well. no need to have a probe-rs specific impl if we have a generic tool
<re_irc> <@yatekii:matrix.org> should coordinate this with maybe
<re_irc> <@diondokter:matrix.org> : I was thinking the same while looking at the probe-rs code 😅
<re_irc> <@yatekii:matrix.org> : how does stack usage analysis work?
<re_irc> <@diondokter:matrix.org> I don't really know about the feature difference between the codebases, but afaik the main difference is that the probe-rs code is more thought out in advance. It looks like the person who created it knew what he was doing before he started 😋
<re_irc> <@diondokter:matrix.org> Like, most data structures are tighter
<re_irc> <@diondokter:matrix.org> : I think it's the thing where they put in a stack canary so you can detect if something has overwritten it
<re_irc> <@yatekii:matrix.org> https://github.com/probe-rs/probe-rs/issues/1582 made an issue
<re_irc> <@yatekii:matrix.org> : not sure that is actually true XD pretty sure tiwalun just went and started and jack continued :D
<re_irc> <@yatekii:matrix.org> : hmm stack usage analysis would imply to me that it actually grabs some numbers hmm
<re_irc> <@diondokter:matrix.org> Ok, same with me then. I had barely heard of DWARF before XD
<re_irc> <@barafael:matrix.org> maybe more of a general Rust question: I have made this demo of the dining philosophers problem in embassy: https://github.com/barafael/dining-philosophers
<re_irc> its relying on macro_rules to generate the task bodies of the five philosopher tasks. However, I'm not liking this too much because I will have a tough time explaining this in a Rust-for-beginners setting, and there is no more IDE functionality in the macro_rules. Is there any other way to do this without repeating the body of the function 5 times?
<re_irc> <@jamesmunns:beeper.com> I only took a quick look, why can't it just be a function that takes those arguments instead of a macro?
<re_irc> <@barafael:matrix.org> hmm, I tried that earlier and it didn't work with "#[task]", but things changed, I'll try that agian
<re_irc> <@barafael:matrix.org> * again
<re_irc> <@jamesmunns:beeper.com> Like, 5 tasks that each call a function. I think embassy also has task syntax allowing you to create the same task multiple times?
<re_irc> <@jamesmunns:beeper.com> So you could just spawn the same task 5 times
<re_irc> <@jamesmunns:beeper.com> "pool_size = 5"
<re_irc> #[embassy_executor::task(pool_size=5)]
<re_irc> <@dirbaio:matrix.org> this should work
<re_irc> async fn philosopher(num: usize, fork1: &'static Mutex<ThreadModeRawMutex, ()>, fork2: &'static Mutex<ThreadModeRawMutex, ()>) { ... }
<re_irc> <@dirbaio:matrix.org> this should work
<re_irc> #[embassy_executor::task(pool_size=5)]
<re_irc> async fn philosopher(num: usize, fork1: &'static Mutex<ThreadModeRawMutex, ()>, fork2: &'static Mutex<ThreadModeRawMutex, ()>) { ... }
<re_irc> <@barafael:matrix.org> d'oh. Simply a function works. Now trying the pool
<re_irc> <@barafael:matrix.org> thanks y'all!
<re_irc> <@barafael:matrix.org> yeah, this is perfect