ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
cinemaSundays has quit [Quit: Connection closed for inactivity]
Rahix has quit [Quit: ZNC - https://znc.in]
Rahix_ has joined #rust-embedded
azqb[m] has quit [Quit: Idle timeout reached: 172800s]
BentoMon has quit [Ping timeout: 272 seconds]
sroemer has joined #rust-embedded
BentoMon has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.4.2]
sroemer has joined #rust-embedded
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
shilga[m] has quit [Quit: Idle timeout reached: 172800s]
chomp4570[m] has quit [Quit: Idle timeout reached: 172800s]
jakzale has quit [Ping timeout: 272 seconds]
jakzale has joined #rust-embedded
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
jakzale has quit [Ping timeout: 272 seconds]
jakzale has joined #rust-embedded
BentoMon has quit [Remote host closed the connection]
BentoMon has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
Artea has quit [Ping timeout: 264 seconds]
exark has quit [Ping timeout: 248 seconds]
jakzale_ has joined #rust-embedded
m5zs7k_ has joined #rust-embedded
loki_val has joined #rust-embedded
mathu has joined #rust-embedded
exark has joined #rust-embedded
jakzale has quit [Ping timeout: 252 seconds]
m5zs7k has quit [Quit: m5zs7k]
jakzale_ is now known as jakzale
crabbedhaloablut has quit [Ping timeout: 252 seconds]
exark has joined #rust-embedded
exark has joined #rust-embedded
exark is now known as 077AAT1JQ
mathu_ has quit [Ping timeout: 276 seconds]
exark has quit [Ping timeout: 248 seconds]
jsolano has quit [Ping timeout: 276 seconds]
jsolano has joined #rust-embedded
ello has quit [Quit: ZNC 1.9.1 - https://znc.in]
ello has joined #rust-embedded
m5zs7k_ is now known as m5zs7k
Artea has joined #rust-embedded
hustor[m] has joined #rust-embedded
<Lumpio-> This is a Rust channel, not a crypto blockchain
<hustor[m]> I see
<hustor[m]> I have 6 years of experience in development of blockchain and system
<Lumpio-> On embedded platforms (組み込み系)?
<hustor[m]> ofc, Its too
Lumpio[m] has joined #rust-embedded
<Lumpio[m]> I don't think there's a lot of people running blockchain related stuff on microcontrollers, except maybe hardware wallets or whatnot
<hustor[m]> but it can be used for high-performance web application.
<hustor[m]> also, game engine
<Lumpio[m]> What can, Rust?
<hustor[m]> yeah
<Lumpio[m]> It sure can, but again, probably not a lot of people doing that on embedded platforms which is the topic of this channel
<hustor[m]> Are you a developer?
<Lumpio[m]> Yes
<hustor[m]> freelancer
<hustor[m]> ?
<Lumpio[m]> I sure am
<hustor[m]> Do you have a project?
<JamesMunns[m]> hustor this is off topic for this channel, please take this somewhere else.
<hustor[m]> okay
<JamesMunns[m]> Thank you
<hustor[m]> Lumpio[m]: @lumpp
<hustor[m]> Can I send you dm?
<Lumpio[m]> If it's about blockchains I'd rather you don't
<hustor[m]> Lumpio[m]: no, it isn't about blockchain
<Lumpio[m]> Fine, sure, go ahead, let's get this off this channel...
sroemer has quit [Ping timeout: 264 seconds]
<thejpster[m]> How indeed
<dirbaio[m]> thgere was some discussion about creating a wg-embedded ping group but I think it never happened
<dirbaio[m]> maybe `@rustbot ping wg-embedded` works tho, not sure
<thejpster[m]> Would that ping everyone?
<dirbaio[m]> I guess yeah
i509vcb[m] has joined #rust-embedded
<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.
<diondokter[m]> thejpster[m]: Yeah it's crazy. If you use the optimize-for-size flag in core you shave off a couple kb, but it's still bad
<diondokter[m]> For floats there are two formatting algos. Fast and fallback (slow). With the flag on, only the fallback algo is used
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
jasperw has quit [Ping timeout: 245 seconds]
jasperw- has joined #rust-embedded
<i509vcb[m]> 20K for a float is brutal
<JamesMunns[m]> <JamesMunns[m]> "i509vcb the new versions of..." <- By the way, I have a demo of this live now: https://github.com/jamesmunns/postcard-rpc/pull/55#issuecomment-2448163516
mabez[m] has joined #rust-embedded
<mabez[m]> <thejpster[m]> "Any last thoughts on https://..." <- You might want to consider buffer alignment, most sdmmc peripherals have some kind of alignment requirements. You could also use https://docs.rs/block-device-driver/0.2.0/block_device_driver/trait.BlockDevice.html which is what that PR does but handles alignment too
<thejpster[m]> ah, uhh, good point
<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
<mabez[m]> It works well for my use case
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]> anybody an idea why on today's nightly the following code using embedded_io_async stoped compiling? :D... (full message at <https://catircservices.org/_irc/v1/media/download/AceCoFQGg8gf9ahBr6YMBj_kGYOqKi93_PahGO8wwiXBnAMGHj83w6MGfigytETtrav2HscQjtInajIxzAsXevdCeS31-P2AAGNhdGlyY3NlcnZpY2VzLm9yZy93ZXhJalJrekFOcnFkaXV0S096cVRFa3Q>)
<dirbaio[m]> Wut. What's the compiler error?
<vollbrecht[m]> dirbaio[m]: 5 | async fn bar<R: Read>() -> Result<(), R::Error>;
<vollbrecht[m]> | ^^^^^ associated type `Error` not found
<dirbaio[m]> Hmhmhm
<dirbaio[m]> And if you import the error trait explicitly.
<vollbrecht[m]> nope
<dirbaio[m]> s/./.?/
<vollbrecht[m]> workes with yesterdays compiler
<vollbrecht[m]> s/workes/works/
<dirbaio[m]> The ErrorType trait I mean. The one that defines the Error associated type
<vollbrecht[m]> you mean the io_async::ErrorType ye? no that's not helping
<dirbaio[m]> Huh
<dirbaio[m]> Smells like rustc bug
<vollbrecht[m]> did not find an error report so far on rust-lang with it
<dirbaio[m]> Broken nameres, it's not searching in supertraits for whatever reason
<vollbrecht[m]> its at least specific to async_fn_in_traits right
<dirbaio[m]> regression probably?
<dirbaio[m]> no backlinks yet
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]> tbh with postcard-rpc, I usually make a single incoming/outgoing buffer, like 256/512/1024B, and call it a day
<JamesMunns[m]> I've not tried to absolutely minimize it thougj
<JamesMunns[m]> s/thougj/though/
<JamesMunns[m]> and honestly with all the postcard-schema stuff, you might be able to calculate it without it's own derive macro
<JamesMunns[m]> if so, I'd accept a PR for that in the postcard-schema repo.
<RockBoynton[m]> interesting, are you thinking it could be part of the derive macro for Schema?
<JamesMunns[m]> I don't think it even needs to be a macro
<JamesMunns[m]> like with recursion you could calculate the max size on the schema that already exists
<JamesMunns[m]> like you should be able to write code like this today that could work without changing the existing schema stuff:... (full message at <https://catircservices.org/_irc/v1/media/download/AZn9d8gBdTFfBSUvPlwH5mAqeb9W5Nm6pb-RczbE1b3bkWleNAip8nSXB2xb0f4lELtDnWZsg4H9limFdlKih6tCeS4BKGrAAGNhdGlyY3NlcnZpY2VzLm9yZy9ubnVSSGFyWVpuY1hvYU5sVVFIUmx6bWQ>)
<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
<JamesMunns[m]> etc