Freuqenz auswerten

Es gibt im Forum, in der Codesammlung und auch hier
http://www.mikrocontroller.net/articles/AVR_Softwarepool

unzählige Beiträge zum Thema Frequenzmessung.

Welche hast du denn schon studiert?

wiss schrieb:
> Ich habe es mit diesem Quelltext versucht, jedoch ich konnte nur
> Frequenzen zwischen 0 und 50 khz ohne Probleme auswerten, alles was
> darüber ist, funktioniert nicht mehr richtig.
> Liegt es vielleicht am atmega 8?

Wie schnell taktest du den?

Die Messung am INTO wird irgendwann schlapp machen.
Aber die Messung am Input Capture sollte mit 500kHz eigentlich noch so 
lala klar kommen.

Allerdings denke ich, dass in dem Code noch Fehler sind. Ich 
konzentriere mich jetzt nur auf den Input Capture.

1

ISR( TIMER1_CAPT_vect )

2

{

3

 static unsigned char ErsteFlanke1 = TRUE;

4

5

 if( Update1 && Update0 )

6

  return;

ändern auf

1

ISR( TIMER1_CAPT_vect )

2

{

3

 static unsigned char ErsteFlanke1 = TRUE;

4

5

 if( Update1 )

6

  return;

--------------------------------

Die Overflow Behandlung ist auch nicht korrekt. Etwas abhilfe (auch wenn 
es noch nicht ganz korrekt ist), würde bringen:

1

     Erg1 = (NumberOverflow1 * 65536) + EndTime1 - StartTime1;

ändern auf

1

     if( NumberOverflow1 > 1 )

2

       Erg1 = (NumberOverflow1 * 65536) + EndTime1 - StartTime1;

3

     else

4

       Erg1 = EndTime1 - StartTime1;

Woran machst du fest, dass die Ergebnisse nicht stimmen?

Im übrigen ist das Messprinzip in beiden Fällen hier die Messung der 
Periodendauer. Diesem Messprinzip ist es zu eigen, dass die 
Messauflösung schlechter wird, je höher die Frequenzen werden.
Bei deinen Frequenzen (wie weit geht die Frequenz eigentlich runter, 
wenn der Sensor anspricht), wäre wahrscheinlich eine Zählung der Pulse 
in einer Torzeit besser geeignet (da wird die Messauflösung schlechter, 
je niedriger die Frequenzen werden)

Marc schrieb:

> könntest du mir erklären, wieso das nicht korrekt ist? Ich sehe darin
> keinen Fehler (aber ich täusche mich wohl) und möchte nun dazu lernen

Weil die Differenz zweier unsigned Werte in diesem Fall auch bei 1 
Overflow das korrekte Ergebnis bringt. Erst wenn ein zweiter Overflow 
dazukommt muss man handeln.

Wobei auch das noch immer nicht korrekt ist, wenn ich es mir recht 
überlege

Die Logik muss sein:
  1 Overflow wird ignoriert, wenn Ende kleiner als Start ist. Ist Ende 
größer/gleich stimmt die Anzahl der Overflows.

Probiers einfach mit kleineren Zahlen durch
Sagen wir Start und Ende können nur Werte von 0 bis 7 annehmen.

  Start sei zb 5

jetzt geben wir dazu noch 4 Zählticks dazu

  Start            5
         (Tick 1)  6
         (Tick 2)  7
         (Tick 3)  0           <- Hier gibt es den ersten Overflow
         (Tick 4)  1

Wir haben also
   Start:            5
   Ende:             1
   Anzahl Overflows: 1

unsigned gerechnet: Ende - Start:   1 - 5    macht 4
                    Overflows:      1*8      macht 8
                                               ------
                                                  12

d.h. so gerechnet, würde bei der Messung rauskommen, dass 12 Ticks 
gezählt wurden. Wir hatten aber nur 4. 1 Overflow wurde zuviel 
eingerechnet

Jetzt das ganz mal mit 9 Ticks vom Start bis zum Ende

      Start:            5
              (Tick  1) 6
              (Tick  2) 7
              (Tick  3) 0          <--- Hier ist der erste Overflow
              (Tick  4) 1
              (Tick  5) 2
              (Tick  6) 3
              (Tick  7) 4
              (Tick  8) 5
              (Tick  9) 6

Unsere gemessenen Kennzahlen sind also:
   Start:            5
   Ende:             6
   Anzahl Overflows: 1

ausgewertet ergibt das

                    Ende - Start:   6 - 5    macht 1
                    Overflows:      1*8      macht 8
                                               ------
                                                   9

Jetzt stimmt die Rechnung. Dieser 1 Overflow darf nicht ignoriert 
werden.
Das Kriterium ist, ob Ende größer/gleich Start ist. Ist das der Fall, 
dann stimmt die Anzahl der Overflows und muss eingerechnet werden. Ist 
das aber nicht der Fall (wie im ersten Beispiel) dann wurde zwar ein 
Overflow detektiert, der sich aber durch die unsigned Rechnung nicht 
auswirkt. Wir müssen also mit 1 Overflow weniger rechnen.


(Das ganze dann natürlich sinngemäs hochskaliert, wenn mehrere Overflows 
auftauchen)

1

     if( EndTime1 < StartTime1 )

2

       NumberOverflow1--;

3

4

     Erg1 = (NumberOverflow1 * 65536) + EndTime1 - StartTime1;

Wenn du dir leichter tust, dann stell dir eine Uhr vor (damit sind wir 
vertrauter). Wieviele Sekunden sind vergangen, wenn der Sekundenzeiger 
von 55 bis 12 gelaufen ist? Genau. Der Sekundenzeiger ist zwar über die 
60 drübergelaufen (und hat damit 1 'Overflow' registriert), aber das 
spielt hier keine Rolle, es sind trotzdem nur 17 Sekunden vergangen. Ist 
der Sekundenzeiger aber von 15 ... tick, tick, tick, über die Minute 
drüber, tick, ... bis 20 gelaufen, dann sind das 65 Sekunden und der 
eine Overflow über die 60 Sekunden drüber wirkt sich aus.