Problem mit Tachoprogramm tiny2313

[F. P. (pl504)]

So, jetzt muß ich Euch Experten nochmal bemühen. Habe mir ein 
Tachoprogramm gebaut, das wird mit zwei Low-Flanken pro Raddrehung an 
ICP1 befeuert und zeigt die Geschwindigkeit auf einem LCD an.

Folgendes Problem:
Sporadisch springt die Anzeige kurz auf 4 oder 5 km/h, wenn Impulse 
reinkommen.

Wo liegt der Fehler?

// -------------------------------------------------------------------
// Projekt : Tacho-Test, 2 Impulse pro Raddrehung
// Taktrate: 8 MHz
// Prozessor: ATtiny2313
// -------------------------------------------------------------------

#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdlib.h>      // für itoa
#include <util/delay.h>
#include "lcd-routines.h"

#define FAKTOR 384750    // Zählrate/(Impulse pro Drehung) * 3,6 * (Radumfang in m)

volatile uint8_t impulse = 0, ende = 0, status = 0;
volatile uint16_t zahl1 = 0, zahl2 = 0xFFFF;


int main(void) {
    char puffer[4];
    uint32_t ergebnis = 0;

// Init
    PORTD |= (1<<PD6);              // Pullup ein für Impulszähler

    TCCR1B = (1<<ICNC1 | 3<<CS10);  // Rauschfilter, Teiler 64 = 125 kHz Zählrate
    TIMSK = (1<<ICIE1) | (1<<TOIE1);// Interrupt für Überlauf und ICP1

    lcd_init();
    lcd_setcursor(2, 1);
    lcd_string("0 km/h");
    sei();

    while(1) {
        if(ende) {                  // Berechnung von v, wenn Messung abgeschlossen
            ergebnis = impulse;
            ergebnis = (ergebnis << 16) + zahl2 - zahl1;
            if(!ergebnis)           // Division 0 abfangen
                ergebnis = 0xFFFF;
            ergebnis = (FAKTOR + (ergebnis >> 1)) / ergebnis; // clever runden
            ende = 0;
        }
// Begrenzung
        if(impulse > 2)
            ergebnis = 0;
        if(ergebnis > 199)
            ergebnis = 199;

        _delay_ms(250);             // Anzeige wird 4x pro Sekunde aktualisiert

// Ausgabe
        utoa((uint16_t)ergebnis, puffer, 10);
        if(ergebnis < 10) {         // einstellig (0...9 km/h)
            lcd_setcursor(0, 1);
            lcd_string("  ");
        }
        else if(ergebnis < 100) {   // zweistellig (10...99 km/h)
            lcd_setcursor(0, 1);
            lcd_string(" ");
        }
        else                        // dreistellig (100...199 km/h)
            lcd_setcursor(0, 1);
        lcd_string(puffer);
    }
}

ISR(TIMER1_OVF_vect) {
    if(impulse < 3)
        impulse++;
}

ISR(TIMER1_CAPT_vect) {
    if(!ende) {
        if(!status) {
            zahl1 = ICR1;
            impulse = 0;
            status = 1;
        }
        else {
            zahl2 = ICR1;
            ende = 1;       // Messung beendet
            status = 0;
        }
    }
}

[Karl H. (kbuchegg)]

Hmm

Deine Einrechnung der Overflows

            ergebnis = impulse;
            ergebnis = (ergebnis << 16) + zahl2 - zahl1;

ist falsch.
Wenn zahl2 kleiner als zahl1 ist (es also mindestens 1 Overflow gab), 
dann zählst du einen Overflow zu viel.

(Annahme: es gab genau einen Overflow)
Der springende Punkt ist, dass durch die Differenzbildung Ende - Anfang 
mittels unsigned Rechnung, du 1 Overflow nicht berücksichtigen 
musst/brauchst. Solange deine Timerwerte so sind, dass du nicht mehr als 
65535 Timerticks zählen musst, kommt durch die unsigned Subtraktion 
IMMER das richtige Tick-Differenz-Ergebnis raus, selbst wenn da 1 
Overflow dazwischen lag.

Ich hab jetzt die Zahlen nicht kontrolliert und nachgerechnet. Aber 
durch den einen zuviel gezählten Overflow, kriegst du eine zu lange Zeit 
als Messergebnis und dadurch eine zu geringe Geschwindigkeit.
Frage: kann es dir überhaupt passieren, dass dein Messergebnis den Wert 
65535 übersteigt? Jetzt rein rechnerisch. Oder anders gefragt: Wie 
schnell (bzw. langsam) müsstest du fahren, damit Endzeitpunkt - 
Startzeitpunkt überhaupt größer als 65535 werden kann?
Denn wenn da jetzt 0.5km/h raus kommen, dann kannst du dir die ganze 
Overflow Berücksichtung in der Berechnung komplett sparen. Du benutzt 
den Overflow dann nur noch dazu um den Stillstand zu detektieren, alles 
an Geschwindigkeit kleiner als 0.5km/ definierst du als Stillstand und 
zeigst am Tacho 0 an. Aber wie gesagt: ich hab die Rechnerei nicht 
gemacht und nicht nachgesehen, was da für Zahlen raus kommen.

[Max H. (hartl192)]

Karl Heinz schrieb:
> selbst wenn da 1
> Overflow dazwischen lag.
Das mit dem Overflow habe ich vorgestern hier erklärt:
Beitrag "Re: Capture Mode mit PIC18F46k80"

[F. P. (pl504)]

Karl Heinz schrieb:
> Deine Einrechnung der Overflows
>

>             ergebnis = impulse;
>             ergebnis = (ergebnis << 16) + zahl2 - zahl1;
>

>
> ist falsch.
> Wenn zahl2 kleiner als zahl1 ist (es also mindestens 1 Overflow gab),
> dann zählst du einen Overflow zu viel.
>
> (Annahme: es gab genau einen Overflow)
> Der springende Punkt ist, dass durch die Differenzbildung Ende - Anfang
> mittels unsigned Rechnung, du 1 Overflow nicht berücksichtigen
> musst/brauchst. Solange deine Timerwerte so sind, dass du nicht mehr als
> 65535 Timerticks zählen musst, kommt durch die unsigned Subtraktion
> IMMER das richtige Tick-Differenz-Ergebnis raus, selbst wenn da 1
> Overflow dazwischen lag.
kopfkratz
Habe jetzt die Berücksichtigung der Überläufe rausgenommen. Damit haut 
es hin. Kann es nur noch nicht zu 100 % nachvollziehen. 
Mindestgeschwindigkeit liegt dann bei ca. 7 km/h, das ist OK.

Angenommen, es gab 2 Überläufe und zahl2 = 4, zahl1 = 100:
ergebnis = 131072 + 4 - 100 = 130976
Klingt für mich plausibel. Oder muß man "(ergebnis <<16) + zahl2" in 
Klammern setzen, damit der Compiler nicht fälschlicherweise erst "zahl2 
- zahl1" (vorzeichenlos) rechnet?