- LiFePO4 Speicher Test         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

Thema: Probleme mit IF-Abfrage / Timer

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    17.12.2005
    Ort
    Untermain
    Beiträge
    58

    Probleme mit IF-Abfrage / Timer

    Anzeige

    LiFePo4 Akku selber bauen - Video
    Hallo Leute,

    nach etlichen Versuchen und mittlerweile leicht verzweifelt, muss ich mich wohl geschlagen geben und einfach mal um Hilfe bitten

    Ich versuche derzeit mich nach und nach (wieder) in die Programmierung einzuarbeiten (echt erschreckend, wie viel man in 4 Jahren vergessen kann...).
    Soweit komme ich ja ganz gut zurecht, und dank Datenblatt, RN-Wissen und mikrocontroller.net komme ich eigentlich auch mit den Timern und den ganzen anderen Registern klar.
    Nur will mir jetzt offenbar eine popelige IF-Abfrage den Spaß verderben.

    Folgendes Phänomen kann ich beobachten:
    Ich habe einen einfachen CTC-Interrupt auf Timer0 meines AT-Mega32 programmiert, der mir alle Millisekunde eine 16-bit-Variable g_msec inkrementiert.
    Wird g_msec > 1000 soll g_sec inkrementiert werden:
    Code:
        
    void make_time(void){
        if (g_msec > 999) {
            cli();
            if (g_msec < 1000){
            g_msec++;
            }
            g_msec -= 1000;
            sei();
            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++;
                   }
                }
            }
        }
    }
    Blöderweise springt er mir der Befehlspointer aber manchmal auch bei kleineren Werten als 1000 in die Schleife:
    unten im Bild der Wert der geprüften Variable...
    Der Aufruf der Funktion erfolgt in der Hauptschleife in main.c:

    Code:
    #include <avr/io.h>     // Namen der IO Register
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <util/delay.h> // Funktionen zum Warten
    #include <avr/wdt.h>
    #include <avr/interrupt.h>
    #include <avr/pgmspace.h>
    
    #include "raupe.h"
    #include "uart.h"
    #include "scheduler.h"
    
    int main(void)
    {
        /**
         * Stammfunkion.
         * Ruft alle anderen Programmteile auf. */
    
        unsigned int c;
        char buffer[20];
        char command[20];
        command[0] = '\0';
    
    
        startup_diag();
        sei();
        init_scheduler();
    
        PORTA = ( 1 << PINA3 ); // Pullups auf Eingangs-Pins
        DDRA |= ( 1 << PINA0 ); // PINA0 als output,  _BV(0) = (1<<0) = 1
        DDRA |= ( 1 << PINA1 ); // PINA1 als Output
        DDRA |= ( 1 << PINA2 ); // PINA2 als Output
    
        while (1)
        {
        make_time();
    
            /*
             * Get received character from ringbuffer
             * uart_getc() returns in the lower byte the received character and
             * in the higher byte (bitmask) the last receive error
             * UART_NO_DATA is returned when no data is available.
             *
             */
            c = uart_getc();
            if ( c & UART_NO_DATA )
            {
                /*
                 * no data available from UART
                 */
                //i = 0;
            }
            else
            {
                /*
                 * new data available from UART
                 * check for Frame or Overrun error
                 */
                 if ( c & UART_FRAME_ERROR )
                 {
                     /* Framing Error detected, i.e no stop bit detected */
                     uart_puts_P("UART Frame Error: ");
                 }
                 if ( c & UART_OVERRUN_ERROR )
                 {
                     /*
                      * Overrun, a character already present in the UART UDR register was
                      * not read by the interrupt handler before the next character arrived,
                      * one or more received characters have been dropped
                      */
                     uart_puts_P("UART Overrun Error: ");
                 }
                 if ( c & UART_BUFFER_OVERFLOW )
                 {
                     /*
                      * We are not reading the receive buffer fast enough,
                      * one or more received character have been dropped
                      */
                     uart_puts_P("Buffer overflow error: ");
                 }
                 if (!((c=='\0')||(c=='\n'))&&(i<sizeof(command))){
                     command[i] = (unsigned char)c;
                     command[(i+1)] = '\0';
                     i++;
                 }
                 else if (c=='\n') {
                     i=0;
                 }
            }
    
            if (!strcmp(command, "time") || (g_send)) {
                sprintf(buffer, "\nT: %02d:%02d:%02d.%04d\n", g_h, g_min, g_sec, g_msec);
                uart_puts(buffer);
                command[0]=(int)"\0";
                g_send=0;
            }
    
        }
        // Programm-Ende - sollte nicht erreicht werden...
    }
    Fuses: 0x09(High) 0x7F(Low); komplettes Programm im Anhang.

    Wäre super, wenn ihr mir auf die Sprünge helfen könntet!

    Gruß,
    sammler

    PS: der Wert von g_msec, wenn er fälschlich reinspringt, ist offenbar immer 768 (dez.)...
    Angehängte Dateien Angehängte Dateien
    Geändert von sammler (24.04.2011 um 20:16 Uhr)

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    25.04.2010
    Beiträge
    1.249
    Code:
    if (g_msec < 1000){
            g_msec++;
    Das kann nie zutreffen, wenn du vorher
    Code:
    if (g_msec > 999) {
    kontrollierst.

    Du hast deine Timerroutine leider nicht gepostet, aber da g_msec signed ist und sie einfach nur hochgezählt wird (so hast du es jedenfalls geschrieben) dann kann der Wert auch weit größer als 1000 und sogar negativ sein, in dem Moment in dem du sie abfragst. Und dann wirst du Probleme kriegen.

    Ich würde die ganze Berechnung mit in die Interrupt Routine reinbringen und die Werte ( Stunden, Minuten, Sekunden) in drei volatile Variablen speichern, so kannst du sie jederzeit abrufen. Aber ist nur ein erster Gedanke

  3. #3
    Benutzer Stammmitglied
    Registriert seit
    17.12.2005
    Ort
    Untermain
    Beiträge
    58
    Du hast offenbar etwas übersehen. Die von dir erwähnte abfrage TRIFTT dummerweise zu, wie du dem Screenshot entnehmen kannst.
    Dass
    Code:
    if (g_msec < 1000) {}
    nach
    Code:
    if (g_msec > 999) {}
    nicht zutreffen DARF, ist mir schon auch klar...
    die Zeile entsprang nur meiner verzweiflung; und da die inkrementierung leider mehr als einmal aufgeführt wurde, versuche ich jetzt herauszufinden, wie es dazu kommen kann...
    vielleicht flackert ja ein Bit im RAM, aber ich halte das für ehr unwahrscheinlich...

    nachdem ich den ganzen µC jetzt noch einmal komplett gelöscht und auch die Fuses einmal (bis auf SPIEN) nicht gesetzt programmiert habe, bevor ich wieder zurück gewechselt habe, scheint der Fehler nicht mehr sehr häufig aufzutreten...
    ich habe die "debug-Prüfung" etwas angepasst:
    Code:
            if (g_msec < 1000){
            g_fail++; // volatile, int16
            }
    g_fail wird jetzt außerdem mit ausgegeben, die entsprechende Zeile (in main.c) ist:
    Code:
    sprintf(buffer, "\nT: %02d:%02d:%02d.%04d   %04d\n", g_h, g_min, g_sec, g_msec, g_fail);
    der Wert ist bei Laufzeit 00:01:04 (hh, mm, ss) des Programms auf 1 gesprungen (ja, wird immer mit 0 initialisiert) und mehr als eine Stunde so geblieben... scheint also ein (mittlerweile) ehr seltenes Phänomen zu sein... (das ist so auch reproduzierbar, er macht das immer wieder zu dem Zeitpunkt und dann geht es zumindest bisher ohne diesen Fehler weiter, bis ich neustarte)

    Der Code der Timerroutine ist übrigens im Anhang dabei, ist aber auch nix weltbewegendes:
    Code:
    ISR(TIMER0_COMP_vect)
    {
       // hier wird der msec-zähler gesetzt. Die übrigen
       // Programmteile müssen diese Aenderung "sehen":
       // volatile -> aktuellen Wert immer in den Speicher schreiben
       g_msec++;
    }
    zu früh gefreut:
    00:01:43.-232 0003
    Geändert von sammler (23.04.2011 um 17:56 Uhr)

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    25.04.2010
    Beiträge
    1.249
    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?

  5. #5
    Benutzer Stammmitglied
    Registriert seit
    17.12.2005
    Ort
    Untermain
    Beiträge
    58
    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).

  6. #6
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    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.
    Geändert von sternst (24.04.2011 um 00:04 Uhr)
    MfG
    Stefan

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    25.04.2010
    Beiträge
    1.249
    Du meinst also das cli(); sollte besser noch eine Zeile früher kommen?

  8. #8
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    Zitat Zitat von TobiKa Beitrag anzeigen
    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:
    Code:
    #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++;
                   }
                }
            }
        }
    }
    MfG
    Stefan

  9. #9
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    25.04.2010
    Beiträge
    1.249
    Ja, das ist schon klar.

    Aber wie gesagt, ich würde alles in den Interrupt rein packen.
    Geändert von TobiKa (24.04.2011 um 13:42 Uhr)

  10. #10
    Benutzer Stammmitglied
    Registriert seit
    17.12.2005
    Ort
    Untermain
    Beiträge
    58
    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...

    Code:
    ATOMIC_BLOCK(ATOMIC_FORCEON){
    ...
    }
    ist das selbe wie
    Code:
    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...

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. interne pull up widerstand/ probleme mit der tasten abfrage
    Von Asuro91 im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 4
    Letzter Beitrag: 06.06.2010, 14:36
  2. problem mit button-abfrage im timer (c#)
    Von Roboman93 im Forum Open Source Software Projekte
    Antworten: 4
    Letzter Beitrag: 29.12.2008, 17:40
  3. Probleme mit Timer und ATMega 32
    Von steffen21m im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 07.01.2008, 19:17
  4. Radencoder- und Timer-Probleme
    Von Speedking im Forum C - Programmierung (GCC u.a.)
    Antworten: 0
    Letzter Beitrag: 26.07.2006, 22:18
  5. Anfängerfrage: Timer-Abfrage beim PIC 10F206???
    Von JayCool im Forum PIC Controller
    Antworten: 2
    Letzter Beitrag: 07.06.2006, 10:23

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Labornetzteil AliExpress