-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
i2c: support writes with a list of buffers (v2) #4763
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
Closed
dpgeorge
wants to merge
10
commits into
micropython:master
from
dpgeorge:extmod-i2c-partial-transactions-v2
Closed
i2c: support writes with a list of buffers (v2) #4763
dpgeorge
wants to merge
10
commits into
micropython:master
from
dpgeorge:extmod-i2c-partial-transactions-v2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
API is: int transfer( mp_obj_base_t *obj, uint16_t addr, size_t n, mp_machine_i2c_buf_t *bufs, unsigned int flags )
For example: i2c.writevto(addr, (buf1, buf2)). This allows to efficiently (wrt memory) write data composed of separate buffers, such as a command followed by a large amount of data.
This was referenced May 14, 2019
dpgeorge
added a commit
that referenced
this pull request
May 20, 2019
This allows to efficiently send to an I2C slave data that is made up of more than one buffer. Instead of needing to allocate temporary memory to combine buffers together this new method allows to pass in a tuple or list of buffers. The name is based on the POSIX function writev() which has similar intentions and signature. The reasons for taking this approach (compared to having an interface with separate start/write/stop methods) are: - It's a backwards compatible extension. - It's convenient for the user. - It's efficient because there is only one Python call, then the C code can do everything in one go. - It's efficient on the I2C bus because the implementation can do everything in one go without pauses between blocks of bytes. - It should be possible to implement this extension in all ports, for hardware and software I2C. Further discussion is found in issue #3482, PR #4020 and PR #4763.
tannewt
pushed a commit
to tannewt/circuitpython
that referenced
this pull request
May 27, 2021
…info Add build_memory_info for esp32s2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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).