Hallo zusammen, ich habe mir das Beispiel aus der Codesammlung für den PCF8574 von hier http://www.mikrocontroller.net/articles/Port-Expander_PCF8574 runtergeladen. Habe es auf einem ATmega128 laufen und es scheint alles zu funktionieren - nur wenn beim Auslesen von P7 eine "0" steht (Pin 12 also auf Masse) friert der Controller ein. Ich habe alles genau so wie im Beispiel gemacht. Ich verstehe nicht, warum das Programm beim Auslesen des P7 abstürtzt, obwohl alle anderen Werte korrekt ausgelesen und angezeigt werden. Ich habe 4 ICs angeschlossen und bei allen das gleiche Phänomen, Hardware ist 100% ok. Irgendwo ist der Fehler beim 2. Durchlauf, weil das erste mal wird die "0" auf P7 richtig gelesen und auch angezeigt, dann hängt der Controller. Hat jemand eine Idee? Vielen Dank für Eure Antworten. Habe schon mit Bitrate 10 und 20 probiert, kein Unterschied.
Versuch mal
1 | void pcf8574_send_stop (void) |
2 | {
|
3 | /*writing a one to TWINT clears it, TWSTO=Stop, TWEN=TWI-enable*/
|
4 | TWCR = (1<<TWINT) | (1<<TWSTO) | (1<<TWEN); |
5 | |
6 | /*wait, until stop condition has been sent*/
|
7 | while (!(TWCR & (1<<TWINT))); |
8 | }
|
Im Beispiel ist ja genügend Pause nach dem Stop. bei dir warscheinlich nicht.
Hallo. Ich habe nun dasselbe Problem, hab auch denselben quelltext als basis genommen. alle anderen bits funktionieren, nur das 7. eben nicht - wenn das low wird, friert die cpu (atmega32) ein. wenn ich die stop-funktion wie vorgeschlagen ändere, bleibt der rechner schon beim ersten aufruf in der stop-fkt hängen. hat vielleicht jemand eine lösung oder idee? pcf8574 werden ja nun eigentlich nich so selten eingesetzt..
Nunja, es sieht so aus, als würde, sobald diese null gesendet wird statt der eins, das komplette timing des i2c busses durcheinander geraten. der rechner schläft dann ein wenn er auf das nächste ack wartet. wenn man die abfrage weglässt, läuft er zwar weiter, empfängt aber auch keine neuen werte mehr. kann auch sein dass das problem an der i2c-ansteuerung liegt, ich könnte natürlich noch andere i2c implementierungen durchprobieren und so. aber ich denke ich werde jetzt einfach den pin nicht benutzen. zum glück habe ich noch einen pin direkt am avr frei, jetzt geht eben nur ein unschönes extrakabel durchs gehäuse. so gehts auf jeden fall und ich spare mir zeit.. interessant ist das problem dennoch, ich habe schon gelesen, dass pic-benutzer dasselbe problem hatten... viele grüße olli
Hallo miteinander, mit dem PCF8574 habe ich nie Probleme gehabt. Aber die im Schaltplan angegebenen Pullups an SDA/SCL von 10k scheinen mir etwas groß. Die Spezifikation habe ich jetzt nicht zur Hand, aber ich verwende in der Regel 2.2 k. Bei längeren Kabeln (und entsprechend größeren Kabelkapazitäten) und zu hohen Pullups "runden" die Flanken aus - und dann steht der Bus. Hilfreich bei Testen ist übrigens, sich 2mA LEDs mit 1.5 k Vorwiderstand an den Bus zu klemmen (nach VCC). Dann kann man an SCL (wenns Dauerlicht gibt) erkennen, dass irgendjemand den Bus dauerhaft auf Low zieht - was nicht sein sollte. Michael S.
Hallo, Ich glaube das Problem liegt hier in der Funktion pcf8574_read_byte. Da immer nur ein Byte gelesen wird, sollte ohne ACK gearbeitet werden. Also:
1 | TWCR = (1<<TWINT) | (1<<TWEN); |
Frank.
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.