Atmega328p und DS1307

[Jonas N. (medustv)]

Hallo, ich versuche nun schon seit 2 Wochen aus dem DS1307 vernünftige 
Werte zu bekommen. Im Anhang befindet sich einmal das gesamte 
Projekt(Den Code selbst hier rein zu schicken ergibt keinen Sinn, da er 
auf mehrere Dateien verteilt ist). Der Atmega328p läuft mit 8MHz über 
den internen Quarz (falls das für euch wichtig ist). An der Schaltung 
liegt es nicht, diese habe ich bereits mehrfach geprüft und habe sie 
auch von dritten prüfen lassen. Hängen tut der Code in der

i2c_start_wait()

 (twimaster.c) wenn ich versuche die Werte auszulesen. Hängen genau tut 
der Code genau an dieser Stelle

while(TWCR & (1<<TWSTO));

 an der gewartet werden soll bis die Stoppbedingung durch ist und der 
Bus wieder frei.

[Wastl (hartundweichware)]

Und was wäre deine Fragestellung?

Einfach mal ein Problem in den Raum stellen und drauf warten
dass schon was passieren wird?

[Jonas N. (medustv)]

Ich dachte jemand könnte mir vielleicht helfen einen Lösungsansatz zu 
finden oder sieht anhand vom code direkt was das Problem ist.

[Z.B. Max (darter)]

Hi,
da scheinbar

RTC_Init();

 und

RTC_SetDateTime(&rtc);

 nach deine Aussage funktionieren kann es ja nicht an

while(TWCR & (1<<TWSTO));

 liegen da diese Funktionen

i2c_start()

 aufrufen und diese bis auf den Teil identisch zu

i2c_start_wait()

 ist.

      twst = TW_STATUS & 0xF8;
      if ( (twst == TW_MT_SLA_NACK )||(twst ==TW_MR_DATA_NACK) ) 
      {          
          /* device busy, send stop condition to terminate write operation */
          TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWSTO);
          
          // wait until stop condition is executed and bus released
          while(TWCR & (1<<TWSTO));
          
          continue;
      }
      //if( twst != TW_MT_SLA_ACK) return 1;
      break;

Sicher dass du Pullups an SCl und SDA angeschlossen hast?

[Jonas N. (medustv)]

Ja sind angeschlossen

[Steve van de Grens (roehrmond)]

Jonas N. schrieb:
> vielleicht helfen einen Lösungsansatz zu finden

Messe die Spannung an SCA und SDL. Sie müssen vor der ersten 
Kommunikation schon auf HIGH sein. Und danach auch.

Überprüfe die beiden Leitungen mit einem Oszilloskop und zeige uns das 
Bild.

Am einfachsten geht das, indem zu die Kommunikation nur einmal nach 
einem Tastendruck versuchst und das Oszilloskop auf den Tastendruck oder 
auf die fallende Flanke an SDA triggerst.

[Jonas N. (medustv)]

Okay mache ich morgen mal

[Steve van de Grens (roehrmond)]

Du könntest folgenden Code versuchen:

TWBR = 32;  // 100 kHz bei 8 MHz CPU Takt

// Sende Start 
TWCR=(1<<TWINT) | (1<<TWEN) | (1<<TWSTA);
while (!(TWCR & (1<<TWINT)));
uint8_t status=TWSR & 0xf8;
if (status != 0x08 && status != 0x10) {
  // Hier bitte eine Fehlermeldung ausgeben
}
    
// Sende Adresse (write mode)
TWDR=slave_address << 1; // keine Ahnung, welche Adresse deine RTC hat
TWCR=(1<<TWINT) | (1<<TWEN);
while (!(TWCR & (1<<TWINT)));
if ((TWSR & 0xf8) != 0x18) {
  // Hier bitte eine Fehlermeldung ausgeben
}

// Sende STOP
TWCR=(1<<TWINT) | (1<<TWEN) | (1<<TWSTO);

Das sollte 9 Takte auf SCL erzeugen und ein Byte auf SDA übertragen. Das 
ist mit einem digitalen Oszilloskop recht übersichtlich darstellbar. 
Wenn die Slave Adresse richtig ist, sollte die RTC die Leitung SDA beim 
9. Takt auf LOW ziehen.

[Z.B. Max (darter)]

Habs mal eben nach gebaut und funktioniert bei mir ohne Probleme.

Wen du dir absolut sicher bist dass du SCL und SDA über Widerstände auf 
High ziehst und alles richtig verkabelt ist würde ich den DS1307 chip 
austauschen wenns immer noch nicht klappt den atmega 328 tauschen

[Jonas N. (medustv)]

Hm komisch, na gut dann schicke ich morgen mal meinen Schaltplan rein. 
Könntest du deinen wenn der aufwand nicht allzu groß ist auch hochladen?

[Z.B. Max (darter)]

Ich habe in meinem fall nen Arduino uno genommen und nen DS1307 Chip.

Wenn ich die Pullup-Widerstände abziehe bekomme ich genau den von dir 
beschriebenen Effekt dass er in

i2c_start()

 hängen bleibt.

[Z.B. Max (darter)]

ok ich hab eben mal versucht einen quarz dran zu hängen, da ich leider 
keinen mit 32.768kHz da hatte hab ichs mit nem anderen versucht und nun 
hab ich das gleiche Problem wie du.

ic2 start()

 funktioniert.

ic2 start_wait()

 nicht.

[Jonas N. (medustv)]

Also wohl ein Timing Problem..
Versuche es morgen auch mal ohne den Quarz.

[Z.B. Max (darter)]

Habs jetzt mal an ein grove - ds1307 gehängt.

Auf dem Board ist ja nur der DS1307 Chip, ein quarz und 2 Pullup 
Widerstände.

Funktioniert einwandfrei.
Hab mir mal nur die Sekunden ausgeben lassen.
Liegt also eindeutig nicht am Code.

[Stefan F. (Gast)]

Z.B. Max schrieb:
> Ich habe in meinem fall nen Arduino uno genommen und nen DS1307 Chip.

Ohne Abblock-Kondensator an der Stromversorgung des IC ist alles 
möglich. Den solltest du nicht weglassen.

Funktioniert der Chip überhaupt ohne Quarz?

[Frank M. (ukw) (Moderator)]

Wenn's nicht am Code liegt:

Wie sehen die Fuses aus? Kannst Du eine LED mit der richtigen Frequenz 
blinken lassen?

[Gerald B. (gerald_b)]

Wie stehen die Fuses? Wie ist der Compiler konfiguriert? (boards.txt)
Wenn du bspw. auf externen Quarz gefused hast und da ist keiner, dann 
schwingt garnichts.
Teilst du dem Compiler die falsche Frequenz mit, haut dein Timing nicht 
hin (8 statt 16 Mhz, oder umgekehrt)
Das kann z.B. der Fall sein, wenn du das falsche Board in der IDE 
auswählst 3,3 statt 5V Variante und umgekehrt.

[Jonas N. (medustv)]

Weitere infos folgen morgen

[Jonas N. (medustv)]

Wieso?

[Frank E. (ffje)]

So ganz im Detail habe ich mir den ATMEGA328P nicht angesehen..., aber 
interner Quarz?
mfG  fE

[Jonas N. (medustv)]

Verzeihung, dass ich mich falsch ausgedrückt habe. Ich meinte 
selbstverständlich den internen Oszillator.

[Z.B. Max (darter)]

C-hater schrieb im Beitrag #7484043:
> Jonas N. schrieb:
>
>> Der Atmega328p läuft mit 8MHz über
>> den internen Quarz
>
> Und schon ist klar: Troll oder Vollidiot. Troll-Vermutung ist wohl
> wahrscheinlicher.

Was ist denn das bitte für eine Ausdrucksweise?
Nicht jeder wird Allwissend geboren und wir haben alle verstanden was er 
mit internen Quarz gemeint hat.
Deswegen ist man noch lange kein Vollidiot...

[Jonas N. (medustv)]

Steve van de Grens schrieb:
> Das sollte 9 Takte auf SCL erzeugen und ein Byte auf SDA übertragen. Das
> ist mit einem digitalen Oszilloskop recht übersichtlich darstellbar.
> Wenn die Slave Adresse richtig ist, sollte die RTC die Leitung SDA beim
> 9. Takt auf LOW ziehen.

Sieht das so in Ordnung aus?

[Jonas N. (medustv)]

Hier einmal die gesetzten Fuses und der Schaltplan.

[Dietrich L. (dietrichl)]

Jonas N. schrieb:
> der Schaltplan

Wo sind die Stützkondensatoren?

[Jonas N. (medustv)]

Habe einen mit 100nF an Vcc und Gnd

[Michael M. (michael89)]

Hallo,

hab es mal kurz überflogen.

    rtc_t rtc; 
    uart_init();
    RTC_Init();
    rtc.hour = 0x10; //  10:40:20 am
    rtc.min =  0x40;                 <------ 
    rtc.sec =  0x00;

ist HEX 0x40 in DEC 64 ?? evtl. führt das zum Problem ?

Wo ist denn jetzt überhaupt noch das Problem ? Du konntest doch die 
Sekunden auslesen. Hast du ein 100nF (Abblockkondensator) hinzugefügt ?

Gruß

[Jonas N. (medustv)]

Michael M. schrieb:
>

>     rtc_t rtc;
>     uart_init();
>     RTC_Init();
>     rtc.hour = 0x10; //  10:40:20 am
>     rtc.min =  0x40;                 <------
>     rtc.sec =  0x00;
> 
>

> ist HEX 0x40 in DEC 64 ?? evtl. führt das zum Problem ?

Hab ich korrigiert, hat aber dennoch nichts geändert.

> Wo ist denn jetzt überhaupt noch das Problem ? Du konntest doch die
> Sekunden auslesen.

Nein konnte ich nicht, hab immer noch das Problem überhaupt nichts lesen 
zu können.

>  Hast du ein 100nF (Abblockkondensator) hinzugefügt ?

Ja

[S. L. (sldt)]

> Problem überhaupt nichts lesen zu können

Worauf wird eigentlich ausgegeben, und wie sieht die Ausgabe aus?

[Jonas N. (medustv)]

Ich möchte mir die gelesenen Werte in Putty ausgeben lassen und das 
Terminal bleibt logischerweise schwarz, da er beim Lesen der Zeiten fest 
hängt.

[Z.B. Max (darter)]

Einen anderen Quarz probiert? An der Software liegt es ja 
nachgewisenerweise nicht.

[Jonas N. (medustv)]

Ja auch schon versucht

[Jonas N. (medustv)]

Das ist übrigens die Ausgabe auf den SCL und SDA Leitungen, wenn er an 
der While schleife, stehen geblieben ist.

[S. L. (sldt)]

> das Terminal bleibt logischerweise schwarz

Ich würde generell am Programmbeginn ein 'hallo' einbauen, um Probleme 
im Ausgabebereich ausschließen zu können.

[Jonas N. (medustv)]

Hast du dir den Code überhaupt angesehen? Wenn ja, dann wüsstest du, 
dass es nicht an der Ausgabe liegen kann.

[Joachim B. (jar)]

Jonas N. schrieb:
> Der Atmega328p läuft mit 8MHz über
> den internen Quarz

hat intern kein Quarz!

Jonas N. schrieb:
> Hier einmal die gesetzten Fuses und der Schaltplan.

warum schwindelst du?
Quarz ist auch nicht eingezeichnet

Jonas N. schrieb:
> Versuche es morgen auch mal ohne den Quarz.

wo wird denn F_CPU gesetzt? Welchen I2C Clock nutzt du?
Ich durchsuche nun nicht den ganzen Code, irgendwo wird dein Fehler 
sein.

[Michael M. (michael89)]

Hallo,

nimm mal eine andere Lib für I²C oder DS1307 Modul.
sieht schonmal komisch aus, wenn die Header und C Datei nicht den selben 
Namen haben (muss natürlich nichts heißen).

google einfach mal : "atmega328P IIC github" und probiere eine andere 
aus.

Wenn du ganz einfach machen willst lad dir die Arduino IDE wähl da den 
Atmega328P (UNO) aus und probiere ein Beispiel.

Hab auch keine Zeit komplett durch die Lib zu surfen.

Gruß

[Z.B. Max (darter)]

Joachim B. schrieb:
> Jonas N. schrieb:
>> Der Atmega328p läuft mit 8MHz über
>> den internen Quarz
>
> hat intern kein Quarz!
>
> Jonas N. schrieb:
>> Hier einmal die gesetzten Fuses und der Schaltplan.
>
> warum schwindelst du?
> Quarz ist auch nicht eingezeichnet
>
> Jonas N. schrieb:
>> Versuche es morgen auch mal ohne den Quarz.
>
> wo wird denn F_CPU gesetzt? Welchen I2C Clock nutzt du?
> Ich durchsuche nun nicht den ganzen Code, irgendwo wird dein Fehler
> sein.

Die Diskussion hatten wir gestern schon.
Er benutzen den internen Oszillator am ATMega328P
F_CPU wird auf 8000000 gesetzt.

Wir hatten den über den Quarz am DS1307 gesprochen, weil ich keinen 
32,768 kHz da hatte hab ich mit nem 16Mhz versucht, was nicht von Erfolg 
gekrönt war.
Deshalb hab ich seinen Code genommen und an nen Grove-DS1307 gehängt und 
es hat funktioniert, woraus ich schließe dass es ein Hardware-Problem 
ist.

[Εrnst B. (ernst)]

Jonas N. schrieb:
> Das ist übrigens die Ausgabe auf den SCL und SDA Leitungen, wenn er an
> der While schleife, stehen geblieben ist.

Das wiederum kann garnicht sein, weil die While-Schleife

while(TWCR & (1<<TWSTO));

keinerlei weitere Ausgaben auf dem I²C enthält und demnach spätestens 
nach etwas Zeit Ruhe auf dem Bus herrschen muss.
ISRs die pausenlos den I²C befeuern habe ich bei dir nicht gesehen.

Also: Entweder bleibt dein Programm an einer anderen Stelle hängen, und 
nicht in der Schleife die du vermutest, oder dein Oszi-Bild ist Fake, 
oder du hast noch geheime Zusatz-Hardware mit an dem Bus, von der du uns 
nichts verraten hast.

[Z.B. Max (darter)]

Ok habs eben nochmal auf nem nackten 328p probiert.
1 zu 1 mit dem von dir geposteten Code(Bis auf meinen Versuch einen 
Zeilenumbruch hinzubekommen "uart_puti(0x0A);" was leider nicht 
funktioniert) und es funktioniert problemlos.
Es muss daher an deiner Hardware liegen.

Wie schaust du dir die daten am seriellen Port an?
Vielleicht gibt es da Probleme. Ich kenne mich mit dem Atmel Studio 
nicht aus. gibt es da nen Seriellen Monitor?

[S. L. (sldt)]

> Wie schaust du dir die daten am seriellen Port an?
> Vielleicht gibt es da Probleme.

Diese Vermutung hatte ich auch bereits, bekam aber als Antwort:

> Hast du dir den Code überhaupt angesehen? Wenn ja,
> dann wüsstest du, dass es nicht an der Ausgabe liegen kann.

[Jonas N. (medustv)]

Leute, ich bekomme im Debugmode doch mit, dass er aus der einen Schleife 
nicht mehr herauskommt

[Εrnst B. (ernst)]

Jonas N. schrieb:
> Leute, ich bekomme im Debugmode doch mit, dass er aus der einen Schleife
> nicht mehr herauskommt

Das kann nicht sein. Laut deinem Oszi-Screenshot hast du innerhalb der 
Schleife kontinuierlich Flankenwechsel auf SCL. Wenn du keine geheime 
Troll-Hardware mit angeschlossen hast, müssen die vom ATMega kommen. Der 
wiederrum wackelt garantiert nicht am SCL, wenn ihm das nicht 
aufgetragen wird. Während er im Debugger gestoppt ist erst recht nicht.

Hast du evtl. den Strichpunkt nach

while(TWCR & (1<<TWSTO))

vergessen?

[S. L. (sldt)]

> Leute ...

Eine Frage von Wahrscheinlichkeit und Aufwand - zu Programmbeginn ein 
'hallo' einbauen, den Debugmode abschalten und das Ganze laufen lassen: 
kostet Sie vielleicht ein oder zwei Minuten. Was ist das schon 
verglichen mit diesem Thread mit inzwischen 43 Beiträgen.

Zumindest verfahre ich so, wenn ich nicht mehr weiterweiss.

[Wastl (hartundweichware)]

Z.B. Max schrieb:
> Versuch einen
> Zeilenumbruch hinzubekommen "uart_puti(0x0A);" was leider nicht
> funktioniert)

Für einen Zeilenumbruch versuchs doch mal mit

uart_puts ("\r\n");

[Z.B. Max (darter)]

Wie sieht denn nun deine Ausgabe am Seriellen Port aus? Ein "Test" 
müsste du ja auf jeden fall bekommen.
Probier nen anderen DS1307 Chip, wenn das nicht Funktioniert hol dir das
https://www.reichelt.de/arduino-grove-echtzeituhr-rtc-ds1307-grv-rtc-p191187.html

Ich kann mich nur widerholen. Damit und mit deiner Software funktioniert 
es bei mir.

[Stefan F. (Gast)]

Jonas N. schrieb:
> Sieht das so in Ordnung aus?

Fast perfekt. Der einzige Haken ist, dass sich deine RTC nicht 
angesprochen fühlt. Sie bestätigt die empfangene Slave Adresse nicht.

Also ist entweder die Slave Adresse falsch oder die RTC funktioniert 
nicht.

[Stefan F. (Gast)]

Jonas N. schrieb:
> Das ist übrigens die Ausgabe auf den SCL und SDA Leitungen, wenn er an
> der While schleife, stehen geblieben ist.

Auch hier sieht man beim jeweils 9. Takt, dass deine RTC die Slave 
Adresse nicht bestätigt.

Ich finde aber seltsam das dein Bild mindesten eine Wiederholung der 
Adresse zeigt, obwohl das Programm nach deiner Aussage beim Fehler 
hängen bleibt. Hast du noch einen Watchdog aktiviert, der dabei einen 
Reset auslöst?

[Stefan F. (Gast)]

Ich habe mal die 9 Bits eingezeichnet.

Die 7 Bit Slave Adresse ist 1101000 (= 0x68, oder 104), was mit dem 
Datenblatt des DS1307 überein stimmt.

Danach kommt das R/W Bit mit dem Wert 0, womit der Master mitteilt, dass 
er in der folgenden Kommunikation schreibend auf den Slave zugreifen 
will.

Danach sollte eigentlich das ACK kommen. Der Slave müsste beim 9. 
Taktimpuls die SDA Leitung auf Low ziehen um zu signalisieren "hier bin 
ich, bereit zur Kommunikation". Genau das fehlt in deinem Fall, der 
Slave hat nicht bestätigt.

Vergleiche mit
https://de.wikipedia.org/wiki/I%C2%B2C#Takt_und_Zust%C3%A4nde_des_Busses

Ich tippe immer noch darauf, dass der Chip nicht funktioniert, weil der 
Abblock-Kondensator an der Stromversorgung fehlt. Vielleicht auch, weil 
der Quarz fehlt. Auf dem Steckbrett funktioniert der Oszillator außerdem 
wahrscheinlich nicht, weil die Kontakte von dem Brett zu viel Kapazität 
haben. Das wird wohl nur auf einer gelöteten Platine funktionieren 
können.

Andere Bild:
Jonas N. schrieb:
> Sieht das so in Ordnung aus?

Dieser Screenshot sieht doch nicht gut aus. Hier ist die 7 Bit Adresse 
1010000, was nicht mit dem Datenblatt überein stimmt.

[Rainer S. (rsonline)]

SPI Würde ich I2C immer vorziehen, da das Protokoll doch wesentlich 
einfacher und auch eindeutiger ist. Auch wenn der I2C Chip irgendwann 
mal laufen sollte.

MCP795W20
Enhanced Feature Battery-Backed SPI Real-Time Clock/Calendar

https://www.microchip.com/en-us/product/mcp795w20

[Jonas N. (medustv)]

Stefan F. schrieb:
>
> Auf dem Steckbrett funktioniert der Oszillator außerdem
> wahrscheinlich nicht, weil die Kontakte von dem Brett zu viel Kapazität
> haben. Das wird wohl nur auf einer gelöteten Platine funktionieren
> können.

Habe mal den Quarz direkt an den Chip gelötet und erhalte nun endlich
eine Ausgabe. Die Werte, die ich derzeit bekomme, sind nur etwas
komisch. Die Zeitwerte gehen über 60 hinaus und springen auch sehr 
stark.

[Steve van de Grens (roehrmond)]

Hast du den Abblock-Kondensator hinzugefügt und dafür gesorgt, dass die 
Pins X1 und X2 nicht im Steckbrett stecken?

Hänge nochmal das Oszilloskop an den I²C Bus, so dass man die 
Kommunikation sehen kann (zumindest die ersten 9 Takte).

[Jonas N. (medustv)]

Kondensator ist hinzugefügt und die Pins X1 und X2 stecken zwar im 
Steckbrett, aber auf die ist der Quarz aufgelötet, sollte also passen.

Den Fehler bei den Sekunden konnte ich beheben, das war nur ein Fehler 
in der Ausgabe, aber bei den Minuten gibt es noch Probleme: Wenn ich die 
Minuten auf 59 stelle, springen sie nicht wieder auf 0, sondern auf 68.

[Joachim B. (jar)]

Jonas N. schrieb:
> Die Zeitwerte gehen über 60 hinaus

fehlt etwa bcd to int?

uint8_t decToBcd( int val )
{
    return (uint8_t) ((val / 10 * 16) + (val % 10));
}
 
uint8_t bcdToDec( uint8_t val )
{
    return (uint8_t) ((val / 16 * 10) + (val % 16));
}

[Mod: C-Tags eingefügt]

[Jonas N. (medustv)]

Danke jetzt funktioniert es.

[Steve van de Grens (roehrmond)]

Jonas N. schrieb:
> Kondensator ist hinzugefügt und die Pins X1 und X2 stecken zwar im
> Steckbrett, aber auf die ist der Quarz aufgelötet, sollte also passen.

Nein, sollte nicht passen. Denn die Kontakte des Steckbretts haben 
typischerweise mehr als 10pF Kapazität, die den Oszillator belasten. 
Dafür ist er nicht vorgesehen.

Wenn er trotzdem für einen kurzes Experiment halbwegs läuft, hast du 
Glück. Den finalen Aufbau wirst du eh nicht auf Steckbrett machen, nehme 
ich mal an.

[Jonas N. (medustv)]

Okay dann werde ich morgen die Pins nach oben biegen. Funktioniert hatte 
es jetzt aber erstmal so.

[C-hater (c-hater)]

Z.B. Max schrieb:

> Was ist denn das bitte für eine Ausdrucksweise?
> Nicht jeder wird Allwissend geboren und wir haben alle verstanden was er
> mit internen Quarz gemeint hat.
> Deswegen ist man noch lange kein Vollidiot...

Hat ja auch niemand behauptet. Die Schwerpunkt lag ganz eindeutig auf 
"Troll". Ich habe nur auch die einzige rationale Alternative 
aufgezeigt...