Not yet but I added it to a to-do list to investigate. Maybe I will add the information to some sort of mini update video where I revisit some old issues or discuss upcoming things.

@@GadgetReboot Yes, this will helps really.

This project should help: geek.adachsoft.com/home/article/id/21/n/How-to-use-ESP8266-with-PCF8574-4-input-and-4-output/refid/it#software I found this once when I was looking for some research. It’s a wireless interface to individually control some relays so the source code has routines like SW_on SW_off SW_toggle. Those show how to manipulate just one thing on the eight pin expander by reading in the state of all pins, changing just the one of interest, then writing it all back out so everything is preserved.

A PCF8574 has 3 address pins allowing up to 8 on a single bus for 64 IO pins, but then an I2C bus expander like this kzfaq.info/get/bejne/fM1zjMaA17fSmKM.html can be used to allow multiple busses, each with up to 8 PCF8574 on them

I suggest you to divide it into a matrix (for example a 12x13 allows you to read 156 pins), so that you only require 25 pins, which means 4 PCF8574 should be enough

It would seem like you would still require some kind of extra chips or driver transistors like an 8 x 8 matrix or an address decoder like taking three inputs and turning it into eight decided outputs. For a matrix I’m not too familiar with how those LED cubes do it or even general keyboard input matrix circuits but if one side of the matrix is sinking while the other one is sourcing, that’s where this particular unit would need some extra help. I don’t know if having just external pull up resistors to help source current would be enough and then there’s the whole Matrix ghosting thing where if it’s not done properly if you try to activate three sides of a square, the fourth side gets phantom activated. So I think it would be fun to look in those LED cubes and see exactly what they do because I believe those are the most efficient way to get the maximum usage out of minimal GPIO.

Interesting

Maybe 2 expanders plus 4 more Arduino I/O can do 64 like this: kzfaq.info/get/bejne/gZljlbWgl9qtiZs.html

Congrats, looks like you beat your issues! The best use of a PCF8574 is for input, rather than output. One of my 5x7cm perfboard projects has an I2C OLED and a PCF8574 connected to 5 buttons in a cross, and plus a rotary encoder (left, right, push==3 more buttons). In this way, you can display output, navigate menus, and rapidly twist in a value, all with two i2c data lines. The speed of the rotary's turn is calculated to accelerate, so high values will not require a whole lot of twisting. If you must have symmetrical drive output with a PCF8574, an octa-buffer is the thing. 74HC14's may be cheaper. If you are just driving a LED matrix or a bunch of 7-segs, the 74HC595 shift register is superior. Inexpensive, chainable, good at sourcing current, and fast. You can use the AVR native SPI bus to "shiftout()" data to them.

Yeah I saw an LED cube schematic using 74HC595s as part of the mass control infrastructure. After all the learning I have done in the past two days on the expander I can see how it is well-suited for inputs. Along the way I resolved many different issues but I think there still might be a few unresolved mysteries for another day. Now I have to think about what to tackle next...

Thanks for the comments! I didn’t know about using volatile. I remember I couldn’t get the library to work but if I tried again I might have better luck now after using the part several different ways. I just needed something to work. I haven’t done any coding in about 10 years so this is also kind of a re-introduction experience for me. The interrupt is overkill here but it was also to test it and if the code gets bigger polling may not be frequent enough.

If polling gets to slow your code has other problems ;) And besides the overkill, interrupts come with pitfalls like the need for volatile. But also non-atomic can be a problem. A good series about interrupts and the good, the bad and the ugly parts of it: hackaday.com/?s=Embed+with+Elliot%3A+Interrupts And if you have a working hardware setup, just load the library (with the right address) and it should work out of the box. And welcome back to coding! About consistency, there are multiple ways of doing it consistent but by the names of loop() and setup() and other examples Arduino it would be more consistent to follow that style. Aka camelCaseForVariables and forFunctions. And as an aid, UpperCamelCaseConstVariables or ClassNames. ALL_CAPS_FOR_MACROS (but really the need for them in C++ is VERY little). And things like pin 2 also deserves a (const byte) variable ;) Keep up the nice video's!

Thinking about consistency, one thing I did notice while poking around is the different ways people structure the use of the braces like if they are starting a for loop, some people put { at the end of that same line and others put it on the next line and it’s easy to get lost. I don’t know if there is a more accepted etiquette on that. The more I do it, the more I will figure it out. Coming from a world of spaghetti BASIC coding, any structure is good at this point.

Yeah, the placement of brackets is the biggest disagreement in C/C++ world :D I think 50/50 like it at the end or at a new line. I'm, like the IDE (because look at the default sketch), in favor of placing it on the same line. Because the block has a hard connection with the if/else/while/for/etc. You can not read it on it's own. But yeah, that is just style. As long as your consistent I don't mind people having different styles. But a consistent style makes it easier to read the code and also remember function/method/variable names.