<cr1901>
I really hope that cat had its paws cleaned. And not using its tongue :(
<pmnxis[m]>
absolutely i did
<pmnxis[m]>
s/did/cleaned her paws ASAP./
<cr1901>
good :D
<cr1901>
plz 2 give cat pets and treats for me
vrakaslabs[m] has joined #rust-embedded
<vrakaslabs[m]>
descriptors.
<vrakaslabs[m]>
<vrakaslabs[m]> "Thanks for the help, I’ll take a..." <- dirbaio: Is there any contract on the lifetime of these tokens? Can I safely assume that tokens will be consumed immediately after being created, and will not be stockpiled? It appears the STM32 implementation doesn't actually allocate a descriptor when a token is created, so it would be possible to stockpile tokens, and them consume them all at once, and you'd run out of
<vrakaslabs[m]>
- Second prong of this question: If I create a TxToken to accompany every RxToken, and most are never used, what's the intended approach to "free" the unused tokens, and their associated descriptors?
<vrakaslabs[m]>
I was under the impression the Token-style interface existed to allow the network stack to "claim" a spot in the descriptor list, but I might not be understanding it fully.
crabbedhaloablut has joined #rust-embedded
<marmrt[m]>
Is there a good reference for an embedded application using smoltcp 0.10? I'm updating code from 0.8 and I can for the life of me not figure out what I have to do to satisfy SocketSet::new()
<marmrt[m]>
Nevermind, I think I'll stick with 0.8 for now.
<ryan-summers[m]>
Would also highly recommend 0.10.0 - lots of good stuff and fixes for TCP and DNS support etc. But only if you need it. If 0.8 is working fine, there's no strong reason for the thrash
<ryan-summers[m]>
The basic concept is to store all the socket buffer in static memory
<ryan-summers[m]>
<vrakaslabs[m]> "dirbaio: Is there any contract..." <- The lifetimes explicitly dictate that only a single rx/tx token will exist at a time
<ryan-summers[m]>
ryan-summers[m]: i.e. the compiler guarantees that only a single token can live at once from what I recall
fooker has quit [Quit: WeeChat 3.8]
fooker has joined #rust-embedded
nex8192 has left #rust-embedded [Error from remote client]
nex8192 has joined #rust-embedded
<vrakaslabs[m]>
<ryan-summers[m]> "i.e. the compiler guarantees..." <- Ah, that makes life much easier 👍
nex8192 has left #rust-embedded [Error from remote client]
nex8192 has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<corecode[m]>
for storing settings in flash (maybe via some eeprom emulation layer), would you suggest using serde/postcard or something else? I was thinking of just storing the binary data (requiring a Copy type)
<diondokter[m]>
corecode[m]: I've written a crate for just this purpose: https://crates.io/crates/sequential-storage Its `map` is a key-value store in flash that's good for small configs that you want to regularly update. It's serialization format neutral. You could store the binary data or the result of e.g. postcard.
<diondokter[m]>
For storing structs as binary, you really need to watch out for proper alignment of your data. Also, you'd probably want to make it repr C so the struct layout is fixed across compiler versions (but you'll have to give up on some nice things like enums and such)
<firefrommoonligh>
I think that's doing double-duty as USB format
<firefrommoonligh>
* as USB/PC-interface format
<firefrommoonligh>
packed_struct is another option
<firefrommoonligh>
I'm not entirely happy with this approach, as it adds inertia to changing the format, but in weighing the pros and cons, it's what I do for small configs
<firefrommoonligh>
Probably should be paired with something MCU-specific too to cycle the actcive pages
<corecode[m]>
i'd expect a simple crate that uses serde to just dump out the bytes, is that what postcard does?
<corecode[m]>
something that doesn't try platform independence
<corecode[m]>
i just need to dump and read data; and i guess also test for invalid enums
<diondokter[m]>
firefrommoonligh: Yeah, we have some counters that we need to update every time our device wakes up. And nordic flash can only be erased 10k times, so yeah...
<firefrommoonligh>
corecode[m]: Btw, I didn't post it explicitly, but I'm a fan of u8-repr Enums for config types
<firefrommoonligh>
(Or really anything that is serialized to/from byte arrays)
<corecode[m]>
i guess packed_struct is pretty simple too
<corecode[m]>
firefrommoonlight: is there a way to check whether a type is trivially serializable to a byte array and has a stable binary representation?
<firefrommoonligh>
Great question; regrettably I don't have an answer
<firefrommoonligh>
But could probalby answer for a specific data type
<diondokter[m]>
I don't think there's a way to check that at either runtime or compile time
<corecode[m]>
yea i doubt it
<corecode[m]>
the other question is, how to deal with bit errors. i guess i could just rely on the storage layer to report an error (has to implement a checksum)
<corecode[m]>
some sort of plausibility check/bound
<corecode[m]>
ranged_integers is nightly only :/
<corecode[m]>
i thought i found a crate that did this without nightly
<diondokter[m]>
Probably just add a CRC to your data and be done with it
<corecode[m]>
diondokter: generally i really prefer to treat file system data as hostile
<corecode[m]>
or applications start failing in really weird ways
<diondokter[m]>
Could also encrypt it haha
<firefrommoonligh>
CRC is a good first line of defense
<firefrommoonligh>
But may need some tailored checks depending on the data
<firefrommoonligh>
Sanity checks etc
<corecode[m]>
i don't trust the vendor flash library all the way
<diondokter[m]>
CRC to check if the data was stored and retrieved correctly, postcard to check the format and do the deserialization and then some custom sanity checks to top it off
<corecode[m]>
yea i'll try this bounded_integer
<corecode[m]>
it's a bit unfortunate that i can't just add fields to a struct with postcard - you need to version the whole thing in an outer enum
<diondokter[m]>
Yep. But that's why I like the key-value style
<diondokter[m]>
Just add a new key
fooker has quit [Ping timeout: 258 seconds]
<firefrommoonligh>
Watch out for those cosmic rays
<corecode[m]>
you mean use a map instead of a struct?
<diondokter[m]>
Yeah
<corecode[m]>
but then my values all need to be the same type
<corecode[m]>
or do you mean in storage
<diondokter[m]>
In storage yeah
<corecode[m]>
i guess i could store every value separately
<diondokter[m]>
That's what sequential storage does for you. You hand it a key and some bytes. When you get it you give it a key and it reads the bytes back. It's up to you to interpret the bytes
<corecode[m]>
yea that part of the storage is taken care of
<corecode[m]>
(vendor library)
<corecode[m]>
it's about the bytes to rust type
<firefrommoonligh>
Oh v nice
<firefrommoonligh>
I have been wearing+tearing the same page over and over
<firefrommoonligh>
So far it's fine, but I don't do too many writes; mainly when a user changes a setting
<firefrommoonligh>
Or calibration changes
<firefrommoonligh>
I figure even if you mess up a secotor you can fix it with a firmware update later
<firefrommoonligh>
s/secotor/page/
<firefrommoonligh>
* I figure even if you mess up a page through too many writes you can fix it with a firmware update later
<JamesMunns[m]>
*you can add new variants at the end
<JamesMunns[m]>
but it's fragile because if you add to the end of a struct in the middle of something else, it will not work.
<JamesMunns[m]>
as always you *can* hand serialize as firefrommoonlight suggested, and you *can* use `repr(C, packed)`, they are just both decently error prone, not portable, etc. You do what you'd like tho, just be aware of relevant dragons.
<ryan-summers[m]>
In this case, the settings are in external EEPROM, but I've rev'd the version a few times to add and remove fields in existing hardware in a compatible way using semver. However, the compatibility management has been largely manual
<ryan-summers[m]>
I think I tried using postcard for this a while back, but opted against it because of said compatibility discussion
<JamesMunns[m]>
We do have experimental schema support, which you could potentially use to check for compatibility, but it doesn't help you at runtime, or allow for anything new, just something you could potentially check with CI to know IF you've broken wire stability.
<JamesMunns[m]>
maybe someday I'll make a "medium sized" postcard that can handle more compat topics like that, but to be honest, it probably wouldn't be too far from CBOR
<corecode[m]>
James Munns: thanks.
<corecode[m]>
what happens if you deserialize into a new struct that is now longer?
<JamesMunns[m]>
deserialization fails
<JamesMunns[m]>
like if you deserialize struct { A, B } into struct { A, B, C }?
<corecode[m]>
ah yea, so i cannot add fields, i can only remove fields
<JamesMunns[m]>
semantically, tuples and structs are the same on the wire in postcard, so this is just a sort of way to "incrementally" build a struct.
<JamesMunns[m]>
you *can* do a lot of forwards compat things in postcard, there's just a lot of different ways of doing it an no "right" way, and even if I were to pick one I liked, I haven't figured out how to do it without:
<JamesMunns[m]>
* very tricky proc macros, which I'm not good at.
<JamesMunns[m]>
* external code generation, like the protoc compiler
<ryan-summers[m]>
To be fair, proc macros are somewhat cursed IMHO. They can do wonderful things, but are truly, truly black magic
<ryan-summers[m]>
We have one for miniconf and wowzers are they hard to maintain
<ryan-summers[m]>
But absolutely wild what they enable
StephenD[m] has joined #rust-embedded
<StephenD[m]>
I've been spending a ton of free time working on a payload that's supposed to take images/video live from the eclipse next year and send it down to the ground in real time. I'm in charge of comms and every line of code I've written has been in rust, including image/video acquisition, embedded (for running the transmitter) and (some of) the decoding on the ground side. We're doing a test launch in under a week. It's been lovely
<StephenD[m]>
using Rust for everything, especially because we need the resiliency Rust provides
<corecode[m]>
i don't know if a #[serde(default)] would be sufficient
<JamesMunns[m]>
I don't think postcard works well with that attribute
<corecode[m]>
:)
<JamesMunns[m]>
there are a couple of serde attributes that really assume you are doing JSON-like key/value things, that pretty much don't/can't work with non-self-describing formats like postcard
<JamesMunns[m]>
I think flatten is another one that causes problems
<corecode[m]>
yea
<firefrommoonligh>
<diondokter[m]> "Well... but you can have it..." <- This is how we get the npm ecosystem. (I don't disagree with you in this specific case that postcard is fine)
fooker has quit [Ping timeout: 258 seconds]
<JamesMunns[m]>
it's almost like issues are nuanced and there's no one right binary answer :)
<firefrommoonligh>
<ryan-summers[m]> "To be fair, proc macros are..." <- Concur on this description. Powerful, but takes a specific skill set to maintain/understand them. See RTIC v1
<JonathanDickinso>
they also break rust-analyzer a lot of the time
fooker has joined #rust-embedded
<firefrommoonligh>
Yea that too. And intellij Rust
<JonathanDickinso>
I feel as though a #[transparent] attribute is needed for proc-macros that declares to IDE tools that nothing funny happens with syntax
<ryan-summers[m]>
The problem is that proc macros are actual programs that run on the source code that they wrap
<ryan-summers[m]>
And they literally generate new code
<ryan-summers[m]>
So you can configure IDEs to pre-run the proc-macro on the span and output the code, but often that's not what you want
<JonathanDickinso>
there's bigger issues with macros that the RA dev goes into with a blog post
<ryan-summers[m]>
Do you mean [transparent] as in, completely ignore that there's a proc-macro here? Can also be problematic because often proc-macros are what cause a trait to be implemented
<JonathanDickinso>
still run the code, but the interior of the procs/whatever can be treated as normal rust code
<ryan-summers[m]>
Ah gotcha, yeah
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
I've started to work on the SDMMC peripheral for my STM32MP1 HAL. I'm wondering how much difference there is between SD Cards and eMMC in terms of protocol. Basically I want to avoid code duplication if they are quite similar.
<sourcebox[m]>
E.g. SD cards have different states, are these identical with eMMC?
TimSmall[m] has joined #rust-embedded
<TimSmall[m]>
AFAIK, no the original base standard is the same, but extensions (including high speed modes, max number of data line, and lower operating voltages) are completely different. If you don't need to support the advanced features, that might not matter. Linux kernel source might be a good reference.
<sourcebox[m]>
I think I don't really need to support the advanced features, so I guess there's a good chance that a lot of code can be shared.
IlPalazzo-ojiisa has quit [Ping timeout: 245 seconds]
fooker has quit [Quit: WeeChat 3.8]
fooker has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
crabbedhaloablut has quit []
IlPalazzo-ojiisa has quit [Remote host closed the connection]