<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]>
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😅
<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]>
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]>
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
<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.