i2c: support writes with a list of buffers (v2) #4763
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an alternative implementation to #4746 that uses a different C-level API. Instead of
start_addr()
,read_part()
andwrite_part()
, it has a single C functiontransfer()
. This function takes an array of buffers to read/write, which should be done all at once.The reason to reimplement it this way is that it makes it much easier for the various ports to satisfy the C-level API. With the implementation in #4746 it's rather difficult since ports would usually need to cache incoming buffers until the last one, and the return value (eg error code) from the intermediate calls would not be useful.
The PR here includes updates to the stm32, nrf and zephyr ports. All other ports just use software I2C so they are OK.
Also, instead of overloading
i2c.writeto()
to allow a list of buffers, the implementation here adds the new "vector" methodi2c.writevto()
, to see how that would look (discussed in #4020).