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
ivche has quit [Read error: Connection reset by peer]
ivche has joined #rust-embedded
pcs38 has joined #rust-embedded
<Ralph[m]> i'm looking for a small, cheap MCU on a dev board (don't want to solder) which has good rust support. currently i'm using an RP pico W (the original with RP2040) in the "everything spread out on my desk... (full message at <https://catircservices.org/_irc/v1/media/download/AbF3vX037SSgkYPQKb-6ppuMMfvv0MFRcrgCQlDiVzgHehUHP52ER74AjOpcFmXGAi8AL0dUvT4_i_aXHWo7aGC_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9zZXJRSUVIUW1MQ3ZneUdqVW5idkdMdHk>)
<Ralph[m]> * i'm looking for a small, cheap MCU on a dev board (don't want to solder) which has good rust support. currently i'm using an RP pico W (the original with RP2040) in the "everything spread out on my desk... (full message at <https://catircservices.org/_irc/v1/media/download/AXuJReaWS78ndw6WIEJqMgmEB1_PLHG7E4Sgz-ET3mNxGOGusC6YeuR58U4-1h2BIAt3RCAY7z5uJwHJzxqQfoW_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9WZlVwcWdJUWNKb0NlSXpYbEVHak11d2s>)
<Ralph[m]> <JamesMunns[m]> "Published my "Embedded Rust in..." <- btw James Munns : i think your list is missing nitrokey, they have a couple of rust repos online, seems that their firmware is written in rust: https://github.com/Nitrokey
diondokter[m] has joined #rust-embedded
<diondokter[m]> The SoloKey is on there already. That and the nitrokey work together
<diondokter[m]> Sort of :P
ckrenslehner[m] has joined #rust-embedded
<ckrenslehner[m]> <Ralph[m]> "i'm looking for a small, cheap..." <- Not quite sure if you mean something like this, but I really like these: https://www.seeedstudio.com/xiao-series-page
<JamesMunns[m]> The XIAO is really nice if you only need a few pins, it's cheap and compact. It doesn't have screw holes, but there are a lot of adapter/breakout boards. Pretty often I'll make a simple breakout board with kicad+jlc and use a xiao which has all the small fiddly bits. It is soldering, but not too many pins.
<JamesMunns[m]> But there are a lot of RP2xxx, and ESP32-Cx dev boards to choose from
<Ralph[m]> <Ralph[m]> "i'm looking for a small, cheap..." <- one downside i see for the RP pico is that i can't program it with probe-rs without having a 2nd as a programmer around. of course i can just use `elf2uf2-rs`, but i also just saw that [RP2350 support hasn't been merged yet](https://github.com/JoNil/elf2uf2-rs/pull/39)
<diondokter[m]> ckrenslehner[m]: No this doesn't work. I'd advice not using workspaces at all for projects with mixed targets
<ckrenslehner[m]> JamesMunns[m]: Yeah and they are mostly pin compatible. The only tricky thing is, that the debug pins are at the bottom. So you almost need a kind of pogo pin
<RobinMueller[m]> workspace with different targets is really tricky. I have not found better solutions than to comment/uncomment the default target in .cargo/config.toml and use helper scripts like this:... (full message at <https://catircservices.org/_irc/v1/media/download/AeLJKFxjPjfhwU45liexN0Pz6ptyomfyHfSsl3ZgnNJpaggjtmr7_djuYo0ZbTkR6yZoyQ3EQbBL_AEO34Er5Em_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9EcHJ1VklFV1l6eFNnVXpSTE5XREZDWFY>)
<RobinMueller[m]> * .cargo/config.toml and/or use
<RobinMueller[m]> or not use workspaces.. but they are useful that I accept having these hacks in place 😅
<ckrenslehner[m]> Okay.. this workspace topic is really annoying. :-D
<ckrenslehner[m]> There is almost no docs which cover this. The best I found was the testing blob post series of ferrous
<RobinMueller[m]> * they are so useful that
<Ralph[m]> <ckrenslehner[m]> "Not quite sure if you mean..." <- thanks! they look nice, but i don't think that i need it _that_ tiny (i have enough space) and i'm a bit worried about the amount of GPIOs available (i don't think that i need even all of the ones available on the xiao boards, but better safe than sorry, eh?)
<Ralph[m]> but i'll definitely keep them in the back of my head for whenever i'll have a need for such tiny boards!
Kaspar[m] has joined #rust-embedded
<Kaspar[m]> diondokter[m]: In [Ariel](https://ariel-os.org), we're wrapping Cargo in [laze](https://laze-build.org). This allows us to have host tests and on-device tests next to each other. `laze` basically takes care of setting the right cargo targets et al.
mkj[m] has joined #rust-embedded
<mkj[m]> RobinMueller[m]: a `app/.cargo/config.toml` with ```[build]
<mkj[m]> target = "x86_64-unknown-linux-gnu"
<mkj[m]> ``` _might_ be adequate? I know I hit other problems with workspaces, but that's working alright for a project I'm using here atm
<mkj[m]> * a app/.cargo/config.toml with \[build\] target = "x86\_64-unknown-linux-gnu might work adequately?
<mkj[m]> * a app/.cargo/config.toml with [build] target = "x86_64-unknown-linux-gnu might work adequately?
<mkj[m]> * a app/.cargo/config.toml with [build] target = "x86_64-unknown-linux-gnu" might work adequately?
<RobinMueller[m]> mkj In this case, still want my default target to be the embedded target the workspace is targeted for. I don´t like architecture specific settings if I can avoid them.. I mean, I am only developing my embedded crates on linux, but I still try to keep everything cross-platform if I can😅
<Ralph[m]> you'll have to wait for https://github.com/rust-lang/cargo/issues/9406 in order to use different targets within one workspace. i think we're all waiting for that 😥
<JamesMunns[m]> <Ralph[m]> "one downside i see for the RP..." <- I honestly just use the `picotool` binary provided by RP themselves
<ckrenslehner[m]> Yes, but if you want a project which supports different targets depending on the feature flags this does not work either, right?
<ckrenslehner[m]> I mean e.g. a NRF feature and a RP2040 feature
<JamesMunns[m]> <Ralph[m]> "one downside i see for the RP..." <- ```toml
<JamesMunns[m]> runner = "picotool load -x -t elf"
<JamesMunns[m]> ```
<JamesMunns[m]> <Ralph[m]> "one downside i see for the RP..." <- With postcard-rpc, I just add a "reboot to bootloader" endpoint, trigger that (usually through `poststation-cli`), then cargo run
<thejpster[m]> <mkj[m]> "a `app/.cargo/config.toml` with..." <- Not on my mac :(
<thejpster[m]> I *wish* you could say `cargo test --target=native` to override a custom target set in a .cargo/config.toml file
DominicFischer[m has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]> <JamesMunns[m]> "With postcard-rpc, I just add a..." <- oh, interesting idea, i hadn't thought of that! do you have a public example of this (maybe even for an RP2040)? do you then use something like `embassy_boot` or what kind of bootloader do you mean? so far i never explicitly added a custom bootloader
joelsa[m] has joined #rust-embedded
<joelsa[m]> This is using the PICOBOOT interface, as described on p. 144ff of the RP2040 datasheet
reto[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> Yep, my templates folder generally has this endpoint: https://github.com/OneVariable/poststation-util/tree/main/templates/rp2040/src
<joelsa[m]> James, I am trying to send a quite large heapless::Vec<MyStruct, 256>; over postcard-rpc via RTT, each struct is 48 Bytes, so 12_288 bytes in total. I assume it need to fit into all buffers for this, so my BUF_RX needs to be at least this large (+header), and my RTT channel as well?
<joelsa[m]> Because for some reason the maximum length I can transmit it 200 entries, no matter the buffer sizes. So I guess I am running into another more subtle limit
<joelsa[m]> * Because for some reason the maximum length I can transmit is 200 entries, no matter the buffer sizes. So I guess I am running into another, more subtle limit
<JamesMunns[m]> There's probably some hardcoded buffer size somewhere
<JamesMunns[m]> but yeah, your buffers need to be able to store the full encoded size, including cobs encoding
<JamesMunns[m]> you're using prpcrtt right?
<JamesMunns[m]> the host size seems to also only have a 1K max buffer, that should probably be configurable
<JamesMunns[m]> THAT BEING SAID, sending a 12k chunk probably isn't the best idea, if you can avoid it
<JamesMunns[m]> are you sending the large struct TO the device @joelsa ?
<JamesMunns[m]> (I should probably update the prpcrtt to actually have `tracing` and not just silently ignore errors like "you asked me to send something bigger than possible"
<joelsa[m]> JamesMunns[m]: Yes, exactly
<joelsa[m]> The response is 6 bytes or so ;)
<JamesMunns[m]> :D
<JamesMunns[m]> Yeah, you'd need to have a fairly large rx buffer (probably 13k is enough), and probably patch the host side to make sure it also has a large enough buffer for sending
<JamesMunns[m]> (maybe it does it on the heap for encoding? I forget)
<joelsa[m]> Yeah, I did all that, even went up to 24_576 bytes for all buffers, but the 200-entry limit persists#
<JamesMunns[m]> does your device have like... 50-100k extra to spare of ram?
<JamesMunns[m]> oh maybe less than that
<JamesMunns[m]> but returning big heapless vecs is a Bad Idea, because it can use like 2-4x as much stack as you expect, maybe more in async
<joelsa[m]> JamesMunns[m]: Yep, STM32H723ZG
<joelsa[m]> 432 Kbytes of system RAM
<JamesMunns[m]> hmmmm
<JamesMunns[m]> there's nothing that would limit you that I can think of other than the buffer sizes
<JamesMunns[m]> BUF_RX is the only one that should need to be bigger I think?
<JamesMunns[m]> did you update to probe-rs 0.27?
<JamesMunns[m]> https://github.com/jamesmunns/prpcrtt/blob/main/host/Cargo.toml#L16 is still old and has the off-by-one error iirc
<JamesMunns[m]> Outside of that: I'm not sure. Adding some defmt/tracing logs on each side and letting me know where things go wrong would definitely help!
<JamesMunns[m]> Gotta run for a bit, but can check back later
<joelsa[m]> <JamesMunns[m]> "(I should probably update the..." <- I did that, added another RTT channel and did `rtt_target::set_defmt_channel(channels.up.0);`, but the issue is that of course probe-cli and the host binary cannot access the same probe at the same time, so I'd need to incorporate the tracing output to the host binary
<JamesMunns[m]> hmmmmm
<joelsa[m]> Might add that later though
<JamesMunns[m]> yeah, figuring out how to debug RTT is a fun problem, "I have no tools because I've used my tools to break all of my tools" and all that
<JamesMunns[m]> yeah, figuring out how to debug RTT is a fun problem, "I HAVE NO TOOLS BECAUSE I’VE DESTROYED MY TOOLS WITH MY TOOLS" and all that
<joelsa[m]> I mean, there is still a UART on the ST-Link that I could use for tracing, which would be 10 times easier and quicker
<joelsa[m]> But where's the fun in that?
inara` has joined #rust-embedded
inara has quit [*.net *.split]
wose has quit [*.net *.split]
wose has joined #rust-embedded
<joelsa[m]> <JamesMunns[m]> "does your device have like... 50..." <- Well, it works if I build both host and mcu code in release... So your hunch here might be right
dngrs[m] has joined #rust-embedded
<dngrs[m]> <ckrenslehner[m]> "https://github.com/ckrenslehner..."; <- [this blog post](https://ferrous-systems.com/blog/test-embedded-app/) might help; it recommends nesting two workspaces
<JamesMunns[m]> Going live in ~15m or so in case anyone wants to hear me chat with the Memfault folks about Rust :)
wassasin[m] has quit [Quit: Idle timeout reached: 172800s]
Azathoth[m] has quit [Quit: Idle timeout reached: 172800s]
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
p__q[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> ping on https://github.com/rust-embedded/cortex-ar/pull/24. More Cortex-R nonsense from me.
<thejpster[m]> also, I think I found a bug in OpenOCD. Send help.
<balbi[m]> thejpster[m]: OpenOCD's IRC channel is usually pretty helpful, but it's been many years since I worked with those guys.
thalesfragoso[m] has quit [Quit: Idle timeout reached: 172800s]
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> Going live in ~15m or so in case anyone wants to hear me chat with the Memfault folks about Rust :)
<JamesMunns[m]> edit: updated link with recording :)
<ckrenslehner[m]> <dngrs[m]> "[this blog post](https://ferrous..." <- I already checked that out thanks. :-) Unfortunately this does not help with sharing crates across the whole project.
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> @ckrenslehner I'm sure someone has said it to you before, but really I don't know any answer other than "don't" for making heterogeneous workspaces :/
<dngrs[m]> "send more funding or people in cargo's general direction so they can fix this" :/
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
kenny has quit [Quit: WeeChat 4.5.1]
kenny has joined #rust-embedded
kenny has quit [Client Quit]
kenny has joined #rust-embedded
thalesfragoso[m] has joined #rust-embedded
<thalesfragoso[m]> Hmm, I think this might be unsound:
<thalesfragoso[m]> Some other thread can pop top between the load and the deref to get next. And through the popping, it can invalidate it by writing a value to it, since it's usually an union between the next ptr and data.
<thalesfragoso[m]> Any opinions?