Hallo Leute....
Ich habe da ein Automatisierungssystem für mein Tropenterrarium gebastelt, welches von einem Uno gesteuert wird. Folgendes ist verbaut:
-Beregnungsanlage (über Relais geschaltet)
-Leuchtstoffröhre (über Relais geschaltet)
-RGB-LED-Streifen (PWM-Ausgänge steuern MOSFETs an)
5m, 60LED/m
grün-gelbliches Licht am Tag, Rot in der Nacht (Rot ist für die Terrariumbewohner nicht sichtbar)
sanfte "Sonnen"auf- und untergänge
kleine Temperaturregelung durch die Lichtintensität des LED-Strips
-Temperatur- und Feuchtigkeitssensor DHT22
-externes Uhrmodul (DS3231)
Berechnung von Sommer- und Winterzeit
-Anzeige durch 20x4 LCD-Display (I2C)
Uhrzeit, LF, Temperatur/ PWM-Intensität der einzelnen Farben des RGB-Strips bei Knopfdruck
-4 Taster
LCD-Beleuchtung für gewisse Zeit anschalten
Beregnung manuell starten
LCD-Anzeige ändern
RGB-Intensität auf Grundeinstellung setzen
Hier der Schaltplan:
Aber nun zum Problem:
ab und zu kommt es vor, dass der Arduino einfach einfriert, also Ausgänge werden nicht mehr verändert, Veränderungen an den Eingängen bewirken nichts, LCD-Anzeige bleibt gleich. Nur der Neustart-Taster am Arduino geht dann noch. Das Ganze passiert am großen Terrarium vielleicht 1x in zwei Monaten, bei meinem kleinen Terrarium 1-2x im Monat. Ist ziemlich ärgerlich, wenn ich mehrere Tage weg bin und die Zeitsteuerung vom Arduino nicht hinhaut. Habe bisher auch nichts weiter gefunden, was den Fehler verursachen könnte.
Meine Idee: eine Art Kontroll-Arduino (Nano oder Mikro) hinzuzuziehen, der Uno toggelt mit jeder Sekunde einen Port, welchen der Kontroll-Arduino liest. Registriert dieser nun, dass der Uno stillsteht, dann schaltet er den Uno ein und wieder aus (per Relais, welches den Taster am Uno ersetzt). Der Vorteil: der Uno kann gleichzeitig den Kontroll-Arduino testen, so dass die beiden sich gegenseitig prüfen.
Was haltet Ihr von der Idee, ist das so umsetzbar und auch sinnvoll? Oder gibt's da was Besseres?
Sowas kann der Prozessor auch selbst per Watchdog Timer erledigen. Das ist ein interner Timer mit einem eigenen Oszillator. Wenn man man den nicht in einem bestimmten Zeitrahmen zurücksetzt (z.B. 8 Sekunden) löst er automatisch einen Reset aus.
https://tushev.org/articles/arduino/5
Sind nur drei Zeilen. Erst den Header einfügen:
#include <avr/wdt.h>
Dann macht man in setup() das:
wdt_enable(WDTO_8S)
Und dann muss man in loop() innerhalb dieser Zeit das machen:
wdt_reset();
Also darauf achten dass du keinen lange blockierenden Code hast
Poste doch mal deinen Code und poste mal auch noch deine Compiler Ausgabe...
@Serenifly
Das ist natürlich eine geniale Sache, werde das gleich implementieren und hochladen, vielen Dank für den Hinweis (y)
@mpl1337
Öhm wozu die Compilerausgabe? Er lädt es ja hoch wie er soll, und das Programm an sich funktioniert ja auch.
Wie gesagt darauf achten das wdt_reset() ständig gemacht wird. Also das in loop() aufrufen und dann schauen dass es schnell genug dran kommt. Wenn du irgendwo eine blockierend Schleife hast kannst du das auch darin aufrufen. Aber 8 Sekunden sollten ausreichen wenn der Code halbwegs vernünftig geschrieben ist.
Der Compiler sagt dir ja wie groß der Flash und sram ist...Wird wohl irgendwas überlaufen .. Hatte auch das Problem und lange gesucht bis ich es gefunden habe.
@Serenifly
Jup werde ich machen, sollte dann klappen (hoffentlich).
@mpl1337
Der Compiler sagt am Schluss:
"Der Sketch verwendet 12.870 Bytes (39%) des Programmspeicherplatzes. Das Maximum sind 32.256 Bytes.
Globale Variablen verwenden 574 Bytes (28%) des dynamischen Speichers, 1.474 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.048 Bytes."
Muss ich dann noch schauen ob das geht, habe kürzlich auf 1.6.6. umgerüstet, da hat er ein paar Bibliotheken durcheinandergewürfelt und gab ein paar Fehler aus, habe das nun soweit behoben.
Nun gibts noch folgende Warnungen, die aber nichts für das Programm zu sagen haben müssten, oder?
(am Programm habe ich ja noch nix geändert, nur die IDE)
"Warnung: platform.txt aus dem Kern 'Arduino AVR Boards' enthält veraltete recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/{archive_file}" "{object_file}" und wurde automatisch zu recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}" konvertiert. Erwägen Sie eine Aktualisierung dieses Kerns.
WARNUNG: Kategorie '' in der Bibliothek EEPROM ist ungültig und wird auf 'Uncategorized' festgelegt
WARNUNG: Kategorie '' in der Bibliothek SPI ist ungültig und wird auf 'Uncategorized' festgelegt
WARNUNG: Kategorie '' in der Bibliothek SoftwareSerial ist ungültig und wird auf 'Uncategorized' festgelegt
WARNUNG: Kategorie '' in der Bibliothek Wire ist ungültig und wird auf 'Uncategorized' festgelegt"
