Espeasy: Enhancement: make GPIOs expander as part of ESPEasy core

[papperone]

Steps to reproduce

How can we trigger this problem? Not an issue but an enhancement request

Expected behavior

Tell us what should happen? I'd like to have most commonly used GPIOs expanders (e.g. PCF8574) as part of core code, so that any plugins who will require a GPIO can select not only the ESP8266 ones but as well the one from expander(s); this is a huge change I can imagine but will allow to abstract the plugin from the GPIO selection, make virtually any device usable via internal or external GPIOs seamlessly and avoid code duplication on each plugin in order to support expanders

Actual behavior

Tell us what happens instead? only ESP8266 GPIOs are usable by default

System configuration

Hardware: ANY

Software or git version: Enhancement for 2.1/mega

[TD-er]

Wasn't there already a similar request, or was it on the forum?
One of the issues to support it will be on how to number these extra GPIOs.

[Domosapiens]

Numbering could be done by PCFGPIO prefix and is given by address selection
https://www.letscontrolit.com/wiki/index.php/PCF8574

[papperone]

we could have Dxx for the internal GPIOs (as currently done using NodeMCU/Wemos names and select something else for the expanders (like PCxx) this is a minor issue, I think the major is to rewrite the GPIO handling routine and as well the hardware page to be able to define one (or maybe more) expanders as active or not...

[papperone]

BTW as there are many different CHIPs to be used as GPIOs expanders it will be tricky to choose which one should be part of the core code (I personally use a lot MCP23017 as easy to wire and offers 16 GPIOs).

[ShardanX]

Mainly there are three widespread GPIO chips: MCP2308, MCP23017 and PCF8574. Just for me the MCP2308 is not necessary as it hs more or less the same functionality as the PCF8574 has. PCF8574 has a very wide possible address range as there are two chips with different start addresses so you may use up to 16 of these. The MCP23017 has most GPIO's on one single chip. I think it might be these two to chose from.

651 and #702 might be included here.

[TD-er]

If more than one expander is to be used at once, then the number of tasks (currently 12) in ESPeasy should be increased.

This also means the storage of settings should be changed.

[ShardanX]

OR the way these expanders are read should be changed as described in #651

[TD-er]

@ShardanX I am not sure what you mean.
I thought this issue was about just adding the option to use expanders like these to be able to connect more devices.
So they can be used just like the normal GPIOs. (with some limitations regarding speed and timing of course)
Thus the need for inverting pins and other chip specific stuff should be included just to make it as transparent as possible.
Or did I miss something? (and need some extra coffee ;) )

[ShardanX]

More coffee to me too.... and i should stop doing 10 things same time.
Sorry, mixed up my own postings, #557 is the one.... corrected the posting.

[TD-er]

I can imagine that when you're using a GPIO expander, you would like to use several of the same devices.
Like (input) switches or switch something like a relais.
So instead of do almost a complete refactoring, we could also create special versions of these plugins for use with a GPIO expander and preferably one which can work with all of the widespread GPIO expander chips.

So what would these GPIO's be used for? I can imagine it is not for high-speed communications, or even continuous communications. Realtime operations are almost impossible for these.

[Domosapiens]

So what would these GPIO's be used for?

Display of 3 MPU6050 axis with 3*TM1637 takes 6 GPIO's and SCL/SDA for the MPU6050.

[TD-er]

When you set the MPU6050 to I2C, it will take only 2 lines for the I2C communications.
The TM1637 could in theory share the clk line, which would take 4 GPIOs.

But still, even if you would want to increase it to lets say 7 TM1637, it would be best to operate it via a special plugin which would address the GPIO expander. (1 for CLK, 7 for the data of each, makes 8 pins)
Given these GPIOs can be used fast enough to do this.
If you're using multiple plugins which are not aware of other present plugins for the same device, things could get unacceptable slow.

So maybe it could be an option to create expander-aware plugins for those few you would want to have lots of them.

[Budman1758]

Maybe the current plugins for these chips can be expanded. Instead if configuring a single pin as a task the plugin could define ALL of the pins as input or output. A checkbox and a value for each pin. Inputs could have a value field and outputs would work as they do now. That way a 16 pin expander would only use 1 task. Would that be easier from a programming perspective?

[papperone]

I think we are mixing multiple "things"...
1) I think ESP8266 are too few in several scenarios and we all uses GPIOs expanders; today they are limited to be used as "switch" but you cannot connect anything else to them (like a sensor or a display) as their plugins refers only to internal GPIOs; having an expander predifined ideally you can have 8 or 16 more choices when you select a GPIO for any gived plugin/device/tasks
2) it's true 12 tasks are very limiting many applications, specially when you add an expander like MCP23017 and want to use all of its 16 GPIO; I think the solution of Shardan to make the output in that case "binary" is not a bad idea but still nothign to do with point 1) which is something completely different...

[Budman1758]

Not sure I follow your "point 1" The only use for these GPIO expanders is for general HI or LOW use cases. They are not as configurable as "native" GPIOs on the ESP chip. As far as I know they cannot do I2c or SPI or anything of that nature. (I think?) Digital sensors can be used if they put out hi or low. I don't know if they can be used for PWM either. Seems to me to ask for a complete rewrite of the ESP core is a lot to ask when an expansion of the plugin might be easier. Also, not every use case involves these expanders.

Just my 2 cents worth.

[papperone]

well leaving aside I2C for which a proper multiplexer IC (TCA9548A) exists and there shoudl be arlready a discussion on it.
While it's true what you state about simple digital switches, there are plenty of plugins with specific functionality that uses Digital IOs; my idea is instead of rewrite all current (and future!) plugins with huge amount of redundat code/memory it would be ideally nice to have the expander implemented in the core, and I said it already, it'a a major upgrade of ESPEasy core that won't be "easy" at all but if we can succeed it will make any device which uses digital IO to be able to use expanders seamlessly without even knowing about it...
just my 2 cents as well :)

[Budman1758]

I just recently "discovered" something. I was under the distinct impression that in order to use these IO expanders that in order to "enable" them you had to define at least 1 of the ports as an input to get them to function. I have a project I'm working on right now that has both an MCP23017 and a PCF8574 IO expander. The MCP is connected to a 16 gang relay and the PCF is going to be for inputs. Anyway I found that BOTH of these work as outputs WITHOUT defining either one as a device.

If this is normal that's great but methinks the wiki pages for these should so state this.

[uzi18]

I realy like this idea to move expanders into core.
It will resolve big problem with input/output selection on Pcf8574.
It will create simple solution for all external ios.

To consider some gpios need to be locked for one plugin to not have acces for writing from another...

[vikasjee]

Must include MCP23017 due to more IOs