Probleme mit IF-Abfrage / Timer

[TobiKa]

Nein, das habe ich nicht übersehen.

Und wieso ignorierst du alles was ich zum Typ von g_msec und der Möglichkeit das es negativ sein kann geschrieben hab?

[sammler]

Hi Tobi

Dass g_msec signed ist, stammt daher, dass die Variable zum teil (weil die Abfrage mal wieder gesponnen hat) in den Bereich 65xxx gejagt wurde, als sie noch unsigned war.
Und DA gab es dann natürlich Probleme, weil die Abfrage ständig zutraf, was zu einer ehr ungünstigen dauerinkrementierung der g_sec Variablen geführt hat, wodurch die "Uhr" erstmal gründlich vorging.
Aufgrund der (derzeitigen) Auslastung des µC bekomme ich mit der aktuellen Version faktisch keine Probleme, weil die Routine mehr als 1x in der Sekunde aufgerufen wird...
negative Zahlen sind für die Abfrage grundsätzlich unproblematisch - es dauert nur länger, bis sie wieder zuschlägt (bei mir meist 232 ms, wenn die vorherige Runde wieder einmal schiefging).

[sternst]

if (g_msec > 999)
...
PS: der Wert von g_msec, wenn er fälschlich reinspringt, ist offenbar immer 768 (dez.)

Du hast schlicht ein Atomizitäts-Problem. g_msec ist größer als ein Byte, und damit kann der Vergleich nicht atomar sein. Er besteht aus mehreren Maschinenbefehlen und der Interrupt kann da mitten rein fallen. Was ganz genau passiert, ist folgendes:
- g_msec ist 767 (0x02ff) wenn der Vergleich beginnt.
- Zuerst wird das Low-Byte genommen (0xff).
- Jetzt kommt der Interrupt und ändert g_msec von 767 (0x02ff) auf 768 (0x0300).
- Der Vergleich macht weiter mit dem High-Byte (0x03).
- Ergebnis des Vergleichs: True, weil 1023 (0x03ff) größer ist als 999.

[TobiKa]

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

[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...