i2c i/o exp. mcp23016 "spinnt"

[Alex (Gast)]

Hallo Forum,

ich habe in einer Schaltung u.a. am i2c-Bus den MCP23016 I/O-Expander 
von Microchip. Ich verwende die i2c-Routinen von der Procyon AVRlib, hat 
im Zusammenspiel mit diversen anderen i2c-Bauteilen nie Probleme 
gemacht.

Nur in meinem aktuellen Projekt "spinnt" der MCP23016 irgendwie, mein 
Eindruck ist das sich irgendwie die Kommunikation "verhakt" und der 
Atmega128 kein ACK mehr bekommt. Er bleibt dann stehen. Ich hab dann mal 
den Watchdog reingemacht um zu sehen was weiter passiert, nach diversen 
Resets schafft er es dann mal... Anscheinend werden dann auch 
willkürlich irgendwelche Bits gesetzt weil der Zeiger im MCP dann 
irgendwohin zeigt.

Das Programm läuft auch manchmal tagelang ohne Probleme, sprich ich kann 
den Fehler leider nicht reproduzieren.

Gibt es irgendwelche bekannten Fallsticke bei dem Ding ? Ich hab gesehen 
das Microchip den inzwischen auch abgekündigt hat. Kennt jemand den 
Grund ? Der MCP braucht auch einen eigenen RC-Oszillator ist das in 
Wirklichkeit vielleicht ein PIC (Pinout könnte passen...) ausserdem 
"hält" der MCP den Takt fest wenn er arbeitet, wenn ich das im 
Datenblatt richtig verstanden habe - ist das so in der i2c-spec nicht 
vorgesehen, bzw. eher unüblich ?

Bus sieht sauber aus, Pullup ist 4K7 an SCL und 4K7 an SDA, alle 
Bauteile sind über 270Ohm am Bus, der MCP ist mit 4,7µF Tant. 
abgeblockt. Bus läuft mit 100kHz.

Bin kurz davor den MCP23016 durch einen PCA9555 zu ersetzen (weil ich 
den zufälligerweise da habe und er vom Erfinder des i2c stammt :). Ich 
habe hier: http://tech.dir.groups.yahoo.com/group/lpc2000/message/8827 
was gefunden, kann das vielleicht jemand bestätigen ?


Danke für eure Hilfe,

Alex.

[Bernd R. (Firma: Promaxx.net) (bigwumpus)]

Also,
ich denke der aktuelle Baustein wird der MCP23017 sein.

Am I2C-Bus ist es dem Slave möglich, den Takt zu verzögern, wenn vom 
Slave gelesen wird. Das muß der Master aber wissen und berücksichtigen.

[Alex (Gast)]

Nachtrag, ich habe den MCP23016 durch den PCA9555 ersetzt, nochmal das 
Datenblatt studiert und den Support von Microchip befragt weil ich mir 
da nicht sicher war:

"Nach der Übertragung von einem Byte muß eine Wartezeit von 12µs 
eingehalten werden, bevor das nächste Byte gesendet werden kann. 
Abgesehen davon können die gleichen Bibliotheken wie auch für andere 
I2C-Bausteine verwendet werden."

Das steht auch im Datenblatt, ich dachte aber das würde sich durch das 
ACK vom Slave sowieso ergeben. 8-)

Was ich merkwürdig finde:

-12µs Wartezeit finde ich im vergleich zum I2C-Timing relativ lang
-Pinout vom MCP23016 passt z.B. gut zum PIC16F7X
-Der MCP23016 braucht einen externen Takt (RC)

...ich würde sagen Microchip hat hier einen I/O-Expander in Software auf 
einem PIC realisiert.

An den PCA9555 hab ich testweise mal ca. 11h lang per rand() erzeugte 
Schaltkombinationen gesendet und den PIN Status wieder eingelesen und 
dann verglichen. Keine Probleme, ich hoffe also das ich das Problem 
gelöst habe, vielleicht hilft es ja jemandem weiter...

ciao,
Alex.

[Bernd R. (Firma: Promaxx.net) (bigwumpus)]

In der Tat sieht das sehr nach einem Software-Projekt aus.

Der ...17 ist da wohl etwas besser.

[Peter D. (peda)]

Alex schrieb:
> ...ich würde sagen Microchip hat hier einen I/O-Expander in Software auf
> einem PIC realisiert.

Das scheint sicher.
Das I2C der PICs ist nämlich nicht so durchdacht, wie bei NXP oder 
Atmel.
D.h. der PIC als Slave kann keine automatische Synchronisation über die 
SCL-Leitung.


Peter