Skip to content

Add new method to Wire library #124

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
ghost opened this issue Oct 4, 2017 · 5 comments
Closed

Add new method to Wire library #124

ghost opened this issue Oct 4, 2017 · 5 comments
Labels
enhancement New feature or request

Comments

@ghost
Copy link

ghost commented Oct 4, 2017

It seems necessary to add a new method to the Wire library to avoid buffer limitation.
We could create a method which pass directly a buffer of data to send directly to the i2c core without to use the write() method several time:
uint8_t write(uint8_t *buffer, uint16_t size); shouldn't call write(data[i]) but save and pass the pointer to endTransmission().

@ghost ghost added the enhancement New feature or request label Oct 4, 2017
@LMESTM
Copy link
Member

LMESTM commented Oct 4, 2017

This would definitely improve performances - possibly significantly

@ghost
Copy link
Author

ghost commented Oct 4, 2017

Same issue for requestFrom(). We could add a method to pass a buffer from the user layer and not use the internal rxBuffer[].

@ghost ghost self-assigned this Oct 11, 2017
@bperrybap
Copy link

I doub't it will add much, if any, i/o performance given that Wire runs as 100Khz by default.
At the higher speeds like at 1M, there might be some gain, but even then it would likely only benefit larger transfers like when using an EEPROM/NVRAM.
I think before anything like this were added to the API, that it should be prototyped and actually measured with a logic analyzer to see just what benefits, if any, you actually get.

Now from a functional perspective, if the new functions could handle arbitrary transfer sizes by doing multiple smaller sized blocks to fully send/receive larger blocks of data on behalf of the application, that would be a very beneficial feature.
i.e. you could read/write large blocks of data to an EEPROM vs having to do all the fragmentation into 32 byte requests up in the application.

@ghost
Copy link
Author

ghost commented Oct 25, 2017

In fact, increase performance is not the goal of this issue.

The goal of this issue is to avoid a problem of memory usage. A size of 32 bytes in the internal buffer (inside the library) is enough for most of applications but sometime you need to exchange more than 32 bytes in one time. So to not increase the memory usage (when not needed), a new method is added to use a buffer with a size known by the application.

The STM32 HAL is able to manage a large number of bytes but not the Wire library without the patch #131

@fpistm
Copy link
Member

fpistm commented Oct 25, 2017

Currently, I've an issue with an I2C eeprom with this patch on lower address. I'm searching why.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants