Skip to content
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

Wire buffer length improvments. #8398

Merged
merged 2 commits into from
Dec 14, 2021

Conversation

flaviut
Copy link
Contributor

@flaviut flaviut commented Dec 5, 2021

Enable I2C_BUFFER_LENGTH definition for Wire lib

Based on
paclema/arduino-esp32@375a89e

We should have been very careful when #defining things to not use a name
that could conflict with the user's own code, so this marks that old
define as deprecated.

If you opt-into the new behavior, you do not get the old BUFFER_LENGTH
constant.

Increase buffer indexing variable size

I looked over the users of these variables and they should be fine with
no additional changes. The existing methods already have an option to
use size_t rather than uint8_t.

There's a few methods which return int instead of size_t, which isn't
great from a portability perspective but will be fine since this only is
designed to run on the ESP8266.'

Fixes #8391


Feel free to use this patchset in full or in part.

#ifndef I2C_BUFFER_LENGTH
// DEPRECATED: Do not use BUFFER_LENGTH, prefer I2C_BUFFER_LENGTH
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I expect this may be a bit controversial. My idea is to use the new I2C_BUFFER_LENGTH functionality as a carrot to convince people to switch to the new define.

@flaviut
Copy link
Contributor Author

flaviut commented Dec 5, 2021

cc @d-a-v

Copy link
Collaborator

@d-a-v d-a-v left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
Thanks !

@d-a-v
Copy link
Collaborator

d-a-v commented Dec 6, 2021

It has to be noted that the resulting flash occupation is decreased with this PR.
I don't know whether a note about that in OP would be useful.

So for example when one needs an uint8_t, it may be always good in internal code to use uint_fast8_t instead
(except when code must ensure that 255+1==0).

Based on
paclema/arduino-esp32@375a89e

We should have been very careful when #defining things to not use a name
that could conflict with the user's own code, so this marks that old
define as deprecated.

If you opt-into the new behavior, you do not get the old BUFFER_LENGTH
constant.

As a bonus, changing these uint8_ts to size_t both reduces the code
size & improves performance.
I looked over the users of these variables and they should be fine with
no additional changes. The existing methods already have an option to
use size_t rather than uint8_t.

There's a few methods which return int instead of size_t, which isn't
great from a portability perspective but will be fine since this only is
designed to run on the ESP8266.
@flaviut
Copy link
Contributor Author

flaviut commented Dec 7, 2021

It has to be noted that the resulting flash occupation is decreased with this PR.

That's interesting, and not something I expected. I've updated the commit message with this information.

Copy link
Collaborator

@earlephilhower earlephilhower left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@earlephilhower earlephilhower merged commit 42aa0e6 into esp8266:master Dec 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TwoWire: use 32 bits for buffer size and offset
3 participants