<re_irc>
<David Cabanis> Hi all! I am going through the rust-embedded tutorials (microbit-v2). I am able to compile and run the 'blinking' code but when I visualise the code in VSCode I get a lot of warnings generated by the linting tool. I was hoping that on eof you would have a solution I could use to suppress those false negatives?
<re_irc>
<dirbaio> make sure you're using rust-analyzer instead of RLS (the vscode extension named "Rust")
<re_irc>
<David Cabanis> dirbaio: Thank you for your reply. rust-analyzer is the extension I currently use.
<re_irc>
<David Cabanis> burrbull: Thanks for the lead, am I right in thinking I need to update the settings.json content inside the nrf52833_xxAA HAL? I am not too sure where I would find this file though
<re_irc>
<burrbull> Ups, I gave you wrong link. This is for other bug.
<re_irc>
<David Cabanis> burrbull: 😉
<re_irc>
<burrbull> though have you passed target?
<re_irc>
<David Cabanis> I can build and run the code if that is what you are asking. It seems to me to be related to VSCode not seeing microbit
<re_irc>
<dirbaio> David Cabanis: is the code somewhere, can you post it if not? (the whole file tree)
<re_irc>
<burrbull> next line "rust-analyzer.cargo.target"
<re_irc>
Why do you have to "use microbit" instead of "microbit_v2"??
<re_irc>
<dirbaio> * "use microbit_v2"??
<re_irc>
<dirbaio> what's causing the crate to get "renamed"??
<re_irc>
<David Cabanis> ah the instructions did not mention it
<re_irc>
<David Cabanis> microbit_V2 fixed it. Unfortunately the same code is provided for both V2 and V1. It could be that the instructions are still refering to the previous project.
<re_irc>
<dirbaio> wait so for you it works if you do "use microbit_v2::blah"?
<re_irc>
<dirbaio> but does NOT work if you do "use microbit::blah"?
<re_irc>
<David Cabanis> well at least it gets rid of all the VSCode errors
<re_irc>
<David Cabanis> false negatives
<re_irc>
<David Cabanis> ah... spoken too quickly, it doesn't build anymore. I need to look into it a bit more
<re_irc>
<David Cabanis> error[E0433]: failed to resolve: use of undeclared crate or module "microbit_V2"
<re_irc>
<James Munns> You can do that on both sides :p
<re_irc>
<dirbaio> yaeh... "package=" kinda makes sense though
<cr1901>
James Munns: Btw, bee meaning to ask: to_slice_cobs mutates in place?
<re_irc>
<dirbaio> "[lib] name = blah" is CURSED
<re_irc>
<James Munns> It's middleware
<re_irc>
<James Munns> (to cr1901)
<re_irc>
<dirbaio> its existance means you can no longer know what "use foo" does just looking at _your_ "Cargo.toml", you have to look at ALL the deps "Cargo.toml"s, wtf?
<cr1901>
I'll wait a bit before asking more qs :P
<re_irc>
<James Munns> dirbaio: I dunno, I can't justify the feature, but it's there
<re_irc>
<dirbaio> 🔥
<re_irc>
<James Munns> Probably better to not use it
<re_irc>
<James Munns> But like, eh lol
<re_irc>
<James Munns> cr1901: It mutates as a stream
<re_irc>
<James Munns> For each byte (kinda) you serialize, it does cobs one byte at a time
<re_irc>
<James Munns> Sorta like an iterator chain, but recursion
<re_irc>
<James Munns> This is how flavors work
<cr1901>
How does the function know it's being called the 2nd, 3rd, etc time on the same stream?
<re_irc>
<James Munns> A<B<C>>
<re_irc>
<James Munns> * "A<B<C<D>>>"
<cr1901>
But to_slice_cobs returns a Result<&'a mut [u8]>
<re_irc>
<James Munns> All 4 have the same "push byte" function, so A calls B calls C calls D
<re_irc>
<James Munns> They add days at each layer
<re_irc>
<James Munns> * data
* cr1901
feels like we're not talking about the same function
<re_irc>
<James Munns> cr1901: Sorry yes, it mutates the buffer you give it, and it returns the subslice used for serialization
<re_irc>
<James Munns> I misunderstood your question
<cr1901>
Anyways, let me avoid an XY problem- I have 512 bytes of RAM, I want to send arrays of maximum ~256 bytes or so? Can I do so without needing _another_ 256 bytes just for the COBS serialization w/ postcard?
<re_irc>
<James Munns> So if you give it 100 bytes, and it took 57 to serialize, it gives you back a slice to the first 57 bytes
<re_irc>
<James Munns> You'll need at least enough for Data + Serialized
<cr1901>
Hrm
<re_irc>
<James Munns> So probably 512 in your case
bjc has quit [Remote host closed the connection]
<cr1901>
Is serialization-in-place not possible? Or just not implemented?
<re_irc>
<James Munns> I don't think that's possible with serde
<cr1901>
or alternatively, serialize partially; you already have a CobsAccumulator for deserializing partially
<cr1901>
So that way I don't have to store the entire Serialized
<re_irc>
<James Munns> I could be wrong, but serde expects the source struct to exist entirely during serialization
<re_irc>
<James Munns> Cobs accumulator collects a whole type's serialized data
<cr1901>
ahhh, it doesn't deserialize until all the data's avail
<re_irc>
<James Munns> Yup
<cr1901>
Alright, I guess I'll limit msgs to 128 bytes then
<re_irc>
<James Munns> 😬
<re_irc>
<James Munns> Your scale makes me nervous lol
<re_irc>
<James Munns> Serde is super recursive
<re_irc>
<James Munns> Just don't have huge nested types sand you should be fine
<re_irc>
<James Munns> * and
<cr1901>
They aren't nested
<re_irc>
<dirbaio> if your message is 50% of your RAM you probably need something custom 🤯
<cr1901>
I've almost never run into RAM exhaustion w/ Rust on msp430. It's almost always ROM exhaustion lol
<re_irc>
<James Munns> I agree w/dirbaio. I'd even say >25%
<re_irc>
<James Munns> lol serde could do that too
<re_irc>
<dirbaio> like, serialize and COBSify it byte by byte as you send it
<re_irc>
<dirbaio> oh maybe
<re_irc>
<dirbaio> can you give serde/postcard a "writer" that immedately writes the bytes to uart?
<re_irc>
<dirbaio> just COBS needs 256 bytes of buffer though, LOL
<cr1901>
There's no point in doing this diversion if I can't used postcard. It was supposed to form the basis of the embedded HAL driver blog post I never did
<cr1901>
"Simple RPC to talk to tcn75a using msp430, because that's what I have set up :'D"
<re_irc>
<James Munns> dirbaio: I think it's possible? Serde JSON has something like this for streams
<cr1901>
Also for me to figure out "how to write an embedded application w/ a hosted component and embedded component"
<re_irc>
<James Munns> Postcard doesn't have it tho, but could be possible to add
<cr1901>
I could look into adding it, but now's not the right time. I wanted something turnkey for my constraints :(
<re_irc>
<dirbaio> :(
<cr1901>
>just COBS needs 256 bytes of buffer though, LOL <-- I think that's for decoding?
<cr1901>
If it's for encoding, I haven't worked it out in my head yet lmao
<re_irc>
<dirbaio> for encoding
<cr1901>
(Galaxy brain: If I only ever send packets of 128, then I only need 129 bytes)
<cr1901>
Honestly, I can make the packets smaller. I just wanted to make them as big as possible :P
<re_irc>
<dirbaio> ah well
<re_irc>
<dirbaio> you only need the buffer if you're doing streaming encoding
<re_irc>
<dirbaio> if you have the whole message in a slice you can just use that
<re_irc>
<dirbaio> read it once to figure out how long is the run of nonzero bytes, then read it again to send it
<re_irc>
<dirbaio> no extra buffer required
<re_irc>
<dirbaio> sorry for the confusion
<cr1901>
dirbaio: FWIW, at some point I'm genuinely interested to see if I can fit a minimal async executor into 16kb ROM/512 bytes of RAM :P
<cr1901>
I'm too much of a coward to try 2kb ROM/128 bytes RAM
<cr1901>
I think you're stuck w/ blocking or nonblocking at that point
<re_irc>
<dirbaio> can't see why it wouldn't work
<re_irc>
<dirbaio> async code size is pretty much the same as if you had written the state machine by hand
<re_irc>
<dirbaio> and you can outright ignore the waker stuff, and just do "loop { fut.poll() }"
<cr1901>
I'd like to try and embassy port, but it's probably better if I try to implement the most basic one by hand first
<cr1901>
seeing as I don't actually know how to make an async runtime yet :P