Hallo Kollegen, sitze schon einige Zeit an der Ansteuerung des PCF8583 von Philips, leider ohne Erfolg. Die Hardware scheint zu laufen, denn ich bekomme am Interrupt Pin den Sekundentakt. Wenn ich den Chip ansteuere, habe ich auch Signale auf SCL und SDA, kann aber nichts Vernünftiges auslesen. Mein Programm (Assembler) habe ich angehängt. Eigenartig ist, dass ich beim Schreiben keine Fehlermeldungen bekomme und beim Lesen nur dann, wenn ich am Ende des Lesevorgangs kein ACK zurückgebe. Lese ich immer mit ACK, dann bekomme ich zumindest eine Anzeige mit 5 x 0. Dann allerdings kann ich den PCF nicht ein zweites Mal abfragen. Nach Rücksprung auf -weiter:- kommt die Fehlermeldung '8', also kein ACK der Uhr nach Anruf der Adresse. Ich habe versucht, den Bus langsam zu machen (XTAL=24), bringt aber nichts. Entweder bin ich blockiert oder aber was anderes ist unklar. Habe schon mehrere I2C Routinen aus dem Netz ausprobiert, aber stets ein ähnliches Problem. Auch meine Routinen sind nicht wirklich meine sondern aus einem Netzbeitrag entstanden. Ich habe nur mit den Zeiten etwas rumgespielt, um besser oszillographieren zu können. Die Anzeige-Routine (LCD_Anzeige.inc) läuft ebenso wie die Timing-Routine (Time_22.inc) Kann jemand helfen? Gruß frewer
Wenn Du eine helfende Hand suchst ... Du findest sie am Ende Deines rechten Arms. Besorge Dir einen Logicanalyzer und schaue Dir eine komplette I2C-Transaktion mit Start- und Stop-Condition an. Dann wirst Du ja sehen, was Du falsch gemacht hast. Die üblichen Pull-Ups an SCL und SDA hast Du? Du weißt auch, dass I2C Open-Collector bzw Open-Drain Ausgänge fordert? Schaltplan? fchk
Thanks Frank für die Logik. Also einen Logikanalizer habe ich nicht, aber einen guten Oszi mit dem ich - zusammen mit einem EXT Trigger, den ich mit Port LED erzeuge - mir eine Session ansehen kann. Das Problem ist nur, dass ich sehr genau die Abfolge sehe, nur einen Fehler kann ich nicht erkennen. Die Ausnahme ist halt, dass vorm Lesen bei der Adressierung der PCF manchmal das ACK nicht gibt und was noch komischer ist, dass, wenn wie im Datenblatt beschrieben der Master am Ende eines Lesezyklus kein ACK gibt, sofort eine Fehlermeldung folgt. Der Schaltplan ist identisch mit dem Datenblatt also Pull-up Widerstände an SCL, SDA und Interrupt (je 3,9K), Uhrenquarz zwischen Pin 1 und 2 mit TrimmKapazität zwischen 1 und Vcc. Der Ausgang des AT89S51 an Port0 ist mit zusätzlich 10K pro Ausgang belastet. Interessant ist weiter, dass ich gleich 2 komplette PCF Uhren aufgebaut habe und beide verhalren sich gleich. Nun, werde halt noch etwas weiter experimentieren. Vielleicht finde ich ja doch noch die Erleuchtung. Jedenfalls merci vielmals frewer
Hänge doch mal etwas anderes an den I2C, z.B. einen PCF8574. Da solltest Du den Erfolg an den Ausgängen gleich sehen können. Damit kannst Du sehr einfach prüfen, ob Du zumindest richtig auf den I2C schreiben kannst. fchk
Hi Frank, merci, aber genau das ist ja das Verrückte. Ich habe ein Board mit dem PCF8574A (Portexpander), da läuft alles perfekt. Dann habe ich ein gleiches Board mit dem PCF8591 (A/D-Wandler). Das läuft nicht, obwohl ich die gleichen Routinen (übrigens von Dr Rathlev Uni Kiel) benutze. Dann habe ich mal mit dem Timing variiert, jedoch ohne Erfolg auch beim A/D Wandler. Dagegen hat der Portexpander mit dem Timing überhaupt kein Problem. Dann habe ich den AD-Wandler ausgetauscht (steckbar). Ergebnis: das Gleiche wie vorher. Und die Uhrenbausteine, na ja, wie beschrieben. Irgendwie gibt es da ein problem mit dem ACK, denn es ist komisch, dass beim Lesen der Uhr ich immer ein ACK geben muss - auch beim letzten Wert - sonst bekomme ich eine Fehlermeldung. Dann habe ich noch eine Frage zum Datenblatt des PCF8583. Da sind in den Bildern Fig 18/19 zwei Lesemethoden. Fig 18 ist klar, aber Fig 19 verstehe ich überhaupt nicht ???? Da gibt trotz Lesemodus der SLAVE stets ein ACK. mfG frewer
HolgerT schrieb: > Pin A0 des PCF8583 auf Low gelegt? Sonst Slave-Adresse 0xA1 verwenden. Du meinst 0xA2?
www.nxp.com/documents/data_sheet/PCF8583.pdf Auf Seite 2 (Fig.1) ist der Anschluß mit "A0" bezeichnet.
... aahh Ja! Natürlich, Adresse 0xA2 für Schreiben, bei Pin A0=high. (mann-o-mann wie kann man ein Pin "A0" nennen, wenn es Bit-1 einer Adresse beeinflusst?) Nochmal (auch für mich) zum verifizieren: A0=low: 0xA0 schreiben / 0xA1 lesen A0=high: 0xA2 schreiben / 0xA3 lesen
frewer schrieb: > Hi Frank, > merci, aber genau das ist ja das Verrückte. Ich habe ein Board mit dem > PCF8574A (Portexpander), da läuft alles perfekt. Dann habe ich ein > gleiches Board mit dem PCF8591 (A/D-Wandler). Das läuft nicht, obwohl > ich die gleichen Routinen (übrigens von Dr Rathlev Uni Kiel) benutze. Schreibst Du nur auf den 8574A, oder liest Du auch? Es kann ja sein, dass das Schreiben funktioniert, aber das Lesen (bzw die RepeatStart Condition) nicht funktioniert. > Dann habe ich noch eine Frage zum Datenblatt des PCF8583. Da sind in den > Bildern Fig 18/19 zwei Lesemethoden. Fig 18 ist klar, aber Fig 19 > verstehe ich überhaupt nicht ???? Da gibt trotz Lesemodus der SLAVE > stets ein ACK. Wenn der Master ein Byte schreibt, muss der Slave ein ACK senden, damit der Master das nächste Byte schreiben kann. Sendet der Slave ein NACK, muss der Master eine Stop Condition senden, und der Transfer ist zuende. Wenn der Master ein Byte empfängt, muss er dem Slave ein ACK senden, damit der das nächste Byte sendet, ansonsten ein NACK und eine Stop Condition. Bei einem Richtungswechsel der Datenflussrichtung schickt der Master keine Stop Condition, nachdem er die Adresse gesendet hat, sondern eine neue Start Condition (RepeatStart). Prüfe, ob Dein Code das immer so macht. fchk
Hi Holger, Du hast mir einen ganz schönen Schreck eigejagt, aber nach Überprüfung stelle ich fest, dass A0 mit VSS auf GND liegt. Also ist die Adresse UADr equ 0A0h für Schreiben ok. Beim Lesen mache ich ein < mov a,#UADr >, dann ein < or a,#1 > was natürlich 0A1h (0xA1) ergibt. Also daran kann es wohl nicht liegen. trotzdem herzlichen Dank, jeder ausgemerzte fehler hilft natürlich Gruß frewer
Hallo Frank, also ich lese nur vom Portextender PCF8574A (aber da ist ja ein Schreiben mit dabei) und das Lesen ist völlig ok. Allerdings habe ich den Startbefehl so gestaltet, dass ich zuerst ein STOP ausgebe und prüfe, ob SCL und SDA high sind (ist der Bus frei?). Dann gebe ich die START-Kondition. Das werde ich nachmal mal ändern. Danke für die Mühe und mfG frewer
Das kann auch nicht der Fehler sein, denn der Port-Expander folgt der gleichen Adressierungslogik wie die RTC. Bei i2c gibt es vereinfacht nur 7-Bit Adressen, die per Definition von NXP, eins nach links geshiftet werden. Danach wird rechts ein Bit für Lesen/Schreiben angehängt.
Ich sehe zwei interessante Sachen: 1. Der Portexpander hat kein Adressregister 2. Dein Code kann nicht mit den wiederholten START-Folgen funzen. Was ist denn der Unterschied zwischen 'Startbefehl' und 'START' bei dir? Auf STOP darf STOP folgen, auf START vermutlich nicht sofort ein weiterer START. Jedenfalls bräuchte man es nicht (Macht keinen Sinn) und ich habe es nie gemacht.
Hallo, ich melde mich nochmal zum Thema: Also nach mühsamer Suche mit dem Oszillographen habe ich festgestellt, dass offenbar mein I2C-Bus zu schnell war. Ich lag zwar unter 100kHz, was nach Datenblatt ok wäre, doch bekam ich stets Fehlermeldungen an unterschiedlichen Stellen (mal beim Schreiben, mal beim Lesen). Ich bin jetzt weiter heruntergegangen mit der Clockfrequenz (ca 45kHz) und jetzt läuft sie, die Uhr. Weiter habe ich festgestellt, dass der Baustein sehr, sehr empfindlich auf Verunreinigungen der Betriebsspannung reagiert. Man muß da wirklich sauber abblocken sonst geht nichts. mfG frewer
Bei mir lief der Baustein ohne Probleme. So wie man es von NXP generell erwartet. Vielleicht hast du doch noch ein Problem drin, eventuell hardwareseitig. Bei i2c muß man an einer Stelle im Protokoll 4,7us warten. Hast du das drin?
Hallo Abdul, bin schon mal froh, dass die Uhr überhaupt vernünftig läuft. Ich hatte, wie gesagt, das Timing des Philips (NXP) Datasheet zum PCF8583 exakt eingehalten, doch ohne Erfolg. Jetzt habe ich die Zeiten verlängert (statt 4,7µsec auf ca 10µsec) und siehe da, jetzt geht die Abfrage. Natürlich werde ich jetzt versuchen, die Übertragung zu beschleunigen (interessehalber) aber zunächst will ich die Uhr für meine Heizungssteuerung preparieren, um dort die Uhrzeit aus dem programm zu nehmen. Als nächste Variante will ich dann versuchen, auch die Sommer-/Winterzeit - Umschaltung mit dem Bauatein zu machen. Mal sehen, ob das alles klappt. Übrigens kannst Du mir nicht mal genau sagen, wo Du die 4,7µsec eingebaut hast und mit welcher Frequenz Du überhaupt arbeitest? mfG frewer
Ist lange her, so ca. 1993. Da machte ich Bit-Banging. Die von mir geschriebenen Sources habe ich nicht mehr und die gehören mir auch nicht. Tut mir leid. Momentan benutze ich immer ne fertige Lib des MCU-Herstellers und muß also nix mehr aufbrödeln. PCF8583 habe ich seitdem auch nicht mehr angesprochen. Wenn RTC, dann läuft die direkt auf dem Controller. Bei i2c sieht es einfach schlecht aus, wenn mal was nicht geht.
Das mit den 4.7us erscheint mir sehr seltsam. Der PCF8583 kann nur 100kHz, da sind immer >= 10us angesagt.
Na Hannes, mit den 4,7µsec, das stimmt schon, wenn man die Impulsbreite nimmt (wie im Datenblatt auch angegeben). Das errechnet sich zu ca 100kHz, wenn man 2 Impulsbreiten nimmt - wie für die Frequenz nötig -. Mittlerweile habe ich mit 5µsec Impulsbreite eine funktionierende I2C Routine, die mit allen meinen Chips zusammenarbeitet (Expander, AD-Wandler, Uhr). mfG frewer
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.