<re_irc>
<@jspn:matrix.org> I'm struggling a bit with parsing binary data in Rust, and wonder what the best way would be.
<re_irc>
<@jspn:matrix.org> Say I have receive this message I just sent, and put it in a [u8; 8]. How would you guys go about parsing this?
<re_irc>
<@jspn:matrix.org> My idea was to create a `get_angle` function that takes in `&[u8; 2]` to get the alpha or beta angle, and call it with `get_angle(&message[0..2]).
<re_irc>
<@jspn:matrix.org> But that doesn't work. I've seen a way to make it kinda work with const generics, but still seemed like a hassle.
<re_irc>
<@jspn:matrix.org> Is making some kind of `parse_message` function that just does everything the best option?
<re_irc>
<@diondokter:matrix.org> Usually I´d want to make a struct that represents the message. That struct then has a serialize and deserialize function that does all the fields at the same time
<re_irc>
<@jspn:matrix.org> Thanks, that sounds like a good idea.
troth has quit [*.net *.split]
<re_irc>
<@josfemova:matrix.org> so are there any near-future plans to continue work on the cortex-r stuff? just curious
troth has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
<re_irc>
<@jamwaffles:matrix.org> jspn:matrix.org: `nom` has a few different bitfield parsing functions (and works in no_std) but you might feel it's one size too large on the parsing hammer selection cos it does loads of other stuff too
fabic has joined #rust-embedded
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
nexos has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 250 seconds]
<re_irc>
<@adamgreig:matrix.org> Going to be a few minutes late for them meeting tonight, will kick us off at five or ten past
<cr1901>
agg: Feeling a bit under the weather, I'll be in read only mode for the meeting/a bit late
<re_irc>
<@adamgreig:matrix.org> no announcements from me, does anyone else have anything?
<re_irc>
<@adamgreig:matrix.org> ok, guess not! shout later if you think of anything
<re_irc>
<@adamgreig:matrix.org> since last week, the error traits and delayus unification embedded-hal PRs were merged 🎉
<re_irc>
<@adamgreig:matrix.org> there's a bit of new feedback on the separate-buffers SPI thing, including a suggestion to maybe try implementing it just to check we've not missed anything (https://github.com/rust-embedded/embedded-hal/pull/287)
<re_irc>
<@adamgreig:matrix.org> and the embedded-can PR has been updated with an Other error variant, and renamed Ack to Acknowledge, which I think were the final comments for it, so perhaps that's now ready to merge?
<re_irc>
<@posborne:matrix.org> Nothing from me, I've been catching up a bit and will be looking to clean up a few of the linux side crates that need some love (e.g. sysfs-pwm) but nothing to escalate.
<re_irc>
<@adamgreig:matrix.org> looks like this will be a much quieter meeting than last week, heh
<re_irc>
<@adamgreig:matrix.org> one new embedded-hal PR that might be worth discussing briefly is https://github.com/rust-embedded/embedded-hal/pull/316 about combining the i2c nack errors, if anyone has thoughts...
<re_irc>
<@adamgreig:matrix.org> it sounds like apparently at least some very niche annoying devices do exist that really can't disambiguate between address and data phase nack, which is a pain
<re_irc>
<@dirbaio:matrix.org> I have no idea about CAN, but: why is the Frame type needed?
<re_irc>
<@dirbaio:matrix.org> vs send/receive just taking a `&[u8]`?
<re_irc>
<@adamgreig:matrix.org> nesting enums is kind of annoying, but having variants for NackData, NackAddress, NackGeneric is a bit cruddy too
<re_irc>
<@adamgreig:matrix.org> CAN frames are defined to have extra metadata beyond just the data, which may be empty
<re_irc>
<@adamgreig:matrix.org> and that extra stuff is standardised across all can implementations
<re_irc>
<@dirbaio:matrix.org> ah, it's not like ethernet where a packet on the wire is basically a `[u8]`?
<re_irc>
<@adamgreig:matrix.org> correct
<re_irc>
<@adamgreig:matrix.org> the metadata isn't byte-oriented
<re_irc>
<@dirbaio:matrix.org> Fun! I see, thanks :)
<re_irc>
<@dirbaio:matrix.org> of course they had to overcomplicate it, hehe
<re_irc>
<@adamgreig:matrix.org> it's even worse with CAN-FD
<re_irc>
<@adamgreig:matrix.org> and the data length is always 0..=8 bytes, never longer, so it fits into a struct quite nicely
<re_irc>
<@adamgreig:matrix.org> (in CAN 1 and 2, not FD)
<re_irc>
<@posborne:matrix.org> I've worked with SocketCAN on linux quite a bit in the past; I'll review the hal stuff for compat there but I think, off of memory, it should be workable.
<re_irc>
<@adamgreig:matrix.org> though in the PR it's just a Frame trait that any struct could implement, which is probably wise to deal with various frames-in-mailboxes or whatever that implementations might have
<re_irc>
<@dirbaio:matrix.org> re the i2c nak: I'm concerned that implementors will take the lazy route of just returning Unknown
<re_irc>
<@dirbaio:matrix.org> poisoning the well for driver writers
<re_irc>
<@dirbaio:matrix.org> making it so driver writers can't rely on the impl distinguishing them
<re_irc>
<@adamgreig:matrix.org> at which point we might as well just have one nack?
<re_irc>
<@dirbaio:matrix.org> exactly...
<re_irc>
<@dirbaio:matrix.org> it's kinda similar to what happened with DelayUs/DelayMs
<re_irc>
<@dirbaio:matrix.org> if there's some functionality that's not universally available, drivers simply end up not being able to use it
<re_irc>
<@adamgreig:matrix.org> the tyranny of the least common denominator, huh
<re_irc>
<@adamgreig:matrix.org> posborne: while you're here, actually, do you know if linux i2c lets you distinguish nack coming from the address vs data phase? we couldn't figure it out a couple weeks ago
<re_irc>
<@adamgreig:matrix.org> lots of confusing possible errno values, heh
<re_irc>
<@posborne:matrix.org> adamgreig: Not sure off hand, I'll have to see how the kernel maps out the error responses for those cases.
<re_irc>
<@adamgreig:matrix.org> dirbaio: I guess a generic driver that needs to know can always issue an empty-data transfer first, so the only possible nack is address phase, and if that gets acked, any further nacks to same address are _probably_ data phase...
<re_irc>
<@dirbaio:matrix.org> yeah.. but then we might as well have a single ACK variant
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@posborne:matrix.org> At least reading through the kernel bitbang impl, I think -ENXIO is probably a good indicator of address failure vs other NAKs being during the data portion of the transfer but not sure if every "algo" (and hardware backend) supports that distincation consistently.
<re_irc>
<@adamgreig:matrix.org> ah, interesting, hadn't really considered that each driver could be different, how fun
<re_irc>
<@dirbaio:matrix.org> yeah I was just through the code
<re_irc>
<@dirbaio:matrix.org> i2c-stm32f7.c seems to ENXIO on any NAK
<re_irc>
<@adamgreig:matrix.org> hmm
<re_irc>
<@adamgreig:matrix.org> so maybe single nak is the answer :/
<re_irc>
<@adamgreig:matrix.org> guess a question of whether it's worth having separate nacks if some impls will have to return the "i dunno" variant
<re_irc>
<@dirbaio:matrix.org> i2c-st.c does EIO on any NAK
<re_irc>
<@dirbaio:matrix.org> I don't think you can even distinguish "was it a NAK or was it something else"
<re_irc>
<@dirbaio:matrix.org> lol
<re_irc>
<@posborne:matrix.org> Yeah, I checked the imx impl with dma and for that chip it seems like they do NXIO and the hardware just exposed "acked or not acked"; that might be commonplace in some IP chunks in multiple chips.
<re_irc>
<@dirbaio:matrix.org> i2c-cp2615.c returns ENXIO for "bus error"
<re_irc>
<@dirbaio:matrix.org> I think it's just broken
<re_irc>
<@adamgreig:matrix.org> well, at least it's loads of linux devices in addition to the anonymous proprietary thing mentioned already in the PR
<re_irc>
<@adamgreig:matrix.org> so "some impls won't be able to tell the nacks apart" -> "no generic driver can rely on different nacks" -> "no point having multiple nacks"?
<re_irc>
<@dirbaio:matrix.org> i'm not so sure though
<re_irc>
<@dirbaio:matrix.org> about removing the nak distinction
<re_irc>
<@dirbaio:matrix.org> having the 3 variants means the driver can detect Unknown and panic/propagate it
<re_irc>
<@dirbaio:matrix.org> presumably if the i2c device you're using *needs* you to distinguish them, it'd be broken on Linux anyway
<re_irc>
<@dirbaio:matrix.org> so maybe adding Unknown is not that bad
<re_irc>
<@dirbaio:matrix.org> assuming HAL writers won't be lazy
<re_irc>
<@dirbaio:matrix.org> "stm32 can't distinguish naks" seems a widespread misconeption
<re_irc>
<@adamgreig:matrix.org> indeed
<re_irc>
<@dirbaio:matrix.org> also being able to match on `NoAcknowledge(_)` is nice
<re_irc>
<@adamgreig:matrix.org> the only examples i remember of drivers that handle them differently is when commands can be retried if the data nacked but not if the address nacked
<re_irc>
<@adamgreig:matrix.org> i guess in that case a driver could take either route if it gets a generic nack, probably retry though
<re_irc>
<@adamgreig:matrix.org> so anyway some sort of progressive enhancement is possible when hals support it
<re_irc>
<@adamgreig:matrix.org> well, let's call it there for this week's quiet meeting, thanks everyone!
<re_irc>
<@adamgreig:matrix.org> kinda nice to not require two slices are identical length just in terms of usability
<re_irc>
<@adamgreig:matrix.org> it certainly is very common to write a byte or two and then read a lot of bytes
<re_irc>
<@adamgreig:matrix.org> and sure, the transactional api could do that too I guess, but it's a bit more verbose, right?
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@barafael:matrix.org> just had a thought. What's the relationship between async/await and typestate programming? Both deal with state machines. async/await has states where computation happens and then control is yielded, after which I/O triggers a state transition. Type state machines have states where nothing really happens, and in the transitions, usually computation or I/O happens.
<re_irc>
<@dirbaio:matrix.org> with typestates the "state" is part of the type, so it must be known at compile time
<re_irc>
<@dirbaio:matrix.org> with async/await the "state" is a field in the autogenerated Future struct
<re_irc>
<@dirbaio:matrix.org> so not known at compile time
<re_irc>
<@dirbaio:matrix.org> they're different things for different use cases
<re_irc>
<@barafael:matrix.org> the fields of a future are not known at compile time?
<re_irc>
<@dirbaio:matrix.org> yeah they are
<re_irc>
<@dirbaio:matrix.org> the autogenerated Future for an `async fn` is kinda a big enum where each variant is the "state" (where the function is suspended) and the variant contents are the local variables
<re_irc>
<@barafael:matrix.org> so, the variant content types are known?
<re_irc>
<@dirbaio:matrix.org> yes
<re_irc>
<@dirbaio:matrix.org> I meant that the state of a particular Future instance is not known at compile time
<re_irc>
<@dirbaio:matrix.org> while the state of a typestate thing like Pin<Input<Floating>> is
<re_irc>
<@dirbaio:matrix.org> so you'd have a hard time "translating" something from async into typestates
<re_irc>
<@dirbaio:matrix.org> because with typestates the states must be known at compile time
<re_irc>
<@barafael:matrix.org> you'd have to translate that big enum into an explicit form
<re_irc>
<@dirbaio:matrix.org> ie if you do .into_push_pull_output() the compiler knows you'll get a Pin<Output<PushPull>>
<re_irc>
<@dirbaio:matrix.org> but if you do my_future.poll(), the state for the future may change to lots of different states, depending on stuff at runtime
<re_irc>
<@barafael:matrix.org> right. So the "dynamic" enum-based state machine we all know and love from C, but generated by the compiler. Thanks for the clarifications :)