PCF8566 am I²C Bus

Hallo, ich habe einen PCF8566 am I²C Bus und bekomme ihn einfach nicht zum Laufen. Ein PIC 18F442 steuert den Bus, 2 PCF 5874 arbeiten korrekt am Bus. Der 8566 ist meines Erachtens richtig angeschlossen; A0, A1,A2,SA0, OSC an GND Ich spreche den Baustein lt. Datenblatt an. Adr. 0x7c Dev. select 0xe0, mode

0xce für 2BP, danach habe ich die unterschiedlichsten Möglichkeiten ausprobiert (data pointer, bank select, daten) letztes Kommando C=0 beachtet, aber alle Ausgänge bleiben auf high (wie nach reset) CLK an 4 ist messbar. Wer kann mir helfen, bin mit meinem Latein am Ende.

Gruß Klaus

Reply to
Klaus Bernhardt
Loading thread data ...

Klaus Bernhardt schrieb:

Schonmal nachgemessen, ob das Teil überhaupt ein ACK gibt (nach dem ersten Byte mit der Slave-Adresse, sowie nach dem Befehlscode)? Dann im nächsten Schritt: kommt das ACK auch nach dem ersten Datenbyte?

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß
Reply to
Tilmann Reh

Muesste die Slave Adresse nicht 0x3e, statt 0x7c sein?

Gruss Klaus

Reply to
Klaus Bahner

"Tilmann Reh" schrieb im Newsbeitrag news:d1ro9u$gji$ snipped-for-privacy@online.de...

gemessen nicht, aber der Master fragt das ACK ab und würde sich aufhängen bzw resetten ohne ACK. Aber ich habe festgestellt, daß die 5874 bei falscher Adresse zwar nicht angesprochen werden aber trotzdem ein ACK abgeben, so kann ich nicht feststellen ob der 8566 angesprochen wird, wahrscheinlich gibt er auch ein ACK bei falscher Adresse ab. Die Adresse 0x7c stimmt lt. Datenblatt und anderen Quellen. Gruß Klaus

Reply to
Klaus Bernhardt

Klaus Bernhardt schrieb:

Ich würde es trotzdem messen. Und zwar zum Test ohne die übrigen I2C-Peripherie am Bus.

Das würde der I2C-Spezifikation widersprechen, und ich habe dergleichen auch noch nicht beobachtet. Möglicherweise hast Du das ACK eines anderen Teilnehmers gesehen?

Mag sein, aber was Klaus Bahner vermutlich meinte: wir wissen nicht, wie dem PIC die Adresse mitgeteilt werden muß. Das 7Ch enthält ja im untersten Bit das R/W-Bit; die eigentliche *Adresse* (also nur für die Adressierung verwendeten 7 Bit) ist eben nicht 7Ch, sondern 3Eh. Das für einen Schreibzugriff zu übertragende *Byte* hat dann den Wert 7Ch.

Ich würde mal sagen, Du solltest das Ganze einmal mit einem Speicherskop nachmessen. Und zwar den ganzen Zugriff, und nur mit dem einen 8566 als Slave. Dann sieht man sehr schnell, was schiefläuft.

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß
Reply to
Tilmann Reh

Das darf eigendlich nicht sein. Prüf mal ob dein Programm wirklich ordentlich arbeitet und nicht eventuell das letzte Datenbit stehenlässt. Ausserdem darfst du kein ack beim letzten vom 8574 gelesenen byte senden weil sonst STOP nicht erkannt wird.

--
MFG Gernot
Reply to
Gernot Fink

"Tilmann Reh" schrieb im Newsbeitrag news:d1s2mb$t9n$ snipped-for-privacy@online.de...

erstmal Danke für die Tips, sie haben mich auf einen Programmierfehler aufmerksam gemacht (habe nicht ACK sondern ein falsches bit abgefragt) natürlich kommt ACK nur bei richtiger Slave Adresse. (Gegenprobe: falsche Adresse-kein ACK) So auch beim 8566, er gibt ein ACK auch bei den weiteren Kommandos u. Daten. Trotz allem muß wohl irgend etwas fehlen, damit das Teil eine Regung zeigt. Gruß Klaus

Reply to
Klaus Bernhardt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.