-
Notifications
You must be signed in to change notification settings - Fork 13.3k
suggestion , do not deprecate wire.pins() #2774
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
Comments
I agree that there is lots of library code that exists that calls Wire.begin() and there needs to be solution to allow a sketch to modify the pins and clock of the Wire object that does not require modifying libraries. I have a library right now (hd44780) that calls Wire.begin(). Not sure about the toggling/altering of pins for using multiple i2c buses for the single Wire object. That one seems a bit odd as normally there are different objects for each bus, but I get the reasoning behind it when using libraries that have hard coded their object name to "Wire" particularly if using multiple libraries on different buses. For TwoWire objects without toggling pins for multiple buses, here is another approach: It looks like this is all that needs to be done:
The last part of using a weak symbol is the main key to making all this work. And that Wire object declaration in the sketch would override & replace the one in Wire.cpp i.e. this gives the sketch a way to declare the Wire object itself along with overriding the default pins and speed if it does not want to use the Wire library defaults. These changes are fairly minimal, should be difficult to implement, and I'd be happy to submit a pull request if there is interest in going down this path. IMO, using constructors to set default parameters in "Wire" objects is better than using functions to set defaults pins and speeds in that typically these are not things that are changed for a given bus/environment and it keeps this type of stuff out of the runtime code and libraries. All that said this does not solve the issue of wanting to use multiple libraries that are hard coded to use the Wire object on different buses. Perhaps the ultimate solution is to do both.
Note: other Wire libraries like the one for the PIC32 core, do more like keep track of the Wire.begin() calls inside the object and only the first one does anything. |
And doing what I described is clearly a kludge, I had 2 devices with same ID and needed to run them both right then as was surprised it actually worked well. So I limited my issue to that ( and compiler flags CAN cause issues with deprecated flags for I figured any solution involving instancing twi class better for wire would be overly complicated, but you seem to understand and have solutions. |
I notice wire.pins() is marked deprecated.
Please consider, I did not see an explanation for reasoning, maybe I missed it.
A lot of libraries have a Wire.begin() inside their own
begin()
or init function.Then they immediately send initialization codes to lcds or oleds.
Short of modifying libraries, or pushing authors to have to modify their code to include arguments for passing through sda and scl, there is no way other than calling pins() or begin() before the libraries begin() to change the pins. Also to be pedantic
begin
is now being called twice once for just kludging the pins then inside the library using wire and also makes it confusing if you wanted to toggle pins back and forth so you can use twi on 2 buses.It is easier to do something like ( granted this is not ideal but if you must use twi twice )
❗️ So another issue with calling begin is that it hardcodes clock and stretch in twi_init, so you must keep redoing those. This might be another "bug" that can be improved by using twi_dcount and twi_clockStretchLimit in twi_init instead of hardcoded values, and init those globals instead.
The text was updated successfully, but these errors were encountered: