<i509vcb[m]>
James Munns: does it sound like a pain to implement a postcard-rpc for the host (for libsigrok, I do have a Rust application which is separate) in C? I guess the most annoying part is going to be that C has no proc macros...
<JamesMunns[m]>
It might be easier to FFI to Rust from C, depending on what you are doing
<i509vcb[m]>
Yeah libsigrok seems to have plenty of device specific dependencies so maybe I could get away with FFI. Although I know that Linux distro packagers love to complain when Rust suddenly becomes a dependency (even if optional)
<JamesMunns[m]>
I have some newer things I'm working on, like postcard-dyn, that might make it possible to implement encoding/decoding from C if you have a way to export the schema, like a side bin that just prints the schema out
<i509vcb[m]>
Yeah I'm not doing anything currently given you said that things are exploding currently
<JamesMunns[m]>
you can look at postcard-dyn in the main postcard repo, it takes a schema, and gives you back a serde_json::Value (and the other way around too)
<JamesMunns[m]>
so it's basically a template of "how to manually decode/encode postcard data to JSON"
<JamesMunns[m]>
Whatcha planning on doing?
<JamesMunns[m]>
i509vcb[m]: (can confirm, is exploding)
<i509vcb[m]>
Kind of think of it like a Nordic PPK2, CMSIS debugger, and low end logic analyzer in 1
<JamesMunns[m]>
Hah! I was planning on working on that next :)
<JamesMunns[m]>
i509vcb the new versions of postcard-rpc will have a built-in way to "get all schemas spoken by the device", which you can then use with postcard-dyn (or something that does the same thing) to decode messages, even if you don't know the schema ahead of time
<JamesMunns[m]>
but if your firmware is relatively fixed, it might be easier to manually write encoding/decoding tools for it, or something that does code generation. Eventually, I want to have a way to specify schemas/endpoints in a non-rust file, kind of like protobuf .proto files, which will be easier to codegen for other languages.
<i509vcb[m]>
Yeah codegen is probably the easiest option for now
<thejpster[m]>
Just in case anyone tries to tell you "But no-one is using Embedded Rust in production" again.
diondokter[m] has joined #rust-embedded
<diondokter[m]>
thejpster[m]: Anybody still saying that is clearly not looking. So many awesome things happening!
<thejpster[m]>
Oh, and did everyone catch the new Rusty Bits? He looks at RTT and defmt, and yikes, formatting a single f64 with core::fmt costs 20 KiB in .text.
<thejpster[m]>
how do you allocate a block with appropriate alignment?
<thejpster[m]>
also, should this just be in embedded-storage?
<thejpster[m]>
or should we add the non async trait to that crate?
<mabez[m]>
<thejpster[m]> "also, should this just be in..." <- Maybe, but they also don't care about alignment iirc
<mabez[m]>
but maybe we should improve embedded-storage in that regard, I recall embassy-nrf having some work around for that with its flash driver
<mabez[m]>
<thejpster[m]> "or should we add the non async..." <- I'd happily accept a blocking trait PR there
<mabez[m]>
<thejpster[m]> "how do you allocate a block with..." <- In embedded-fatfs, it's up to the caller to ensure alignment, and I have an adapter that firstly converts a block device to something that implements the embedded-io traits, but secondly will use a user provided buffer directly if the alignment and length is correct: https://docs.rs/block-device-adapters/0.2.0/block_device_adapters/struct.BufStream.html
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
<RockBoynton[m]>
James Munns: Postcard question: Why is the `MaxSize` trait currently experimental?
<JamesMunns[m]>
Because I haven't used it enough or heard enough about it to be sure it doesn't have any rough edges
<JamesMunns[m]>
the schema trait WAS used pretty extensively for the last 6mo or so, and I just pulled it out into it's own crate, I'd probably give the MaxSize trait the same treatment
<JamesMunns[m]>
It's also somewhat limited, MaxSize doesn't work for a lot of common heap allocated types, like `Vec<u8>`, and I have no idea how to solve that
<JamesMunns[m]>
I don't think there's anything wrong with what DOES work there
<JamesMunns[m]>
(and if there is, please open an issue)
<RockBoynton[m]>
JamesMunns[m]: That just means it's an error to try to derive MaxSize for a type that has that, right? Seems reasonable to me
<JamesMunns[m]>
so - the answer is, it's experimental because it isn't "1.0 quality", and today I'd probably say it should be pulled out into a non-1.0 crate so it's reasonable to iterate on it without breaking "postcard proper"
<JamesMunns[m]>
I'd definitely take a PR that does that, in the same style as postcard-schema.
<JamesMunns[m]>
that also makes it easier to take PRs to impl the trait on arbitrary other crates
<RockBoynton[m]>
I don't see a way to size your buffers at compile time, without just guessing, without it though. Of course if you have alloc, you don't need the trait anyway
<JamesMunns[m]>
basically, you can recurse on NamedType and DataModelType info from the postcard-schema crate, and calculate that by working down until you hit a primitive
<JamesMunns[m]>
every type boils down to one of the twenty-something data model types, most of which have a size, or things like seq (like Vec) would always return None
<JamesMunns[m]>
for a struct, you'd take the sum of all subfields, for an enum you'd take a varint(usize) + the max of all variants