TCA9548A support: I2C switch

[Citrullin]

Description

I am currently designing a PCB with ESP32 and Arduino. I ran into the issue of having the same I2C devices behind it.
So, I need a switch. The TCA9548A looks promissing, is available, especially as breakout board on aliexpress.
Not going to use it with RIOT now, but there is eventually going to be a version for RIOT as well. And I may use it then.
Would probably be helpful to have a driver in RIOT as well.
Probably also useful in order to connect mutliple OLEDs etc. A lot of use-cases can benefit from it.
This ticket is just to keep me reminded as well :D

Useful links

https://www.ti.com/lit/ds/symlink/tca9548a.pdf

[aabadie]

You might be interested in taking over #9054 and pushing the GPIO refactoring work done by @gschorcht

[Citrullin]

You might be interested in taking over #9054 and pushing the GPIO refactoring work done by @gschorcht

Those are interesting as well, but I am not sure, if I would put it it into the same code base, or use it as a base. Correct me if I am wrong. These are GPIO expander, while the TCA9548A are I2C switches. What I was thinking about is to expand the I2C API and abstraact the underlaying switch away. So from a user perspective you just interact with the other I2C devices as if the switch wouldn't even be there.
But thinking about it, the PCF8575 implementation in RIOT could profit from this as well. To abstract it away into the GPIO API. I probably have to talk to some people about this first, since I am not too deep into the peripheral implementation, even though I touched it once.

[aabadie]

Hmm, ok I see. Maybe there are ideas that could be taken from the work done with GPIO expanders.

[maribu]

I guess the best user experience would be to create virtual I2C buses from it (e.g. 1 for each channel - but as I understand one could also connect multiple channels at the same time). That way device drivers (such as e.g. sensor or display drivers) don't need to be re-written with awareness for I2C routers.

IMO the best would be if I2C devs could be provided as XFAs with different implementations being used. E.g. the RP2040 also has native I2C peripherals as well as the programmable state machines that can do I2C as well - so there are multiple use cases for this.

There is already work in progress to do a similar feat with GPIO. It is a slow in painful road to change each and every periph driver, so I'd say don't expect results soonish :) I personally won't start to work on that before the GPIO stuff has landed...