Open travnick opened 8 months ago
Do you mean something like this?
https://esphome.io/components/tca9548a
That's a dedicated I2C multiplexer though, not a general GPIO multiplexer. ESPHome has a software implementation for SPI, but not for I2C. There are libraries that do I2C in software, so it's technically doable - if ESPHome had that, it could presumably use any GPIO multiplexer.
If the problem is trying to use multiple I2C peripherals with the same address (which I expect is the most common reason to want a I2C multiplexer), another solution ESPHome could potentially use is pin muxing - by re-initialising the hardware I2C bus with a different SDA pin (with only that pin changing) when you want to switch talking to a different peripheral. It has the benefit of not needing extra hardware and only needing to use one extra pin.
The documentation says that ESP8266 does not have a hardware I2C, but have two of hardware SPI, so ESPHome has to have software I2C implementation https://nodemcu.readthedocs.io/en/latest/modules/i2c/. Am I right?
My point is to have only hardware SPI pins occupied (with software I2C on top of it) and have other ESP8266 pins free to do other stuff.
(This isn't my usual area, I'm just trying to provide some context and help where possible)
Sorry, yes, you are right - ESP8266 indeed has no hardware I2C, and uses software. Although oddly enough my point is still valid - it only supports one I2C bus. That is (was) due a limitation in the library used (Wire.h). But that changed recently with this PR providing a workaround (not in a release version yet):
I'm assuming Wire.h (and it's API) was chosen because it's so commonly used - it means automatic support for a vast number of Arduino libraries. I mention that because unfortunately Wire.h has some significant limitations that can't be fixed without breaking things.
One of those limitations is that Wire.h only supports internal pins. It would need to be replaced with another library in order to use ESPHome's concept of pins (which is what allows using pins on multiplexers as though they were normal internal pins in most cases - like using Pins Schemas for SPI).
I completely agree this would be very nice to have. But AFAICT the easy way to fix this would break a bunch of stuff. And the hard way is... hard.
Describe the problem you have/What new integration you would like
I'd like to have possibility to use Pin Schema for I2C configuration, the same as it's available for SPI.
Please describe your use case for this integration and alternatives you've tried:
It sounds reasonable to use a MCP23Sxx I/O Expander (GPIO over SPI), and then I2C over it.
Additional context
I'm not sure if it's technically possible at all to have I2C over any I/O Expander (didn't find anything on the internet), but I hope it is.