Pinkompatible Alternative zum DS1307?

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

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

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

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.

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.

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.

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.