I did updated to the latest "library" ver 2.1.0
And indeed by changing the "#include <Adafruit_MCP23X17.h>" got rid of the error.
mcp1.begin(0x20); had to be changed into mcp1.begin_I2C(0x20); now.
The good news is that is working, both IC's, and using your code !
Let me make a code that is not doing in parallel like is doing right now. Something progressive, and after that I will announce you if this is the way or not.

 

Yes ! I think this is it !!!
No need to make anything. Thank you so much mister @Ya'akov !!!
Here is my quick progressive code that is jumping around:

#include <Adafruit_MCP23X17.h>  //this include is using Adafruit-MCP23017-Arduino-Library version 2.1.0
Adafruit_MCP23X17 mcp1; //Instantiate mcp1 object
Adafruit_MCP23X17 mcp2; //Instantiate mcp2 object

void setup()
{
  Serial.begin(19200);
  mcp1.begin_I2C(0x20);
  mcp2.begin_I2C(0x21);
 
 /* configuring ALL GPIO as output. */
  for(int i = 0; i <= 15; i++)
  {
    mcp1.pinMode(i, OUTPUT);
    mcp2.pinMode(i, OUTPUT);
  }
}


int dly = 100;
void loop()
{
  for(int i = 8; i <=29; i++)
  {
    mcp1.digitalWrite(i, HIGH);
    delay(dly);
    mcp1.digitalWrite(i, LOW);
    delay(dly);
    mcp2.digitalWrite(i, HIGH);
    delay(dly);
    mcp2.digitalWrite(i, LOW);
    delay(dly);
  }
}

 

Yes ! I think this is it !!!
No need to make anything. Thank you so much mister @Ya'akov !!!
Here is my quick progressive code that is jumping around:

#include <Adafruit_MCP23X17.h>  //this include is using Adafruit-MCP23017-Arduino-Library version 2.1.0
Adafruit_MCP23X17 mcp1; //Instantiate mcp1 object
Adafruit_MCP23X17 mcp2; //Instantiate mcp2 object

void setup()
{
  Serial.begin(19200);
  mcp1.begin_I2C(0x20);
  mcp2.begin_I2C(0x21);

/* configuring ALL GPIO as output. */
  for(int i = 0; i <= 15; i++)
  {
    mcp1.pinMode(i, OUTPUT);
    mcp2.pinMode(i, OUTPUT);
  }
}


int dly = 100;
void loop()
{
  for(int i = 8; i <=29; i++)
  {
    mcp1.digitalWrite(i, HIGH);
    delay(dly);
    mcp1.digitalWrite(i, LOW);
    delay(dly);
    mcp2.digitalWrite(i, HIGH);
    delay(dly);
    mcp2.digitalWrite(i, LOW);
    delay(dly);
  }
}

Sorry I didn't notice that detail earlier. Not an excuse but by way of explanation,I was very distracted by things here.

 

The version 2.1.0 library example uses "#include <Adafruit_MCP23X17.h>" in the example code.

You saved the day ! Thank you ! Also mister @ericgibbs
Again, I looked over those files on github but I was probably searching for some other stuff and completely fly over that detail.
You had a very good eye !

 

 

The confirmation:

 

A casual observation here. I program in assembler, I didn't quite start before C was invented but certainly before ANSI C was invented. Nowadays, I program ARMs in assembler. I've never found C to be that helpful, generally it seems to make what I want to do more complicated; although there must be applications where C does the job better than assembler they just aren't the applications that I am writing.
When I want to get a external IC to do something. I look it its datasheet, and find what data has to go in what register. Then I look in the manual for the microprocessor I am using and write the data to the register in the I2C peripheral, to cause it to send the appropriate data to the external device, and I generally get it working quite quickly.
I see an awful lot of posts on these fora where people can't get peripherals to work, and it generally seems to be a problem with something called a "driver".
My observations on drivers suggests that they are badly written and atrociously documented, and often from dubious sources, and it doesn't surprise me that they don't work.
I've used the MCP23017 before, controlled by some Microchip part - I forget which, and it seemed to work quite readily - the difference was I didn't employ a "driver".

I'm glad he found a library because the datasheet is fairly intensive. Whoever said it has a learning curve was right. Someone else said it was a piece of cake

I prefer coding from scratch myself as well because the skills are transferable between languages. Plus I'm one of them people who wants to know exactly what makes it tick!

 

I'm glad he found a library because the datasheet is fairly intensive.

Very true, and you will see that EVERY datasheet from Microchip is like this, intensive and full of details that most of them you never use or use once in a lifetime. The essential is buried in a lot of details that not all are that important. Some are, but definitely not all for a quick and straight forward Start with the device. Especially for me, a guy who is poking them from time to time. I've always disliked the TOO much complication they bring into microchip datasheets. Don't misunderstand me, I don't say to throw away all the details, but filter (goddamit) the most important stuff to be first and quick to understand and start with, and leave the rest of the datasheet for further deep insights for whomever is brave to endeavor. Where is a will, is a possibility. The way until today, you have to read the entire datasheet, and discover you understood "something" that you have an idea, and read it again, and discovered you understood nothing. And when a problem arrives, then you have to read it all again because there are multiple references to the problem in a lot of text corners, sprinkled around just to piss you off. Come on... that is intentionally mean. Its my personal and very subjective impression that I always had about them. They have excelent products, thats the attractive side of them, thats why I keep coming back to them, but the literature is written straight from ass, pardon my french, but is very true. Again, for a guy like me who keeps coming from time to time back. THis is not true for someone that is doing all day long, for decades only this stuff, he will lough, because he knows them all like a poetry. No, we are not comparing to them. We are the small and cute ones. Right? haha

 

Very true, and you will see that EVERY datasheet from Microchip is like this, intensive and full of details that most of them you never use or use once in a lifetime. The essential is buried in a lot of details that not all are that important. Some are, but definitely not all for a quick and straight forward Start with the device. Especially for me, a guy who is poking them from time to time. I've always disliked the TOO much complication they bring into microchip datasheets. Don't misunderstand me, I don't say to throw away all the details, but filter (goddamit) the most important stuff to be first and quick to understand and start with, and leave the rest of the datasheet for further deep insights for whomever is brave to endeavor. Where is a will, is a possibility. The way until today, you have to read the entire datasheet, and discover you understood "something" that you have an idea, and read it again, and discovered you understood nothing. And when a problem arrives, then you have to read it all again because there are multiple references to the problem in a lot of text corners, sprinkled around just to piss you off. Come on... that is intentionally mean. Its my personal and very subjective impression that I always had about them. They have excelent products, thats the attractive side of them, thats why I keep coming back to them, but the literature is written straight from ass, pardon my french, but is very true. Again, for a guy like me who keeps coming from time to time back. THis is not true for someone that is doing all day long, for decades only this stuff, he will lough, because he knows them all like a poetry. No, we are not comparing to them. We are the small and cute ones. Right? haha

I have been chewing on the ATmega328 and ATtiny datasheets for a while and they are definitely mind bending. Part of the problem for me is not fully understanding the precursor chips that led to their development (stepping stones). Plus it takes significant time to absorb an entire datasheet and as you pointed out, to actually make sense of it.

Not only that, they are rather old and basic compared to new chips so I am coming in somewhere in the middle trying to tie everything together which can be maddening at times.

I suppose it comes down preference. There will always be people who want to build from scratch and as well as people who don't care as long as it works. As long as your having fun I don't think it really matters what your motivation is or what other people think is best for you!

 

...Part of the problem for me is not fully understanding the precursor chips that led to their development (stepping stones). Plus it takes significant time to absorb an entire datasheet and as you pointed out, to actually make sense of it.

I totally agree with you, in the sense that understanding a basic processor is very important in understanding everything that is built until today... I am not the guy by any means to understand that base, I never got to that level. But I was somewhat smart in some of my decisions along the years. For example, relatively recently, 1 or 2 years ago, I buy 20x PIC's but I specifically hunt for those SUPER easy to use, not that much (unnecessary) complication in their datasheet, and let's say somewhat straight forward, less words to use and learn. They have downside's as well, ofcourse but I really keep my eyes on the prize and I am happy with them, as "basic" as they are, I did a lot of projects with them. Some of the projects here on AAC forums, and some of my friends here remembers my 12F508 PIC threads.
I actually tried to depart from microchip monopol and get into other brands, but ... I didnt do it. Not yet. In my research I got over 6502 processor, talking about basic processors. And this processor was in the movie Terminator as part of his brain. Pretty cool. But... I didnt really go into it, I really wish I will do it someday in the future. I read they are still producing it, with new technology and with better stuff in it, than it was 40 years ago. There are simulators for it, that I put my hands on them as well (online even and for PC as well) , I play a bit, good documentation, good websites,good books. It remains todo in the future. I believe to get into the basics of something you must get the component first and play with it, and learn its datasheet with it in hands, putting it to work, and ideally, even having fun.
Also speaking about basic processors, here is an 8bit processor View attachment z8bitCalculator2.jpg I built in Proteus, also some time ago, but it didn't work because I have some Proteus specific errors and I dont quite understand them, to fully repair and make it work. I used a book where he was explaining every part of the circuit. Very cool book, suggested by some guys from Intel forums to me. Very cool guys there as well. Very helpfull and very patient and understandable with guys like me in the beginnings. I highly recommend them to you to go there and speak your mind to them and you will get amazed.

 

and, for Proteus people here in the forum :
....some custom components and some proper wiring, preparing for the final board, how it will look and feel

 

- I made some simulations in Proteus. And A0-A1-A2 pins work at logic high 5V as well. (As it should with any logic high in most cases). But Proteus simulator can be trusted until a point. He does not care if the chip will overheat or minor bugs that in reality can turn everything upside down.
- Is it safe to put in reality these A0-A1-A2 pins to 5V ? Because in the diagram from post #12 says 3.3V for them, quite black on white, and I'm not completely sure if this voltage can be cheated with 5V or it is as strict as they mention it there.
From my very general knowledge, I know there are different 'logic high' voltages made in this world, made by diverse companies for diverse reasons. I think I even encountered a logic high at 12V at some point in my past readings, and even higher than that. From what I remember, the technology was not there yet to accept low voltages so they used what it worked at that time. But as technology advanced, lower voltages became available and now is really no problem what value the voltage may be. Theoretically, is a range of voltages that a logic pin can get high, for ex one that accepts 5V can also operate at 4 or 3 or 2V the same. But they recommend maximum specified voltage for a logic high to eliminate mistriggers or possible errors. This is the theory I remember and made sense to me. But now, instead of 3.3V to work at 5V? this is questionable to me, its the first time I hit practically to this problem, and I stay and wonder what it may be and the logic behind. Im afraid not to burn something by playing the hero mode and put 5 instead of 3.3V.
- What do you have to say about this problem?
Thank you.

 

Fine the datasheet (I recall this being mentioned earlier in the thread by someone…)

 

I think I understand it now... I also look in its datasheet again.
This is how I read it: for A0-A1-A2 Input High Voltage, Max =VDD
Where VDD at Max = 5.5V
I must be sincere, I totally fly over this detail. I didn't see it before. Why the fungus they dont put a clear 5V there? is not that hard. Oh boy.
Ok, thank you mister Yakov for clarification, so it is good at 5V as well, then everything is more simple now.
I still wonder why they put 3.3V in that table though? Very strange and very confusing.

 

I think I understand it now... I also look in its datasheet again.
This is how I read it: for A0-A1-A2 Input High Voltage, Max =VDD
Where VDD at Max = 5.5V
I must be sincere, I totally fly over this detail. I didn't see it before. Why the fungus they dont put a clear 5V there? is not that hard. Oh boy.
Ok, thank you mister Yakov for clarification, so it is good at 5V as well, then everything is more simple now.
I still wonder why they put 3.3V in that table though? Very strange and very confusing.

Because it isn’t 5V unless Vdd is 5V. If Vdd is 3.3V, it is 3.3V.

 

Because it isn’t 5V unless Vdd is 5V. If Vdd is 3.3V, it is 3.3V.

I see... make sense. Thank you very much mister Yakov, you are a life saver !
I also remade that questionable table: