Hi!
Bin grade dabei einen Arduino mega 2560 mit einem ds1307 zu benutzen,
habe aber das Proboblem, daß mein Program mitten beim Ausschreiben eines
Debugtextes rebootet.
Genutzt wird die gänderte DS1307RTC Lib von
http://limchonghan.wordpress.com/
benutzte Libraries:
1
#include<Time.h>
2
#include<Wire.h>
3
#include<DS1307RTC.h>
Setup routine:
1
voidsetup(){
2
Serial.begin(115200);
3
while(!Serial);// Needed for Leonardo only
4
Serial.println(" setup1");
5
zeitSetup();
6
Serial.println(" setup2");
7
...
8
}
Code wo es abschmiert:
1
tmDriftInfodi;
2
3
voidzeitSetup(){
4
Serial.println("Zeitsetup1");
5
pinMode(13,OUTPUT);
6
Serial.println("Zeitsetup11");
7
pinMode(18,OUTPUT);// pinMode(A2, OUTPUT);
8
Serial.println("Zeitsetup12");
9
...}
Der Output
1
setup1
2
Zeitsetup1
3
Zeitsetup11
4
Z setup1
5
Zeitsetup1
6
Zeitsetup11
7
Z setup1
8
Zeitsetup1
9
Zeitsetup11
10
Z setup1
11
Zeitsetup1
12
Zeitsetup11
13
Z ... usw.
Auch wenn ich das mit dem pinmode oder die Debug texte auskommentiere,
komme ich nicht weiter, es rebootet gleich nach dem auschreiben des Z.
Hat die Library time irgendetwas mit I2C was auf dem Mega nicht geht?
Oder welche Interrupts gibts da? Ist Time eigentlich Interrupt
getrieben?
Langsam verzweifle ich, da es eigentlich gehen sollte...
Gibt es hier jemanden der seine RTC kalibriert benutzt? Welche Library
(außer der von mir oben beschriebenen) benutzt man da am besten?
Wollte ursprünglich DFC77 benutzen, aber das Signal ist zu verrauscht
bei uns. Ich dachte auch an das Benutzen der allgegenwärtigen 50Hz. Hat
die schon jemand geschafft zu benutzen um die RTC zu kalibrieren? Gibts
da Libraries?
Martin G. schrieb:> as Proboblem, daß mein Program mitten beim Ausschreiben> eines Debugtextes rebootet.
Die zwei häufigsten Gründe für das überraschende Rebooten des
Controllers bei laufendem Programm sind
1.) Falsche Pointer-Zugriffe im Programm (z.B. Array-Index außerhalb des
Bereichs)
2.) der RAM-Verbrauch des Programms übersteigt den im Controller
eingebauten RAM-Speicher
Also egal ob 1.) oder 2.): Die Ursache ist typischerweise ein
fehlerhaftes Programm!
> Gibt es hier jemanden der seine RTC kalibriert benutzt? Welche Library> (außer der von mir oben beschriebenen) benutzt man da am besten?>> Wollte ursprünglich DFC77 benutzen, aber das Signal ist zu verrauscht> bei uns.
Das DCF-Signal ist hauptsächlich nur dann verrauscht, wenn sich
innerhalb von zwei Metern um Dein DCF-Modul erhebliche Störquellen
befinden. Zum Beispiel Störquellen als da wären (unvollständige
Aufzählung):
- Computer
- Monitore
- alles was funkt (Smartphone, WLAN, DECT-Schnurlostelefone)
- Energiesparlampen und Leuchtstoffröhren
- Schaltnetzteile
Insbesondere wenn Du Dein DCF-Modul betreibst, während der Arduino am
Computer angeschlossen ist, würdest Du also ein mindestens 2 Meter
langes USB-Kabel benötigen, um Arduino+DCF-Modul zwei Meter weg von
Monitor und PC ablegen zu können, wo Du dann wieder guten DCF-Empfang
hast.
An Libraries und Modulen gibt es solche und solche: Für DCF-Module mit
eingebautem Tiefpassfilter, die das Signal zeitlich verzögert nach
Tiefpassfilterung abgeben (typischer Vertreter: das DCF-Modul von
Pollin) eignen sich eigentlich alle frei verfügbaren DCF-Libraries für
Arduino einigermaßen brauchbar. Aber für "schnelle" DCF-Module, die ihr
empfangenes Signal ungefiltert weitergeben (typischer Vertreter: das
DCF-Modul von Conrad) sind eigentlich alle fertig downloadbaren
DCF-Libraries völliger Schrott und unbrauchbar, dafür programmiert man
sich lieber selbst etwas besseres.
Die 50 Hz-Netzfrequenz ist zwar auf längere Zeit gesehen "im
Durchschnitt" eine Zeit, die nur wenig von der tatsächlichen Zeit
wegläuft, die aber bei Schwankungen der Stromerzeugung auch durchaus mal
in einer Woche um mehrere Minuten in die eine oder die andere Richtung
laufen kann. Außerdem kann die Netzfrequenz niemals die realse Zeit
liefern, sondern stets nur den "Takt" vorgeben, mit dem die Zeit läuft.
Ich frag mich nur, was da den RAM während des Auschreibens des Textes
verbraucht... Kann das sein, daß der Compiler da was nicht schafft?
50Hz: recht hast du. Das kann da paar Minuten falsch gehen...
Zeig mal deinen ganze Code.
Wenn das dein Output ist
1
setup1
2
Zeitsetup1
3
Zeitsetup11
4
Z setup1
5
Zeitsetup1
dann bedeutet das, das die Funktion
1
voidzeitSetup(){
2
Serial.println("Zeitsetup1");
3
pinMode(13,OUTPUT);
4
Serial.println("Zeitsetup11");
5
pinMode(18,OUTPUT);// pinMode(A2, OUTPUT);
6
Serial.println("Zeitsetup12");
7
...}
gar nicht über den pinMode setzen hinaus kommt.
Da zeitSetup() aber hier
1
voidsetup(){
2
Serial.begin(115200);
3
while(!Serial);// Needed for Leonardo only
4
Serial.println(" setup1");
5
zeitSetup();
aus setup() heraus aufgerufen wird, da aber ausser der Seriellen nach
gar nichts aktiviert ist, stimmt da was nicht, was du uns aber nicht
gezeigt hast.
Martin G. schrieb:> Ich frag mich nur, was da den RAM während des Auschreibens des Textes> verbraucht... Kann das sein, daß der Compiler da was nicht schafft?
Ein MEGA2560 hat erstmal genug RAM für etliche nicht optimierte Ausgaben
von Textkonstanten, das mit dem aufgebrauchten RAM-Speicher dürfte es
bei Dir nicht unbedingt sein.
Was es ist, dafür müsste man für eine Diagnose
a) die vollständige Schaltung und
b) den vollständigen Code kennen
Ansonsten bist Du mit Deinen Fragen in einem Hellseher-Forum besser
aufgehoben.
Eine Möglichkeit wäre z.B. bei einem Absturz in dieser Codesequenz:
1
pinMode(18,OUTPUT);// pinMode(A2, OUTPUT);
2
Serial.println("Zeitsetup12");
dass Du an Pin-18 irgendwas angeschlossen hast, das einen Kurzschluss in
der Schaltung verursacht, sobald Pin-18 auf OUTPUT/LOW gesetzt wird, in
der Folge die Spannung am Controller einbricht, und die
Brownout-Detection dann unmittelbar einen Reset einleitet, weil die
Spannung wegen des Kurzschlusses nicht mehr ausreicht.
Aber ohne die Schaltung und den vollständigen Code zu kennen, ist das
natürlich reine Spekulation.
Hi!
Danke für die Tips.
Ich hab mit einem zeilenweisen warten auf Eingabe über Seriell die
Problematische Stelle gefunden. Der Fehler war viel weiter unten im
Code, also erst viel später, bei dem Setzen der
Zeitsynchronisierfunktion.
Also wie ich mir das erklären kann, arbeitet der uC alles ab, und
schreibt in seinen Seriellen Puffer so manche Daten bevor er zu der
fatalen Stelle kommt, und rebootet. Deshalb sah ich das so, als wenn er
mitten in einer Ausgabe neu starten würde.
Mann. das kostet Nerven. Daran denkt man eigentlich gar nicht, das
spätere Ereignisse das auch sein könnten. Ich dachte immer an eher
eintretende Ereignisse.