Split software I2C code into Master-only and Master-or-Slave parts, enabling multiple instances of TwoWire in master-only role

[michkot]

Follow-up to the structural change to I2C core support from #6326

What I did is create class hierarchy, where TwiMaster (a subset of the original Twi class in) in "core" does not have any static members, callbacks or IRS, and is exposed in the twi.h header file (in C++ context only).
TwiMasterOrSlave derives from it and adds all the remaining functionality of the original Twi class.
The C interface (declared in twi.h) is rerouted from Twi singleton to TwiMasterOrSlave singleton.

Then, I modified the Wire library in similar manner, but extra measures had to be taken to guarantee compatibility with other Arduino platforms. The default mode of TwoWire class can be switched to master-only via TWOWIRE_MASTER_ONLY define - this implementation does not depend on any static/singleton variables, and also allocates the buffers dynamically (allowing for fine-tuning of necessary buffer size for each I2C interface).

Note: there is already an issue #7894 asking to support multiple I2C instances (with a kinda crude but probably working solution provided already - turning all the static dependencies into 5-tuples so that up-to 5 master/slave I2C interfaces can be used at a time).

[michkot]

There seems to be a bug in the astyle analysis, it forces a weird style change in the initializers list, when you use braces and new keyword is part of the init expression (I changed that code to use parentheses instead).

[eisnerd]

I merged over on eisnerd@f41e3a9, though what you probably want is a rebase, which I'm also happy to do. It's just trivial stuff with the switch from ICACHE_RAM_ATTR to IRAM_ATTR.

Not sure what the best way for libraries depending on Wire would be for accepting a TwoWire instance. If they stick with TwoWire, not TwoWireBase, you can't pass TwoWireMaster without building with -DTWOWIRE_MASTER_ONLY=true which for me hosed communication with several i2c devices. Not exactly sure why. They could switch to TwoWireBase if available (just #ifdef?), but this arguably looks surprising to application developers. Could the base class be named TwoWire? This would avoid libraries needing to change. It would break a lot of application code that instantiated TwoWire, but that's presumably less as it would only affect esp8266 and code already using another TwoWire instance in some way.

[michkot]

I merged over on eisnerd@f41e3a9, though what you probably want is a rebase, which I'm also happy to do. It's just trivial stuff with the switch from ICACHE_RAM_ATTR to IRAM_ATTR.

I will look into merging onto latest;

Not sure what the best way for libraries depending on Wire would be for accepting a TwoWire instance. If they stick with TwoWire, not TwoWireBase, you can't pass TwoWireMaster without building with -DTWOWIRE_MASTER_ONLY=true which for me hosed communication with several i2c devices. Not exactly sure why. They could switch to TwoWireBase if available (just #ifdef?), but this arguably looks surprising to application developers. Could the base class be named TwoWire? This would avoid libraries needing to change. It would break a lot of application code that instantiated TwoWire, but that's presumably less as it would only affect esp8266 and code already using another TwoWire instance in some way.

Hmm.. its some time since I wrote this, I will have to check my own usage. The compatibility problem gave me a huge headache at that time :D

[michkot]

If they stick with TwoWire, not TwoWireBase, you can't pass TwoWireMaster

Could you maybe just (unsafely) down-cast the wire master-only instance at the place of passing it to library, e.g. static_cast<TwoWire&>(yourWireMasterInstance)?
... hmm now Master and MasterOrSlave are "siblings", not in super/sub class relation, so a double-cast would be needed static_cast<TwoWire*>(static_cast<TwoWireBase*>(&twm)), or the plain old reinterpret_cast<TwoWire*>(&twm) :-) .
I will definitely also look into why I did not make them Base->Master->MasterOrSlave, likely because of the typedef/using hell.