Forum: Compiler & IDEs PCF8574 Codebeispiel klappt nicht


von Haraldo (Gast)


Lesenswert?

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.

von Werner B. (werner-b)


Lesenswert?

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.

von Oliver Simmank (Gast)


Lesenswert?

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..

von Oliver Simank (Gast)


Lesenswert?

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

von Michael S. (Gast)


Lesenswert?

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.

von Frank J. (frajo)


Lesenswert?

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
Noch kein Account? Hier anmelden.