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.
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.
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.
In der Tat sieht das sehr nach einem Software-Projekt aus. Der ...17 ist da wohl etwas besser.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.