<takkaryx[m]>
I have an odd situation, I'm slowly porting an embedded project from C to Rust, (I got shot down on a whole re-write in rust) and so I'm having to use an FFI layer to translate between C and Rust, this is all mostly fine, but `arm-none-eabi-gcc` that we use for C seems to default to using SHORT_ENUM's flag, and the rust side of the code even with `repr(C) is currently unaware of that, leading to some enums having linker errors
<takkaryx[m]>
from being non-packed, nanopb proto structs.
<takkaryx[m]>
is there a way to tell the rust compiler to use short enums? or do I just need to do some careful castings?
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
That kind of feels like a bindgen issue
lulf[m] has quit [Quit: Idle timeout reached: 172800s]
<esden[cis]>
Hey, did any of you try to log defmt debug data to some bulk storage (serial logger with an sd card), if so how did you deal with the fact that the correct elf file is needed to decode it later? I am not seeing an obvious way how to encode in the debug data which version of the ELF file is needed to decode it. But I am likely missing something.
<esden[cis]>
This is especially important if the device in question can be remotely updated with a new firmware.
<esden[cis]>
Maybe I have to include some kind of a firmware version hash in the debug log output? Not exactly sure how to address this issue.
<JamesMunns[m]>
One easy way would be to grab the git sha in a build rs, and log that at boot
<JamesMunns[m]>
Then store your elf files using the Sha as wrll
<JamesMunns[m]>
s/Sha/SHA/, s/wrll/well/
<esden[cis]>
Yeah that is one way, I just wanted to make sure that there is not some elf id code that is already part of the defmt data stream.
<JamesMunns[m]>
I've been meaning to sketch out a way to use some of postcard-rpc's schema stuff with files/sequential storage as well
<JamesMunns[m]>
Like dump the schemas to disk when you boot a firmware for the first time, then tag messages with the keys.
<JamesMunns[m]>
That means you can dynamically decode them to json later on a PC after you retrieve them, without needing the elf file at all.
<JamesMunns[m]>
(if anyone is interested in that, let me know, I know exactly how I'd do it, I just haven't needed it yet 😅)
<thejpster[m]>
<esden[cis]> "Yeah that is one way, I just..." <- Not that I’m aware of
<esden[cis]>
<JamesMunns[m]> "I've been meaning to sketch..." <- That sounds interesting for sure. But I think that would be a slightly different use than the debug output? I can imagine having a local backup storage of the sensor sample data stored on the local SD card this way.
<JamesMunns[m]>
Postcard doesn't handle string interning, but serialized data is likely slightly more compact than defmt
<esden[cis]>
<thejpster[m]> "Not that I’m aware of" <- ok, then I don't seem to be missing something. It would be nice to have some generally accepted way of doing this. Maybe as an option for defmt so that it does not take up bandwidth when it is not needed? But I ran many times into the issue where I am confused about the defmt-print output because the elf file I used did not match the one on the target. (not an issue if you use probe-rs,
<esden[cis]>
where defmt output is tied to the elf file, but that is not a good solution for everyone...)
<JamesMunns[m]>
So you'd want to use enums or something similar to signal events without data, instead of interned strings.
<esden[cis]>
esden[cis]: It would be great if defmt-print would complain that the binary does not match the data stream...
<esden[cis]>
the defmt-print -w option is a huge improvement though.
<thejpster[m]>
Ok, so it’s on open source project and we’re happy to take PRs. I love people want to take defmt and use it for All The Things but it was only designed for getting logs out of a binary you just flashed.
<thejpster[m]>
One problem - you can’t assume the firmware is stored in git. And you can’t put the hash of a binary in the binary (at least, not in the hashed part). Raspberry Pi has a mechanism for tagging hashes on to binaries. Something like that might work.
<thejpster[m]>
* Ok, so it’s an open source project and we’re happy to take PRs. I love that people want to take defmt and use it for All The Things but it was only designed for getting logs out of a binary you just flashed.
<thejpster[m]>
One problem - you can’t assume the firmware is stored in git. And you can’t put the hash of a binary in the binary (at least, not in the hashed part). Raspberry Pi has a mechanism for tagging hashes on to binaries. Something like that might work.
<thejpster[m]>
You could just pick any ID you like and log the bytes first thing on start-up. The interned IDs won’t be known but you’ll see the unique byte sequence in the stream and then be able to work backwards.
<esden[cis]>
<thejpster[m]> "Ok, so it’s on open source..." <- Ok, so I guess this means PRs welcome. :) All I wanted to do is establish if I am missing something or not, and if this is a fundamentally bad idea. It sounds like this might be a useful addition. I hope I can find some cycles to look into a solution that I can contribute.
Noah[m] has joined #rust-embedded
<Noah[m]>
<JamesMunns[m]> "So you'd want to use enums or..." <- Are interned strings planned or a non feature? :) I wager postcard does not really use the ELF to convey metadata but rather a separate channel?
<diondokter[m]>
<JamesMunns[m]> "I've been meaning to sketch..." <- Oh that'd be cool! Config evolution is always hard. Might become easier with actual schema's
HelenBush[m] has left #rust-embedded [#rust-embedded]
<JamesMunns[m]>
<Noah[m]> "Are interned strings planned..." <- I don't use elf metadata at all now, it'd probably be something we'd want to add to the schema data maybe? So you'd still have the strings in the flash but only send them once with the schema info, not in every log.
<JamesMunns[m]>
This is sort of how enum variant names already work in the schema.
<JamesMunns[m]>
JamesMunns[m]: You could make an enum with variants like UnexpectedSerialErrorOccurredBecauseFraming or something lol
<JamesMunns[m]>
* You could already make an
<JamesMunns[m]>
<diondokter[m]> "Oh that'd be cool! Config..." <- Yeah, most of my schema stuff is intended for "the device doesn't actually understand what the schemas mean, but it can give it to a larger device that can use it later".
<JamesMunns[m]>
So less "schema evolution" within the device itself, it only speaks its current schema. But someone else could use it to paper over version changes.
<JamesMunns[m]>
JamesMunns[m]: You could potentially use it on device, nothing is stopping that, it'd just be more effort than it is usually worth, imo