-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I2C: write
, write_read
and read
are unnecessarily limiting
#2174
Comments
Not sure why you linked to embedded-hal's SpiDevice::transaction instead of our actual implementation that you were referring to 🫠 I'd expect reworking this won't be a big task (note to the fixer: please fix the However, |
With |
While |
Heh, must be the lack of coffee. I promise I looked before commenting 🙈 But you're right of course. |
Oh I know what confused me: This leads to: should we start chunking the |
Yes - maybe I was bad at explaining that. A single operation is also limited to 254 bytes I don't think we should do chunking in Would probably also be good if we had an inherent version of |
That's not so simple. We can't create a slice of operations, so we couldn't reuse transaction in its current form. We can probably reformulate transaction to take an Instead, if we could chunk in transaction, we could keep a single implementation. I'd expect that if a device has special needs, its driver would take care of those needs. Otherwise if a driver ends up generating a >254 byte write, we'd just fail anyway. |
Yes - we would need to create an array and that would have a hard bound so we would still limit things and temporarily allocate memory - anyways we should probably provide an inherent transaction API and document things a bit better |
When trying to port the VL53L5CX-ULD driver to Rust I discovered that this device doesn't like e.g. the firmware writes (which are up to 32k) to be chunked. The device doesn't complain but it's also not working afterwards.
When using our very nice implementation of transaction things work fine - so we should consider re-using the internals of
transaction
for the other implementations as well. Additionally, this would reduce code duplicationExample of a successful
write
usingtransaction
You can see the short pause between the
write
operations but no STOP/START/RESTART condition - this is that the sensor likes to seeThe text was updated successfully, but these errors were encountered: