LinkSprite mcp23017 (port expander) shield... Uno only?

I just bought one of LinkSprite's port expander shields, only to discover on reading the doco more closely that it is described as "for Arduino Uno".

This is an i2c device in shield format. Is it likely to work with a Leonardo? Is it safe to try it with a Leo, or is there any risk of smoke? I know the default i2c pins are different (Leo vs Uno) but modern boards also have the dedicated i2c pins in (I think) the same place on both models, so...? has anyone plugged one of these into a Leo and had it work?

According to the published schematics it uses the I2C pins to the side of D13 so it should work with any modern Arduino but not with older types as the Duemillanove.

Thanks Pylon, I tried reading the schematic and thought that this was the case, but didn't trust my reading skills enough yet to be sure there would not be smoke and cuss words :-) That's good news; it's nice compact packaging ideal for my purpose.

I'm finding in practise that this device doesn't seem to play well (so far) with others.

I tested it using the Adafruit mcp 23017 library on a spare Uno, and it worked fine. I can set pins to output mode and light up LEDs consistently.

But when I applied it to my Leo, I got the weirdest results. Hangs in the middle of initialising the 23017 pins, not always at the same exact place in the code. Random pins lighting up, not the ones I thought I was activating. Leo going out to lunch, no longer being seen as connected on its usb port. Having to restart IDE (???) to recover contact with Leo. No Serial monitor capability at all, seem to have lost that entirely. It's as if the board, or the library, or something, is corrupting my Leo's memory...?

I am using Leo native digital ports with LEDs to signal progress through setup() -- blink blue three times to indicate about to init the mcp device, etc. This is the only way I can tell (more or less) what is going on. I can see how far I'm getting and more or less where I hang.

At this point am still scratching my head unable to figure out WTH is going on :-) I thought perhaps I had a bad chip -- so I pulled the IC and replaced it with a brand new spare. This, interestingly, caused my sketch to appear to run correctly just once; after that, the craziness resumed. So perhaps there is something about my setup that is killing 23017 chips? I also thought perhaps the 23017 was pulling too much current and the usb-powered Leo couldn't support it, so I added a sturdy 9v power supply to the mix. That didn't help either.

I have heard this IC described as "troublesome" in the course of googling desperately for a clue. I thought that if it was packaged in a commercial shield it might be "done right" and made easy to use, but now I'm not so sure...

I'm also puzzled by apparent inconsistencies in Adafruit library examples online. Officially they seem to number the GPIO pins from 0-7 (GPIO-A) and 8-15 (GPIO-B), yet I've seen sample code posted online referring to pin numbers higher than 20. Is this just evolution in action?

Anyway, I've been banging my head on this for hours and am about to call it a night and try again tomorrow with a fresh brain, back up a few steps and re-test the unit (both ICs) with the Uno again, etc -- quite time consuming and frustrating. If anyone else has experience of this LinkSprite shield (maybe it's just worthless junk?) or recognises these problems as symptomatic of some elementary error on my part, I'd be very interested to hear from you!

I am using Leo native digital ports with LEDs to signal progress through setup() – blink blue three times to indicate about to init the mcp device, etc. This is the only way I can tell (more or less) what is going on. I can see how far I’m getting and more or less where I hang.

I guess that’s the problem. On the Leo SDA/SCL is on pins 2 and 3. If you connected LEDs there you’ll get a mess with the signals.

I’m also puzzled by apparent inconsistencies in Adafruit library examples online. Officially they seem to number the GPIO pins from 0-7 (GPIO-A) and 8-15 (GPIO-B), yet I’ve seen sample code posted online referring to pin numbers higher than 20. Is this just evolution in action?

GPIO numbers and pin number don’t have to be the same. GPA0 is on pin 21 on the chip. So if you read pin check always what exactly is meant by that term in your context.

@pylon, thanks but yes, I have figured out that pins 0-3 are off limits on a Leonardo running I2c and usb/serial :-) I am using pins 8, 9, 10, 11 with 4 coloured LEDs for my diagnostic light

In the sober light of morning I suspect that the I2C bus is the problem (it usually is) and that I have severe noise or a capacitance issue or something along those lines. I'll take the whole thing apart again and test the mcp unit in isolation (again) and verify that the original setup works without it (again)... and so on.

The irreproducibility of the results (and with 2 different ICs) suggests bus issues. Doncha think?

It may be time for the scope :-) anyway, will report back if/when I figure it out.

RESOLVED

Fortunately before I went hogwild with tearing the whole system down and retesting every part in isolation, I had one more idea... what if the LinkSprite just doesn't work as a shield on the Leo?

Looked again at the pinouts and yes, the Uno's I2C is on pins 4 and 5 (which presumably are ganged to the separate header pins north of D13). The Leo uses 2 and 3, also ganged to the separate header pins etc.

So it looks like the shield is picking up off the original header pins, not the separate ones near D13; therefore it's interpreting D4 and D5 as I2C instead of D2 and D3, with predictably weird results. it was getting data on SDA and SCL, but they were ganged to 2 floating pins. I suppose this should have been obvious to me from the gitgo...

If I had been on that team I would have designed it with a switch, so as to be usable with both models.

The bottom line is this: I peeled the shield off the Leo and let it float in space (resting on the rat's nest of jumper wires above), connected both of them to vcc and gnd, connected both of them to the i2c bus. And guess what -- my simple test code and my ugly production code are now working. I can talk to other i2c devices, LEDs light up when they should, I've got my serial console back. YES!

So in answer to my original question -- the answer is Yes, they mean it, this shield only works with the Uno. You cannot use it as a shield with any other model; but you can use it as a separate breakout board.

Looks like I have 2 choices -- (1) cut off its pins (or stick'em into some deep foam) and mount it next door to its duino buddy. I don't have a severe packaging constraint -- plenty of room for everyone -- so the space-saving shield footprint is not essential. (2) put pullups on D4 and D5, thus losing 2 more pins off the base Leo for a total of 6 unusable pins. I think option 1 is more attractive; the whole reason I'm tinkering with this device is to Get. More. Pins.

So it looks like the shield is picking up off the original header pins, not the separate ones near D13;

That's interesting because the schematics says that the I2C bus is connected to the separate ones near D13. Is it possible that you have an older revision of the board?

therefore it's interpreting D4 and D5 as I2C instead of D2 and D3,

The UNO uses A4/A5 not D4/D5. I guess that was a typo.