DUE Verschluckt sich ab und zu

International Deutsch
1

Hallo,

Habe hier paar Zeilen welche Optimierungsbedarf haben.

Leider verschluckt der DUE ab und an mal dieses Ereignis

  if (hour() == 00 && minute() == 00 && second() == 00 && dayrotate == 0)
  {
    if (nosdcard == 0) {
      getFileName();
      createFileName();
    }
    addLogEntry(dayStr(weekday()));  //neuer tag im Log
    setlogday(); // Wert 1-3
    sprintf(buflogday, "Logday: %02d", getlogday());
    addLogEntry(buflogday);  //neuer tag im Log
    dayrotate = 1;
  }

  if (hour() == 00 && minute() == 00 && second() == 01 && dayrotate == 1)
  {
    dayrotate = 0;
  }

wie könnte ich das umstricken das wenn er das ganz sicher ausführt... falls er mal wegen etwas rechenintensivem zu diesem Zeitpunkt blockiert wurde

2

wie könnte ich das umstricken das wenn er das ganz sicher ausführt... falls er mal wegen etwas rechenintensivem zu diesem Zeitpunkt blockiert wurde

Üblicherweise merkt man sich, wann etwas zuletzt passiert ist (hätte passieren sollen), und wenn seitdem ein Zyklus vorbei ist, macht man es wieder. (BlinkWithoutDelay lässt sich etwas verfeinern, um nicht bei Verzögerungen wegzudriften)

Etwas schwieriger wird es, wenn du auf Uhrzeiten, die asynchron modifiziert werden könnten, angewiesen bist. Dein dayrotate ist schonmal nicht verkehrt. Wenn du aber Aussetzer von einer ganzen Sekunde Dauer oder mehr hast, reicht es nicht ganz.

  static bool dayrotate;
  if (hour() == 00 && minute() == 00 && dayrotate == false)
  {
    daily_task();
    dayrotate= true; 
  }

  if (minute() != 0 ) dayrotate = false;

So hast du eine Minute Zeit für deinen daily_task.

3

Ist zwar nicht der Fehler hier, aber sei vorsichtig bei führenden Nullen mit Integer Lateralen. Das bedeutet dass die Zahl Oktal ist. Bei 0 oder 1 spielt das keine Rolle, aber Zahlen > 7 macht das nicht was du willst

4

Herzlichen Dank, habs geändert. Jetzt mal beobachten :slight_smile:

@Serenifly Wie mach ich das Richtig?

5

@Serenifly Wie mach ich das Richtig?

Vielleicht mal dem Serenifly aufmerksam zuhören!

Wenn der sagt: "Führende Nullen sind u.U. ein Problem!"
Dann kannst du ihm glauben.
Ich stimme ihm zu.

Jetzt klarer?
Nee ....?

Dann:
Aus der Ansage von Serenifly lässt sich folgende Handlungsanweisung ableiten:
"Lass die führende Null weg!"

6

"Ihm glauben" ist nicht verkehrt.
Raten oder forschen was er wohl gemeint haben könnte, bringt einen aber weiter.

Das bedeutet dass die Zahl Oktal ist.

Ich habs jetzt grade nicht ausprobiert, nur mal als Tip für weitere Experimente:

Serial.println(01234); // Ausgabe:  668 !

Das ist übrigens kein Bug, weder im Arduino, noch im im SerialMonitor :wink:

7

mpl1337:
@Serenifly Wie mach ich das Richtig?

Führende Nullen bei Literalen weglassen? Also 0 statt 00 und 1 statt 01

Ist wie gesagt hier noch kein Fehler, aber 08 oder 010 z.B. wären falsch

8

Ok, die timelib.h Funktionen wie day() month() hour() usw liefern aber eben wie 0 immer mit... ich kann ja jetzt nicht alt bewährte libs umändern. Oder gibt es "etwas" um das zu entschärfen?

9

die timelib.h Funktionen wie day() month() hour() usw liefern aber eben wie 0 immer mit...

:o Das hast du dir aber nur mal eben so zwischendurch ausgedacht! :o

Siehe dazu die Vorwärtsdeklaration von hour():

int     hour();            // the hour now
10

liefern aber eben wie 0 immer mit

Nein. 0 ist 0. Du darfst das nicht mit der Serial Ausgabe verwechseln. Wenn du das per sprintf() so formatierst dass führende Nullen gedrückt werden hat das rein gar nichts damit zu tun wie die Zahl im Contoller gespeichert wird.

11

uh sry okay :smiley: okay nehme alles zurück und bin ruhig :zipper_mouth_face: