DS1307 ist ein I2C-RTC-Chip, aber mit max. 100 kHz Busfrequenz schon etwas antiquiert. Außerdem gilt er als anfällig für Störungen auf dem Bus, was ich auch bestätigen kann... Gibt's eventuell eine pinkompatible Alternative (SO8)?
Lena schrieb: > DS1307 ist ein I2C-RTC-Chip, aber mit max. 100 kHz Busfrequenz > schon > etwas antiquiert. Ob antiquiert oder nicht, 100 kHz sind immer noch Standard. Den Fast-Mode mit 400 kHz oder mehr können wesentlich weniger Devices als den Standard-Mode mit 100 kHz. > Außerdem gilt er als anfällig für Störungen auf dem > Bus, was ich auch bestätigen kann... Das halte ich für ein Gerücht! :) - Der DS1307 spinnt nur rum, wenn man sich partout nicht an die Layout-Vorgaben aus dem Datenblatt hält! (keine Leiterzüge unter dem Oszillator, Massefläche unter Quarz und Guard-Ring um diese Massefläche und schon funktioniert das Teil wie es soll. - Stromsparen kann manchmal auch etwas aufwändig sein!? > Gibt's eventuell eine pinkompatible Alternative (SO8)? Schon einmal bei Maxim auf der Webseite nachgeschaut? - Die haben unglaublich viele RTCs. Viele Grüße! Sven
Also, es gibt mit dem DS1307 definitiv deutlich mehr Übertragungsfehler als mit anderen I2C-Devices, die am gleichen Bus hängen. Oft muss man mehrfach hintereinander lesen, um sicher zu sein, dass die Uhrzeit stimmt (und es z.B. nicht -66:87:12 Uhr spät ist...). Zugegeben, der Bus ist grenzwertig, was die Länge angeht, aber diese Probleme existieren mit Sensoren am gleichen Bus überhaupt nicht.
Wie ist denn Dein Hardwareaufbau? Blockkondensatoren vorhanden? Größe Pullup? Wie lang ist der Bus?
Lena schrieb: > Also, es gibt mit dem DS1307 definitiv deutlich mehr Übertragungsfehler > als mit anderen I2C-Devices, die am gleichen Bus hängen. Das muß aber jemand vergessen haben, meinen DS1307 zu sagen, denn die arbeiten korrekt. Wichtig ist allerdings, die Zeit als Block zu lesen, damit nicht die Bytes zwischendrin wechseln und natürlich das NACK vor dem letzen Byte.
Also bei mir gibt es auch keine Probleme, da hängt sogar ein EEPROM am Bus. Immer ganze Datenblöcke auslesen ist wichtig.
Da wird wohl wieder I²C sonst wie lang verlängert worden sein. I²C bedeutet Inter-IC-Communication, das heißt auf der gleichen Platine, maximal noch innerhalb des gleichen Geräts und selbst hier sollte man schon I²C Puffer/Repeater einsetzen. Das ist mal wieder ein klarer Fall von Anwendungsfehler und ist nicht dem DS1307 anzulasten! Der TE wird ein Problem mit der Flankensteilheit auf dem SDA-Signal haben, was durch viel zu hohe Buskapazitäten und -widerstände bedingt ist. Auch mit einer anderen RTC wird es vermutlich nicht wirklich besser laufen, denn die Dinger sind auf Strom sparen ausgelegt. Der OpenDrain, der den Bus treibt ist vermutlich nicht niederohmig genug, um unter diesen ungünstigen Bedingungen noch saubere Flanken zu produzieren. - Ich prophezeie mal, dass das mit einer anderen RTC nicht wirklich besser aussieht. Ich beackere hier einen I²C-Bus mit 100 kHz an dem eine DS1307 hängt, zwei PCF8574, die zyklisch gelesen (Taster) und geschrieben werden und ein weiterer PCF8574, an dem ein HD44780-Display hängt. - Auf dem Bus ist ziemlich High-Life und der läuft auf Anschlag, aber trotzdem sind die Pakete der RTC korrekt und sie lässt sich auch nicht aus dem Tritt bringen. Viele Grüße! Sven
:
Bearbeitet durch User
Mehrere Devices an einem I2C Bus ? Interessant. Das Timing und die Spannungen wurden per Oszilloskop ueberprueft ? 100kHz zu langsam ? Eine Uhr hat nicht soviel zu senden dass die Geschwindikeit wesentlich waere. Ich steuere so eine Uhr mit eigenen Pins an. Im Bitbang Modus per Software. Die Abfrage erfolt extrem selten, wenn der Quarz zuviel Fehler machen wuerde, also zB einmal in der Stunde oder einmal Tag oder so.
Peter D. schrieb: > natürlich das NACK vor dem letzen Byte. sollte bestimmt nach dem letzten Byte heissen. Damit hab ich mir auch schon die Karten gelegt. Es gibt einige Serien von ICs (insb EEPROMS), die den Bus blockieren(Zummindest bis zur übernächsten Stop-Bedingung), wenn das letzte Byte mit ACK gelesen wurde. Sie sind dann wohl der Meinung, immernoch Daten ausgeben zu müssen. mfG
R. M. schrieb: > Damit hab ich mir auch schon die Karten gelegt. Es gibt einige Serien > von ICs (insb EEPROMS), die den Bus blockieren(Zummindest bis zur > übernächsten Stop-Bedingung), wenn das letzte Byte mit ACK gelesen > wurde. Sie sind dann wohl der Meinung, immernoch Daten ausgeben zu > müssen. Das ist ein gewolltes Verhalten, wenn der EEPROM Daten schreibt und nennt sich NACK-Polling. Man liest halt einfach so lange vom EEPROM weiter bis dieser wieder ein ACK sendet, was signalisiert, dass der Schreibvorgang abgeschlossen ist und die nächste Page gesendet werden kann. Generell sollte man I²C-Transfers immer so realisieren, dass der Master, nachdem er die gewünschte Anzahl Bytes empfangen hat, eine STOP-Condition oder eine RSTART-Condition (und weitere Daten) auf den Bus sendet. Ansonsten gilt der Transfer als nicht abgeschlossen. Mir sind da noch keine "komischen" EEPROMs über den Weg gelaufen, die meinten es anders machen zu müssen!? Viele Grüße! Sven
Nein, ich meinte die Gegenrichtung: nachdem der Master die gewünschte Adresse gesendet hat, wiederholter start, und seine Bytes gelesen hat (die er ja selbst, bis auf das Letzte mit ACK quittieren muss). Hier hatte ich auch das letzte Byte mit ACK gelesen und dann STOP gegeben. Danach war der nächste Transfer (in meinem Falle ebenfalls ein DS1307) gestört. mfG + sorry
Interessant... Kannst Du Dich vielleicht erinnern, was das für ein EEPROM war? - Würde ich mir gerne mal anschauen. Um mal zum Thema zurück zu kommen: Wir brauchen ein paar mehr Infos vom TE. Ohne Schaltplan und Angabe zur Buslänge kommen wir hier nicht weiter! Ich habe so die Befürchtung, dass die RTC wohl im Gerät verbaut ist, aber irgend ein Temperatursensor mit 20 m Kabel da dran hängt... Viele Grüße! Sven
R. M. schrieb: > sollte bestimmt nach dem letzten Byte heissen. Ne, vor ist schon richtig. Der Master taktet immer alle 9 Bits am Stück, d.h. danach NACK setzen ist zu spät. Ein gern gemachter Fehler.
Sorry, mal an dieser Stelle den Thread gekapert. Wegen des wichtigen NACKs... Beim AVR funktioniert es ja so: Für das Lesen setzt man _BV(TWEN) | _BV(TWINT) | _BV(TWEA) in TWCR, bzw. ohne TWEA im Falle des letzten Bytes (NACK). Dann wartet man auf das Bit TWINT in TWCR. Nun sollte man ja einer Endlosschleife vorbeugen und eine Art Timeout in der Warteschleife haben. Könnte ja auch sein, dass es einen Übertragungsfehler gibt. Wie geht man dann korrekterweise vor? Ich mache es bisher immer so, dass ich ein Stop sende, wenn die Schleife in den Timeout läuft. Dann wird ggf. neu probiert (von Start an). Klappt eigentlich auch. Aber wie ich hier lese, sollte man ja beachten, dass das letzte NACK gesendet wird. Was im Fehlerfall ja so nicht passiert. Was tun? Ideen? Versteht ihr, was ich meine?
Peter D. schrieb: > R. M. schrieb: >> sollte bestimmt nach dem letzten Byte heissen. > > Ne, vor ist schon richtig. Der Master taktet immer alle 9 Bits am Stück, > d.h. danach NACK setzen ist zu spät. Ein gern gemachter Fehler. Nein, nach dem Byte. Vor dem Byte geht doch gar nicht. Der Master taktet den Bus, soweit richtig. Er taktet für jedes Byte 9 mal. Lesen: bei den ersten 8 liest der Master das eigentliche Byte, beim letzten Takt gibt er ACK oder NACK. Schreiben: bei den ersten 8 schreibt der Master das eigentliche Byte, beim letzten Takt liest er das ACK oder NACK das der Slave gibt. Wenn der Master 3 Byte lesen will dann muss er die ersten zwei Byte mit ACK quittieren (sprich beim neunten Takt SDA auf Low ziehen) und beim letzten Byte MUSS er mit NACK quittieren (sprich: beim neunten Takt lässt er die SDA-Leitung in Ruhe (high), dann weiß der Slave daß die Übertragung zuende ist und kann internen Kram aufräumen). Danach gibt der Master ein STOP. Wenn Du das NACK beim letzten Byte nicht durchführst kommen viele Slaves aus dem Tritt. Wenn es trotzdem geht ist es pures Glück daß der Slave intern so simpel aufgebaut ist daß er das NACK aus irgendwelchen Gründen nicht braucht und nicht auswertet.
:
Bearbeitet durch User
Na Lena, wie sieht denn nun der Hardwareaufbau aus? Ich denke, ihr ist klar geworden, dass ihre Schaltung das Problem ist und nicht die DS1307 RTC. Viele Grüße! Sven
Bernd K. schrieb: > Lesen: bei den ersten 8 liest der Master das eigentliche Byte, beim > letzten Takt gibt er ACK oder NACK. Aber das muß man dem Master eben vor dem Lesen des letzen Bytes sagen. Hinterher ist zu spät, da hat er nämlich das ACK schon gesendet.
Peter D. schrieb: > Aber das muß man dem Master eben vor dem Lesen des letzen Bytes sagen. Ja, das ist wohl wahr. Dann haben wir aneinander vorbeigeredet.
Das heißt? Nach einer fehlgeschlagenen Übertragung (Timeout) sollte man nochmal ein Start senden, dann Read mit Nack, Stop?? Um sicher zu sein, dass der Slave wieder in einem definierten Zustand ist?
Ich will ja nicht meckern, aber könntet ihr das ACK/NACK-Problem bitte in einem eigenen Thread ausdiskutieren? Ich warte noch auf Rückantwort und dass es noch mit dem eigentlichen Thema weitergeht. Das Kapern eines fremden Threads gehört eugentlich nicht zum guten Ton! Vielen Dank! Sven
Svenl schrieb: > Ich will ja nicht meckern, aber könntet ihr das ACK/NACK-Problem bitte > in einem eigenen Thread ausdiskutieren? > > Ich warte noch auf Rückantwort Wenn man in einem i2c-Problem-Thread über gängige i2c-Probleme und Fehler diskutiert während man wartet bis OP die angefragten Informationen zusammengestellt hat dann hat das nichts mit Kapern des Threads zu tun.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.