oder gleich
if (Minute % 5 == 0 && (Minute != altMinute) {
altMinute = Minute;
// jede volle 5 Minuten einmal
...
}
Hi,
... wenn du die letzten vollen 5 Minuten schon mal hier warst, dann geh weg 
Ist natürlich einfacher, aber ich mochte Logiktabellen noch nie wirklich ...
@ Michael, kannst Du mir in 2 Sätzen erklären, was mit myFile.flush() anders läuft. Ich gehe davon aus, daß es besser ist, nur einmal die Stunde auf die SD-Card zu schreiben, als alle 5 Minuten.
@ agmue, bei einem 5 Minutenrhythmus wird es vermutlich tatsächlich relativ egal sein, ob die Temperatur bei 12:05 oder 12:07 geloggt wird. Bei einem längeren Interval hätte ich es dann aber schon gern etwas genauer. Ich habe es ja auch erst mit Interval.h getestet, dann kam aber der Wunsch auf, alles auf feste Zeiten zu synchronisieren, und die RTC wird eh benötigt.
Gruß André
kannst Du mir in 2 Sätzen erklären, was mit myFile.flush() anders läuft. Ich gehe davon aus, daß es besser ist, nur einmal die Stunde auf die SD-Card zu schreiben, als alle 5 Minuten
write/print alleine bewirkt nicht notwendigerweise einen Transfer.
flush() sorgt dafür, dass die bisher "geschriebenen" Sachen tatsächlich auf die Karte gelangen, wirkt also effektiv fast wie ein close() und erneutes open(). Der Dateiname und der Sektor der aktuellen Schreibposition muss natürlich nicht erneut gesucht und geladen werden.
Wenn du jede Stunde einmal flush() aufrufst, wird mindestens jede Stunde der aktuelle Sektor aktualisiert Bei mehr Daten werden vorige Sätze schon früher in kompletten Sektoren gespeichert.
Wenn du jede Stunde {open / eine Serie von print / close} machst, wird zusätzlich die open() Funktion ausgeführt. Eventuell gehen mehr Daten verloren, wenn die volle Stunde nicht mehr erreicht wird. Das zusätzliche open() reicht übrigens nicht immer, wenn zwischendurch die Karte ausgetauscht wurde. Eventuell ist dann sogar ein erneutes SD.begin() erforderlich.
Es finden also in beiden Fällen die gleiche Anzahl "echter" Schreibvorgänge statt. Im zweiten Fall ein paar mehr zusätzliche Lesevorgänge. Ein Spannungsausfall mitten während eines Schreibvorgangs ist in beiden Fällen problematisch.
Um sicherer gegen Datenverlust zu sein, könntest du jedesmal (alle 5 Minuten) open/print/close machen und im Fehlerfall den Datensatz in deinem Array aufheben, bis die Karte wieder (oder eine ErsatzKarte) funktioniert, nach neuem SD.begin. Da heutige Karten riesig groß sind, wird jeder Sektor nur ganz wenige Male in seinem Leben beschrieben, so dass dies für unsere Datenlogger-Anwendungen irrelevant ist.
SpaghettiCode:
@ agmue, ... ob die Temperatur bei 12:05 oder 12:07 geloggt wird.
Ich glaube, Du hast mich gänzlich mißverstanden. Ich wundere mich, warum Du erst eine Stunde Daten sammelst, um sie dann auf die SD-Karte zu schreiben. Ich würde alle 5 Minuten direkt auf die SD-Karte schreiben.
michael_x:
Um sicherer gegen Datenverlust zu sein, könntest du jedesmal (alle 5 Minuten) open/print/close machen ...
Das hatte ich gemeint.
Hi,
Michael, danke für Deine Ausführungen, so umfangreich hätte ich sie nun tatsächlich nicht erwartet! (2 Sätze ;))
Danach habe ich verstanden, daß es nur wiederholte Schreib-Zugriffe pro Sektor (512) gibt, bis dieser voll ist.
Wenn ich die Karte also nicht gerade mit einzelnen Bytes füllen will ist alles gut.
Das Array ist für mich eine Übung gewesen, brauchte ich bisher nicht, und sehe hier einen sinnvollen Einsatz, um die Karte auch mal in jeweils festen Zeitfenstern entnehmen zu können. Kann aber sein daß ich aus der 1h dann 30min oder 20min mache. Daß man danach nochmal SD.begin() benötigt hatte ich schon bei anderen Spielereien rausbekommen.
@ agmue, jetzt verstehe ich Deine Frage auch wie Du sie gemeint hast.
Gruß André
SpaghettiCode:
um die Karte auch mal in jeweils festen Zeitfenstern entnehmen zu können.
Du könntest auch einen Entnahmeschalter zusammen mit einer rot-grünen LED ergänzen. Die LED zeigt an, ob eine Entnahme erlaubt ist.
Hi,
nur eine kurze Info zum Schluss: Der Nano ist zu klein, der RAM reicht nicht.
Entweder müsste ich den Logger soweit runterstricken, daß ich geplante Spielereien wie Trends nicht umsetzen kann, oder ich müsste einen der chinesischen kompakten MEGAs dafür verwenden, habe ich aber gerade nicht da ...
Ich teste zwar noch, wie weit ich ohne Array komme, aber das nimmt sich nur 120 Bytes, also ~ 6%, und ich bin jetzt schon bei 79% RAM Verbrauch, und das mit F-Makro und nur wenig Schnick-Schnack.
Was auf jeden Fall bleibt; ich habe was gelernt, Arrays befüllen und wieder auslesen gehört dazu.
Gruß André
SpaghettiCode:
... oder ich müsste einen der chinesischen kompakten MEGAs dafür verwenden, ...
Ich bin gerade über den diymore Strong Mega 2560 gestolpert, hatte ich bislang noch nicht gesehen.
Oder einen Teensy 3.2 oder 3.5, die sind 5V tolerant und haben etwas mehr Wupps. Programmierung über die erweiterte Arduino-IDE. Du kannst auch ohne Teensy testen, ob alle Bibliotheken funktionieren.
Nur so Ideen 
Hi,
ich meine eher so ein Teil, viel kompakter geht es (beim MEGA) fast nicht mehr: https://ae01.alicdn.com/kf/HTB1NAfvXzDuK1RjSszdq6xGLpXa5.jpg
Da ich noch nicht einmal auf dem Arduino sattelfest bin, möchte ich doch wenigstens in der Chip-Familie bleiben,
aber zugegeben, so ein Teensy ist interessant.
Gruß André
SpaghettiCode:
Da ich noch nicht einmal auf dem Arduino sattelfest bin, möchte ich doch wenigstens in der Chip-Familie bleiben,
aber zugegeben, so ein Teensy ist interessant.
Gerade weil Du nicht "sattelfest" bist, machst Du keine Dinge, die für die Chip-Familie spezifisch wären. Mal überspitzt: Der Blink-Sketch läuft auf dem UNO, dem Mega2560 und auch dem Teensy.
Du mußt nur wegen der 3,3 V und der 32 Bit aufpassen. Alle Typdefinitionen bedürfen der Überprüfung. Ein int hat mal 16, mal 32 Bits, da ist int16_t einheitlich.
Beim Teensy 3.5 unterstützen die Bibliotheken noch nicht die komplette Hardware, die Du auf dem Nano aber garnicht hast. Also auch kein Problem.
Viel Spaß beim Speicher- und Geschwindigkeitsrausch
SpaghettiCode:
viel kompakter geht es (beim MEGA) fast nicht mehr
Dieser Mega2560-CORE mini 2560 Arduino kompatibel ist noch etwas kleiner,
ist aber auch weniger auf der Platine, für Low-Power Anwendungen besser.
