ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
fabic has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent has quit [Killed ( (Nickname regained by services))]
emerent_ is now known as emerent
fabic has quit [Ping timeout: 252 seconds]
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
fabic has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
fabic has quit [Ping timeout: 248 seconds]
fabic has joined #rust-embedded
<re_irc> <yruama_lairba> hello, does cargo-embed support defmt ?
<re_irc> <yruama_lairba> thank you
<re_irc> <ryan-summers> Ooh I had no idea that cargo-embed had support for probe-run-like behaviors
<re_irc> <yruama_lairba> ryan-summers: what you mean ?
<re_irc> <ryan-summers> I didn't know you could configure cargo-embed to pull up the RTT terminal after flashing
<re_irc> <yruama_lairba> It isn't the default setup ?
<re_irc> <ryan-summers> You can see in that default toml linked above, rtt.enabled is set to false
<re_irc> <ryan-summers> Only flash/reset is enabled by default
<re_irc> <yruama_lairba> i always copy my "Embed.toml" when creating a new project
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
aspe has joined #rust-embedded
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
aspe has quit [Quit: aspe]
<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 ""
<re_irc> <David Cabanis> dirbaio: here is a link to the code:
<re_irc> <dirbaio> whole file tree
<re_irc> <dirbaio> the exact folder you're opening in vscode
<re_irc> <David Cabanis> oh okay,
<re_irc> <dirbaio> are you opening the dir "05-led-roulette" in vscode?
<re_irc> <dirbaio> so that "Cargo.toml" shows at the root of the tree?
<re_irc> <dirbaio> or are you opening an "upper" dir?
<re_irc> <David Cabanis> yes I am navigating to the 05-let-roulette dir and invoke code .
<re_irc> <dirbaio> ah, you're building with "--features v1"
<re_irc> <dirbaio> * v1"?
<re_irc> <dirbaio> * v2"?
<re_irc> <dirbaio> put this in ".vscode/settings.json":
<re_irc> "rust-analyzer.cargo.features": [
<re_irc> {
<re_irc> "v2"
<re_irc> <dirbaio> this way rust-analyzer will analyze your project with the same features
<re_irc> <dirbaio> or alternatively, edit "Cargo.toml":
<re_irc> - remove "optional = true" on the microbit version you're using
<re_irc> - remove "[features]" and everything below
<re_irc> - remove the dependency for the other version entirely
<re_irc> <David Cabanis> Super! thanks I'll give this a go
<re_irc> <David Cabanis> yes I build with feature v2
<re_irc> <dirbaio> btw I don't get this:
<re_irc> if you specify the dep as "microbit-v2 = { git = "" }"
<re_irc> the crate name is "microbit_v2".
<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> --> src/05-led-roulette/src/
<re_irc> |
<re_irc> 10 | use microbit_V2::hal::prelude::*;
<re_irc> <dirbaio> do "use microbit"
<re_irc> <dirbaio> that's what works
<re_irc> <dirbaio> sorry for the confusion
<re_irc> <dirbaio> I was asking "why does "use microbit" work and not "use microbit_v2"?"
<re_irc> <dirbaio> because I don't understand why
<re_irc> <David Cabanis> oh gosh I am too much of a noob to know, I am still stabbing in the dark at the moment
<re_irc> <David Cabanis> I'll revert back to microbit but I think this might anger VSCode again
<re_irc> <David Cabanis> nope its working great now
<re_irc> <David Cabanis> brilliant you fixed it now all I need to do is understand how ;-)
<re_irc> <dirbaio> has anyone ever messed with the MPU to catch stack overflows?
<re_irc> <dirbaio> I'm getting some _fun_ corruption
<re_irc> <David Cabanis> At the assembly Arm level
<re_irc> <David Cabanis> setting up a no access region
<re_irc> <dirbaio> yeah, exactly that
<re_irc> <dirbaio> I was hoping there was some crate around that I could borrow :P
<re_irc> <David Cabanis> ah I mainly do Arm assembly on Cortex-M
<re_irc> <David Cabanis> which core are you using?
<re_irc> <dirbaio> cortex-m4
<re_irc> <David Cabanis> the base address of the region must be alligned to the size
<re_irc> <David Cabanis> it's a common mistake
<re_irc> <dirbaio> James Munns: wat, I had never seen that in my life
<re_irc> <James Munns> Same trick that RTIC uses
<re_irc> <dirbaio> that's VERY confusing
<re_irc> <dirbaio> especially for a crate used in THE rust embedded tutorial...
<re_irc> <James Munns> I literally did that today to get 4 copies of postcard in one benchmark project :D
<re_irc> <James Munns> Agree it's surprising tho
<re_irc> <dirbaio> so cursed that a crate can "rename itself" like that
<re_irc> <dirbaio> what the fuck D:
<re_irc> <James Munns> Oh mnemos' kernel and userspace also does this
<re_irc> <James Munns> :p
<re_irc> <dirbaio> 👻
<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
<re_irc> <dirbaio> // Configure stack overflow protection
<re_irc> unsafe {
<re_irc> extern "C" {
<re_irc> static _stack_guard_start: u8;
<re_irc> <dirbaio> well that was easy :D
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]