Foxyloxy has joined #rust-embedded
Foxyloxy_ has quit [Ping timeout: 260 seconds]
Darius has quit [Read error: Connection reset by peer]
Darius_ has joined #rust-embedded
Darius_ is now known as Darius
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
<re_irc> <> Should `i2c: I2C` use a mutable reference other than an owned structure? In real use there could be multiple I2C devices on one pair of I2C bus wires
<re_irc> <> Generally multiple devices on the same bus is left as an exercise for the user.
<re_irc> <> There are solutions like that around
fabic has joined #rust-embedded
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
<re_irc> <> Yes
<re_irc> <> Send a PR
<Lumpio-> Threading the &mut through every single call is so cumbersome
<Lumpio-> Wish there was a better way
<re_irc> <> I'm struggling a bit with parsing binary data in Rust, and wonder what the best way would be.
<re_irc> <> 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> <> 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> <> 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> <> Is making some kind of `parse_message` function that just does everything the best option?
<re_irc> <> 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> <> For reading bits, you could use a crate like bitvec to make stuff easier:
<re_irc> <> Thanks, that sounds like a good idea.
troth has quit [*.net *.split]
<re_irc> <> 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> <> `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> <> 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
fabic has joined #rust-embedded
<re_irc> <> room ok, meeting time! agenda is, please add anything you'd like to discuss
<re_irc> <> no announcements from me, does anyone else have anything?
<re_irc> <> ok, guess not! shout later if you think of anything
<re_irc> <> since last week, the error traits and delayus unification embedded-hal PRs were merged 🎉
<re_irc> <> 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 (
<re_irc> <> 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?
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <> 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> <> looks like this will be a much quieter meeting than last week, heh
<re_irc> <> one new embedded-hal PR that might be worth discussing briefly is about combining the i2c nack errors, if anyone has thoughts...
<re_irc> <> 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> <> I have no idea about CAN, but: why is the Frame type needed?
<re_irc> <> vs send/receive just taking a `&[u8]`?
<re_irc> <> nesting enums is kind of annoying, but having variants for NackData, NackAddress, NackGeneric is a bit cruddy too
<re_irc> <> CAN frames are defined to have extra metadata beyond just the data, which may be empty
<re_irc> <> and that extra stuff is standardised across all can implementations
<re_irc> <> ah, it's not like ethernet where a packet on the wire is basically a `[u8]`?
<re_irc> <> correct
<re_irc> <> the metadata isn't byte-oriented
<re_irc> <> Fun! I see, thanks :)
<re_irc> <> check out the diagram lol
<re_irc> <> of course they had to overcomplicate it, hehe
<re_irc> <> it's even worse with CAN-FD
<re_irc> <> and the data length is always 0..=8 bytes, never longer, so it fits into a struct quite nicely
<re_irc> <> (in CAN 1 and 2, not FD)
<re_irc> <> 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> <> 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> <> re the i2c nak: I'm concerned that implementors will take the lazy route of just returning Unknown
<re_irc> <> poisoning the well for driver writers
<re_irc> <> posborne: I believe implements those traits for socketcan
<re_irc> <> dirbaio: same
<re_irc> <> making it so driver writers can't rely on the impl distinguishing them
<re_irc> <> at which point we might as well just have one nack?
<re_irc> <> exactly...
<re_irc> <> it's kinda similar to what happened with DelayUs/DelayMs
<re_irc> <> if there's some functionality that's not universally available, drivers simply end up not being able to use it
<re_irc> <> the tyranny of the least common denominator, huh
<re_irc> <> 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> <> lots of confusing possible errno values, heh
<re_irc> <> adamgreig: Not sure off hand, I'll have to see how the kernel maps out the error responses for those cases.
<re_irc> <> 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> <> yeah.. but then we might as well have a single ACK variant
<re_irc> <> yea
<re_irc> <> 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> <> ah, interesting, hadn't really considered that each driver could be different, how fun
<re_irc> <> yeah I was just through the code
<re_irc> <> i2c-stm32f7.c seems to ENXIO on any NAK
<re_irc> <> hmm
<re_irc> <> so maybe single nak is the answer :/
<re_irc> <> guess a question of whether it's worth having separate nacks if some impls will have to return the "i dunno" variant
<re_irc> <> i2c-st.c does EIO on any NAK
<re_irc> <> I don't think you can even distinguish "was it a NAK or was it something else"
<re_irc> <> lol
<re_irc> <> 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> <> i2c-cp2615.c returns ENXIO for "bus error"
<re_irc> <> I think it's just broken
<re_irc> <> well, at least it's loads of linux devices in addition to the anonymous proprietary thing mentioned already in the PR
<re_irc> <> 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> <> i'm not so sure though
<re_irc> <> about removing the nak distinction
<re_irc> <> having the 3 variants means the driver can detect Unknown and panic/propagate it
<re_irc> <> presumably if the i2c device you're using *needs* you to distinguish them, it'd be broken on Linux anyway
<re_irc> <> so maybe adding Unknown is not that bad
<re_irc> <> assuming HAL writers won't be lazy
<re_irc> <> "stm32 can't distinguish naks" seems a widespread misconeption
<re_irc> <> indeed
<re_irc> <> also being able to match on `NoAcknowledge(_)` is nice
<re_irc> <> 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> <> i guess in that case a driver could take either route if it gets a generic nack, probably retry though
<re_irc> <> so anyway some sort of progressive enhancement is possible when hals support it
<re_irc> <> well, let's call it there for this week's quiet meeting, thanks everyone!
<re_irc> <> hmm
<re_irc> <> kinda nice to not require two slices are identical length just in terms of usability
<re_irc> <> it certainly is very common to write a byte or two and then read a lot of bytes
<re_irc> <> and sure, the transactional api could do that too I guess, but it's a bit more verbose, right?
<re_irc> <> yeah
<re_irc> <> 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> <> with typestates the "state" is part of the type, so it must be known at compile time
<re_irc> <> with async/await the "state" is a field in the autogenerated Future struct
<re_irc> <> so not known at compile time
<re_irc> <> they're different things for different use cases
<re_irc> <> the fields of a future are not known at compile time?
<re_irc> <> yeah they are
<re_irc> <> 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> <> so, the variant content types are known?
<re_irc> <> yes
<re_irc> <> I meant that the state of a particular Future instance is not known at compile time
<re_irc> <> while the state of a typestate thing like Pin<Input<Floating>> is
<re_irc> <> so you'd have a hard time "translating" something from async into typestates
<re_irc> <> because with typestates the states must be known at compile time
<re_irc> <> you'd have to translate that big enum into an explicit form
<re_irc> <> ie if you do .into_push_pull_output() the compiler knows you'll get a Pin<Output<PushPull>>
<re_irc> <> 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> <> right. So the "dynamic" enum-based state machine we all know and love from C, but generated by the compiler. Thanks for the clarifications :)
<re_irc> <> yup
<re_irc> <> exactly! :)
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded