Probleme mit IF-Abfrage / Timer

[sternst]

Du meinst also das cli(); sollte besser noch eine Zeile früher kommen?

Könnte man so machen, aber dann muss man auch das sei() aus dem if raus ziehen, weil ja sonst die Interrupts im False-Fall abgeschaltet blieben. Ich persönlich würde das nicht machen, weil dann nämlich im True-Fall die Interrupts viel länger abgeschaltet wären, als nötig. Das muss keine Auswirkungen haben (hätte es in diesem einfachen Fall auch nicht), aber besser man gewöhnt sich gleich an, Interrupts immer nur so kurz wie möglich abzuschalten. Bei mir sähe es in etwa so aus:

#include <util/atomic.h>
   
 
void make_time (void) {

    int16_t tmp_msec;

    ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {
        tmp_msec = g_msec;
    }

    if (tmp_msec > 999) {

        ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {
            g_msec -= 1000;
        }

        g_sec++;
        g_send=1;
        PORTA ^= (1 << PINA0);
        if (g_sec > 59){
            g_sec = 0;
            g_min++;
            PORTA ^= (1 << PINA1);
            if (g_min > 59){
                g_min = 0;
                g_h++;
                PORTA ^= (1 << PINA2);
                if (g_h > 23){
                    g_h = 0;
                    g_d++;
               }
            }
        }
    }
}

[TobiKa]

Ja, das ist schon klar.

Aber wie gesagt, ich würde alles in den Interrupt rein packen.

[sammler]

Hi ihr beiden!

Danke euch für eure Unterstützung!

@Sternst: Vielen, vielen dank für diese Erklärung! Das wird mich vermutlich in Zukunft vor solchen Problemen bewahren.
ich hab befürchtet, dass ich was prinzipiell einfaches übersehen hab...

ATOMIC_BLOCK(ATOMIC_FORCEON){
...
}

ist das selbe wie

cli();
... 
sei();

oder? Nur, dass ich nicht noch "util/atomic.h" include (wenn ich die Datei richtig lese...).

@TobiKa: An der Hochschule hat man mir eingebleut, dass Interruptroutinen so kurz wie nur irgendmöglich sein sollen. Daher hab' ich die (unkritischen) Teile aus der Routine herausgelöst...
Und wenn ich es in den Interrupt lege sehe ich auch keinen echten Vorteil...

[sternst]

ist das selbe wie

Nun, fast.
ATOMIC_BLOCK bietet einen besseren Schutz gegen Code-Reordering. Und es stellt sicher, dass die Interrupts wieder eingeschaltet werden, egal auf welchem Exit-Pfad der Code-Block verlassen wird (du kannst sogar ohne Probleme "return" innerhalb des Blockes verwenden).

[TobiKa]

@TobiKa: An der Hochschule hat man mir eingebleut, dass Interruptroutinen so kurz wie nur irgendmöglich sein sollen. Daher hab' ich die (unkritischen) Teile aus der Routine herausgelöst...
Und wenn ich es in den Interrupt lege sehe ich auch keinen echten Vorteil...

Ja da hast du schon recht, aber 3 Abfragen und 3 Zuweisungen sollten kein Problem sein.
Ich sehe bei deiner Variante Probleme falls "UART" mal länger braucht und g_msec irgendwann überläuft.