MCP23017 help

General project help for Adafruit customers

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
jag911
 
Posts: 18
Joined: Tue Mar 06, 2012 11:59 am

MCP23017 help

Post by jag911 »

Trying to use a MCP23017 to get more GPIO pins. I'm learning my way through the Arduino world so I appreciate any help and apologize for stupid questions! ;)

So first please review my schematic and make sure my basic circuit is in order. I based it off of a combination of how it's used on the AdaFruit RGB Shield and a link http://tronixstuff.BANNED.com/2011/0 ... -io-ports/.
Schematic
Schematic
MCP23017SP2.jpg (88.23 KiB) Viewed 3062 times
Now, I've tried two methods of talking to the MCP... the first is the AdaFruit library (code attached, thx guys for providing). The code is overkill at this point, as I'm toggling all pins trying to get anything to work. The second one is taken from the second link above where only the Wire library is used (i can attach if needed, though i'd like to use the adafruit library).

I have swapped chips out to make sure that they are good... And gone back to originals, loaded a test sketch against the RBG Shield using the same chip and I2C which works fine... So i think my hardware is ok.

Anyone have any input as to what i'm missing? :?
Attachments
MCP23017SP2.txt
(1.54 KiB) Downloaded 338 times

jag911
 
Posts: 18
Joined: Tue Mar 06, 2012 11:59 am

Re: MCP23017 help

Post by jag911 »

Ok, so i figured out part and have a new problem to go along with it... ;)

So apparently the jumper cables and TinyBreadboard holes that go with the starter kit/prototype board aren't that great together. I am getting sketchy connectivity on some of the pins. After moving around the I2C pin pair jumpers on the breadboard it started up.

Now... this is true so long as it's powered by USB and *not* an external power source such as the 9v battery case or AC transformer that comes in the kit? Does this make sense to someone???? Any theories? a simple blink test works fine on any of the three forms of power (battery, wall, usb) but this project is finicky about only wanting to work when on USB power?

jag911
 
Posts: 18
Joined: Tue Mar 06, 2012 11:59 am

Re: MCP23017 help

Post by jag911 »


jag911
 
Posts: 18
Joined: Tue Mar 06, 2012 11:59 am

Re: MCP23017 help

Post by jag911 »

Playing with Fritzing to show the same circuit (i hope)... I guess i didn't set the resister values which are 4.7k (YelPurRed) for the two pull up on the I2C pins and a 1k (RedBlaBro) for the LED.
MCP23017_bb.jpg
MCP23017_bb.jpg (61.19 KiB) Viewed 3040 times

jag911
 
Posts: 18
Joined: Tue Mar 06, 2012 11:59 am

Re: MCP23017 help

Post by jag911 »

Not seeing much in the way of feedback guys... c'mon, certainly someone has *something* ;)

Playing more with this situation, just updating with more data in case anyone does feel brave enough to reply with theories. hehe

I'm now using a boarduino programmed/powered by an USBTinyISP. The circuit is roughly the same as before (especially with regards to communication between arduino and MCP23017 via I2C). Only I have altered the code and outputs a little more.

At this point there is a single LED on all outputs of the MCP23017. The video link shows me going from USB based power, over to DC via 9v battery pack, and over to AC transformer to 9v DC. Starts fairly stable on USB, get's a little crazy on 9v, and get's really crazy on AC, then returns back to somewhat stable again on USB. There are times that i am pressing the reset button to attempt to clean and start fresh, other times is me changing power source.

I have a hypothesis at this point, leading towards an generally unreliable and awkward communication path between MCU and IC via I2C.

I2C is basically (in my NB eyes anyway, plus i'm a network guy so it's easy for me to go here) a small network between the MCU and the IC. data exchange is synced by way of the SCL clock line, so that all parties on the bus are using the same clocking... data exchange itself occurs on the SDA line, which is a single wire shared by all devices on the network, a single broadcast domain if you will. Ethernet handles this by requiring a bit of CSMA/CD capability to ensure sent packets are not corrupted by shared access... and various high level protocols require two way communication to ensure data exchange is successful (tcp acking, if you will).

Only here the medium isn't so sophisticated, and/or i've read more than one article suggesting that maybe the arduino code doesn't participate fully in the ACK'ing process (reacting to ACK's from the IC).

It would seem to me that the various timings of startup, power being placed on the bus, and code activating on the arduino prior to or maybe after the IC is ready to accept I2C exchange, might be cause... and/or in other cases there is simply conflict on the wire causing corruption and the like.

This all leaves the MCU in various states. Slight charges holding pins high or low, only partial setup occuring at the time it's read, etc. And i believe in the end this all relates directly to what you see at glitchy here. I cannot speak why there seems to be a difference in the way that the USB, 9v battery, and wall wart trigger this response... but something tells me it has to do with the subtle difference in timing and amount of power provided during the connection.

To fix all of this and make it "stable"... it seems to me that the only resource available to me involves setting up some amount of delay during setup to allow for the MCU, IC, and Power all to settle... and an occasional re-initialization of the registers on the IC to ensure they are at the proper values.

Any brave souls out there willing to provide input???? ;)

http://www.youtube.com/watch?v=RmwQAxdj_V8

User avatar
philba
 
Posts: 387
Joined: Mon Dec 19, 2011 6:59 pm

Re: MCP23017 help

Post by philba »

well, you aren't going to encourage people to help with that line. My guess is few people have used the 23017. Also, you are describing a "gremlin" situation which could be almost anything.

An observation: USB power is likely to be pretty stable and clean. Wall Wart power, who knows. 9V should be stable. The latter 2 should feed through the onboard regulator (you are using Vin, right?), USB power doesn't. So, I'd look there.

jag911
 
Posts: 18
Joined: Tue Mar 06, 2012 11:59 am

Re: MCP23017 help

Post by jag911 »

Oh c'mon, it's all in good fun! I was hoping to feed the ego of someone much wiser than myself, encouraging them to take a moment to type up their thoughts... I did manage to elicit a response.. hehe

the wart in this case is the little unit that came in the adafruit starter kit. not sure if anyone has any input as to the quality of the device, i'm certain it's quite suitable for the job. I'll see if i can spend a little time watching the MM and see if it's behaving poorly (or as poorly as the MM might be able to see, since i have no scope handy). Still, it would seem to me that the gremlin exists in all three sources, just in varying degrees. So you may very well have a good point. This point leads me down a path of wondering how to smooth out the power better than the boarduino's LM7805 setup already does.

No, not using Vin... the MCP23017 datasheet, assuming i'm reading it correctly, would seem to desire some voltage in the range of 4.5v - 5.5v and a maximum current load into Vdd of 125ma. Seems like i might attract the magic smoke monster by powering the IC with Vin at 9v. The LM7805 (even without an attached heatsink) should be able to handle the minimal load of the IC and accessory LEDs?

As for the MCP23017... So again, i'll openly admit that i'm a bit of a NB hack at this stuff... I've played with z80 starter kits years ago, a pickit2 demo set for a quite a while, and now have been tempted to dabble in the world of the 'duino. I was hoping that due to the inclusion of this particular IC in Lady Ada's stockpile that it was a worthy choice, and one that many of her customers had chosen to suit their particular needs... and having seen it work on the Adafruit RBG LCD shield quite nicely (good work on that shield ada team!)... i figured i'd give it a go.

Have any suggestions as to another unit to provide similar function? (again, network guy) I'm drawn to the idea of chips communicating on a TWI saving precious MCU pins for other critical functions (like PWM'ing an RGB LED! j/k). My project, if you can call it that, is less a desperate need for the ultimate device so much as it is a meager attempt to feed my brain. So again I ask (attempting to be as polite as possible), please won't you be so kind as to take a moment out of your busy day to help by posting some ideas?

jag911
 
Posts: 18
Joined: Tue Mar 06, 2012 11:59 am

Re: MCP23017 help

Post by jag911 »

So someone suggested that i use a decoupling cap to see if it smoothed things out... it did not help any... :(

However, still suspecting that the transmission of the I2C instructions to the MCP23017 was getting corrupted somehow i decided to attempt to make a prototyping board that way the SCL/SDA lines where soldered and very short. The result is finally a stable design, on any kind of power source. See the working video here:

http://www.youtube.com/watch?v=gXZKNoIWF24

dreamgame
 
Posts: 1
Joined: Fri Apr 06, 2012 1:28 pm

Re: MCP23017 help

Post by dreamgame »

Don't you have the reset pin reversed?

I say this because the reset pin is overdashed. And this means reverse.

O = Normal operation 1 = reset

And you have the reset pin high all times.

I am only supposing, may be you can try, and give feedback.

jag911
 
Posts: 18
Joined: Tue Mar 06, 2012 11:59 am

Re: MCP23017 help

Post by jag911 »

Thanks dreamgame... I appreciate any and all assistance! I have much to learn... ;) as an example i don't know that i've heard anyone explain the dashed pin as an indicator of it's bias.

So I have made this mistake before, and am not discounting that I made it again... but this idea does make me curious.

if set always high and therefore reset, wouldn't it not operate rather than be glitchy?

i used ada's rgb lcd shield as an example, and i think the reset pin is tied high there
ada-rgb-shield.jpg
ada-rgb-shield.jpg (34.22 KiB) Viewed 2848 times
and from the datasheet i think i'm reading this to say high keeps it operational and the transition to low and high again initiates the reset... am i reading this wrong?
datasheet.jpg
datasheet.jpg (31.33 KiB) Viewed 2848 times
Thanks for the help!

Locked
Please be positive and constructive with your questions and comments.

Return to “General Project help”