Während das Programm in der ISR ist läuft der Zähler schon für den 
nächsten Timer weiter, d.h. du darfst in der ISR nur so viel Code 
ausführen wie zeitlich zwischen zwei Timer-Interrupts passt.

Was willst du eigentlich messen?

Dein Programm, bzw. die Programmidee ist ziemlich wirr. Für mich ist da 
nicht wirklich erkennbar, was eigentlich gemessen werden soll.


ICP ist gut, aber ob du die Rundenzeit eines Autos auf +- 1 
Zehntausendstel Sekunden genau feststellst oder +- deren 2, spielt dann 
nicht wirklich die grosse Rolle. Das kriegt man in dem Fall sicherlich 
auch ohne ICP hin. Dafür allerdings auf 5 Kanälen, solange nur sicher 
gestellt ist, dass die Durchfahrten der Autos auseinandergehalten werden 
können.

Harry schrieb:

> @Karl Heinz Buchegger
>> Was willst du eigentlich messen.
> Eine Anzahl von Pulsen(15,5 kHz - 2,2kHz) in einer bestimmten
> Zeit(5-10ms)

Ah!
Du willst erst mal nur feststellen, welches Auto da über den Sensor 
gerauscht ist?

OK.
MWS hats ja schon gesagt.
Ein Timer wird nicht dadurch gestartet oder gestoppt, in dem du seinen 
Overflow Interrupt freigibst.

Bei dir läuft der Timer ständig, d.h. es ist bei dir mehr oder weniger 
zufällig, wieviele Pulse in der Zeit vom ersten Puls bis zum Overflow 
eintreffen.

Wenn der erste Puls kommt, musst du den Timer definiert bei 0 wegzählen 
lassen! Erst dann hast du deine definierte Zeit bis zum Overflow.

Oder du lässt deinen Timer überhaupt einfach durchlaufen und vergleichst 
die Zählerstände bei 2 aufeinanderfolgenden Interrupts.

Da du ja die Frequenzen kennst, musst du nicht aufs Hz genau messen. Ein 
kleiner Fehler spielt zur Fahrzeugerkennung keine große Rolle.

Harry schrieb:
> MWS schrieb:
>> Oder Periodenzeitmessung, wobei im worst-case bei 4 konkurrierenden
>>
>> Signalen, also 4 Autos gleichzeitig, eine ausreichend genaue Messung der
>>
>> Periodendauer stattfinden muss.
>
> Das arbeite ich gerade aus. Dauert aber länger muss mir das erst mit DB
> erabeiten ;-)

Aus dem Bauch heraus würde ich mal folgende Fragen angehen:

Bei den gegebenen Auto-Frequenzen und den möglichen Vorteilern, wie weit 
kann ein Zähler in der Zeit zwischen 2 Pulsen zählen. Und zwar bei allen 
auftretenden Frequenzen.

Ziel ist es, den Vorteiler zu finden, so dass der Timer in der Zeit 
zwischen 2 Pulsen nicht "überläuft" UND die festgestellten 
Timer-differenz-werten sich bei den jeweiligen Autofrequenzen stark 
genug unterscheiden, so dass sie eindeutig und sicher 
auseinandergehalten werden können.

Ich denke weiters, dass du mit dem 8-Bit Timer nicht weit kommen wirst. 
Ein Zählumfang von 0 bis 255 ist nun mal nicht besonders gross, wenn man 
~15khz von ~2khz nur anhand der Periodendauer auseinanderhalten soll UND 
in die Zählerstände nach Möglichkeit die Overflows nicht eingerechnet 
werden sollen (vereinfacht das Handling insgesamt).

Harry schrieb:
> @Karl Heinz Buchegger
>   danke für den Hinweis hab mal etwas gerechnet:
>
> FCPU=16Mhz, prescaler=0, 16MHz/256

welches ist der nächst kleinere Prescaler? Hast du zb 64 zur Verfügung?

> [CAR1] kürzeste Periode 1/15,62kHz = 64us /16us = 4
> [CAR7] längste  Periode 1/2,232kHz = 448us/16us = 28
> [CAR6]                               384us/16us = 24

> Sollte ich alles richtig verstanden haben würde das so funktionieren
> oder?

Könnte hinkommen. Da dein Timer durchläuft, sollte man auch noch einen 
Zählfehler von +-1 mit einkalkulieren. du hast dann anstellt von 28 und 
24, die Werte 27 und 25. Sollte noch unterscheidbar sein, aber dann darf 
nicht mehr viel passieren.
Wenn du zb einen Prescaler von 64 hast, dann hast du 4-fache Werte.

  112   zu  96

da jetzt noch einen Zählfehler von +-1 eingerechnet, sind wir bei 111 zu 
97 und da gibt es dann schon einen viel schöneren Grenzwert in der 
Mitte, zu dem die erwarteten Ergebnisse einen ordentlichen Abstand 
haben.


112 ist immer noch nicht Ende der Fahnenstange. Bei einem Vorteiler von 
32 wäre der Wert 224. Hast du 32 zur Verfügung?

Harry schrieb:
> Karl Heinz Buchegger schrieb:
>> welches ist der nächst kleinere Prescaler? Hast du zb 64 zur Verfügung?
>
> Ich verwende doch schon den kleinsten prescaler = 0

1. Bei einem Prescaler von 0 steht der Timer.

Trotzdem.
Mein Fehler.

>1. Bei einem Prescaler von 0 steht der Timer.
Ja klar mein Fehler div/0 und so ;-)

Hab alles mal etwas umgeschrieben aber jetzt kommt nur noch unsinn:

//#define F_CPU  16000000
#define LOOP  1

#include <stdio.h>
#include <stdlib.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include "usart/usart.h"

volatile unsigned long int startTime = 0;
volatile unsigned long int stopTime = 0;
volatile unsigned long int count = 0;
unsigned long int newWert = 0;

void display();
void initIo();

SIGNAL (INT0_vect)
{
  startTime = stopTime;
  stopTime = TCNT0;
  count++;
}

//SIGNAL (TIMER0_OVF_vect)
//{
//  timerOVF++;
//}

int main()
{
  unsigned long int lastWert = 0;
  
  initIo();
  sei();

  while(LOOP)
  {    
    if(count == 2)
      cli();

    lastWert = newWert;

    if(stopTime < startTime)
      newWert = 256 + stopTime - startTime;
    else
      newWert = stopTime - startTime;
    
    stopTime = 0;
    startTime = 0;

    if(lastWert != newWert)
      display();
    
    sei();
  }
  return 0;
}

void display()
{
  char Buffer[20];
  itoa( newWert, ( char* ) Buffer, 10 );
  Oputs(( char* ) Buffer);
  Oputs(" \r\n");
}

void initIo()
{  
  InitUart();
  Oputs("UART Init 9600 Baud\r\n");
  EICRA |= (1<<ISC01) | (1<<ISC00);  // Steigende Flanke von INT0 als auslöser
  EIMSK |= (1<<INT0);          // Interruptmaske
  EIFR |= (1<<INTF0);
    TCCR0B |= (1<<CS00);           // Timer 0 mit Prescaler 0 (16000000/0)/256 Hz = 62,5kHz = 1/62,5kHz s = 16us2604
//  TIMSK0 |= (1<<TOIE0);        // Timer0 Interrupt einschalten
}

Kann mir wer sagen ob ich da was grundlegendes falsch mach?

MfG
Harry

Zumindest 2 Dinge fallen mir auf:
- nach dem "if(count == 2)" fehlen die Klammern für einen Block
- count wird nicht zurückgesetzt.

Und ein paar Kleinigkeiten:
- stopTime und startTime braucht nicht auf 0 gesetzt werden, da die 
beiden Variablen eh bei jedem Interrupt gesetzt werden.
- Im Interrupt würde ich die Start und Stop-Zeiten nur dann setzen, wenn 
es auch nötig ist.
- Nicht auf Gleichheit (count == 2) prüfen, besser auf größer gleich 
prüfen, vermeidet bei Problemfälle

Damit ergeben sich folgende Änderungen:

SIGNAL (INT0_vect)
{
  if(count<2) {
    startTime = stopTime;
    stopTime = TCNT0;
    count++;
  }
}

...

    if(count >= 2)
    {
      cli();

      lastWert = newWert;

      if(stopTime < startTime)
        newWert = 256 + stopTime - startTime;
      else
        newWert = stopTime - startTime;
    
      count = 0;

      if(lastWert != newWert)
        display();
    
      sei();
    }

Morgen,

Volkmar Dierkes schrieb:
> Zumindest 2 Dinge fallen mir auf:
>
> - nach dem "if(count == 2)" fehlen die Klammern für einen Block
>
> - count wird nicht zurückgesetzt.

Danke für deine hilfe habe ich selbst schon bemerkt und den rest hab ich 
angepasst. Leider ohne sichtlichem Erfolg:

DEBUG AUSGABE:
96 result, 2 count, 0 startTime, 96 stopTime
250 result, 2 count, 96 startTime, 90 stopTime

Das ist die Ausgabe der 15,6kHz Quelle! (result sollte eigentlich 4 
sein. 4*16 = 64us)

Jetzt stellt sich mir die frage, ob der uC überhaupt mitkommt. In dem 
Projekt vom slotbaeren wurden nämlich 20MHz Takt benutzt.

Macht es sinn den 16bit timer zu nehmen um mehr "Timer counts" zu 
bekommen?
Ich glaub nicht darann, dass das nur mit ICP zu lösen ist!

mfg
Harry

> volatile unsigned long int startTime = 0;

runter mit den Datentypen.
uint8_t reicht völlig. Du hast es nur mit 8 Bit Zahlen zu tun!


Und wenn du das hast, braucht es auch die Unterscheidung hier nicht

      if(stopTime < startTime)
        newWert = 256 + stopTime - startTime;
      else
        newWert = stopTime - startTime;

ein simples

     newWert = stopTime - statTime;

reicht völlig aus.

> Das ist die Ausgabe der 15,6kHz Quelle! (result sollte eigentlich 4
> sein. 4*16 = 64us)


Jetzt muss ich mir doch deine Berechnungen dazu mal genauer ansehen. 
Rein gefühlsmässig kann das nicht stimmen.

....

Ich weiss schon, wo der Fehler ist.

Du hast hier gerechnet:

> FCPU=16Mhz, prescaler=0, 16MHz/256 = 62,5kHz 1/62,5kHz = 16us
>
> [CAR1] kürzeste Periode 1/15,62kHz = 64us /16us = 4

Dein Timer produziert OVERFLOWS mit einer Frequenz von 62.5kHz! Die 
Division durch 256 (die ich ursprünglich für einen Vorteiler gehalten 
hatte) ist der Zählumfang des Timers.
D.h. von einem Overflow zum nächsten vergehen 16us.

d.h. (in der weiteren Rechnung): der Timer zählt nicht bis 4, sondern 
bei dieser Eingangsfrequenz produziert der Timer 4 Overflows!


Ist mir doch gleich so spanisch vorgekommen, dass ein Zähler bei einem 
Vorteiler von 1 und lächerlichen EIngangsfrequenzen grade mal bis 4 
zählen soll. Ich hätt doch auf mein Gefühl vertrauen sollen.

Also: entweder das Zählsystem auf die Zählung von Overflows umstellen 
oder dem Timer einen Vorteiler verpassen (idealerweise 256, wenn du hast 
- dann ändert sich an den Zahlen nichts).

Karl Heinz Buchegger schrieb:

> Also: entweder das Zählsystem auf die Zählung von Overflows umstellen
> oder dem Timer einen Vorteiler verpassen (idealerweise 256, wenn du
> hast).


Hab grad hochgescrollt. Du sagtest, es gäbe unter anderem 256 und 64.
64 wäre besser. Die Zahlen werden schöner.

Du hast es irgendwie mit den unsigned long. Das ist scheinbar dein 
Lieblingstyp :-)

> volatile unsigned long int count = 0;

volatile uint8_t count = 0;

Bei dieser Variablen  ist es ganz besonders wichtig, dass du sie atomar 
lesen und schreiben kannst! einen unsigned long kannst du nicht atomar 
schreiben/lesen. einen uint8_t schon.


Generell: Du willst immer den kleinsten Datentyp benutzen, mit dem sich 
alles ausgeht. Wenn irgendwie möglich einen uint8_t. Das ist sozusagen 
des AVR Leib und Liebingsdatentyp. Damit kann er wunderbar umgehen. 
Alles andere ist für ihn mächtig Aufwand. Und: man kann sich damit auch 
mächtig Probleme einhandeln, die nicht so offensichtlich sind wie 
Overflows in Berechnungen.


(*) atomar: in einem Rutsch. Die Operation ist unteilbar, nicht 
unterbrechbar.

> Jetzt stellt sich mir die frage, ob der uC überhaupt mitkommt.

Logisch nachdenken und mal überschlagsmässig abschätzen:
Der µC läuft mit 16Mhz. Deine Eingangsfrequenz ist ca. 16kHz. Das ist 
ein Faktor von ungefähr 1000.

Ein Faktor von 1000 kann man veranschaulichen:

Du zählst vor dich hin: 1, 2, 3, 4, 5 ....
wobei du ca. jede Sekunde immer um 1 weiterzählt.

Und alle Viertelstunde rufe ich: Halt, wie weit bist du gekommen.

Du hast also den 'Stress' mit jeder Sekunde und ich hab genügend Zeit, 
dass ich mir in der Zwischenzeit die Quantentheorie reinziehe. Deinen 
Zählerstand zwischendurch wieder mal abfragen und mal kurz umrechnen 
mach ich mit Links nebenher. Sozusagen in der Werbepause :-)

@Karl Heinz Buchegger
Besten dank für die Erklärungen die haben mir jetzt echt weitergeholfen!

Hier das Resultat der geistigen Arbeit.

...
volatile uint8_t startTime = 0;
volatile uint8_t stopTime = 0;
volatile uint8_t sensor0 = 0;
...
SIGNAL (INT0_vect)
{
  sensor0++;
  if(sensor0<2)
  {
    startTime = stopTime;
    stopTime = TCNT0;
  }
}

int main()
{
  uint8_t result = 0;
  uint8_t lastResult = 0;

  TCCR0B |= (1<<CS01) | (1<<CS00);    // Timer0 mit Prescaler 64 (16000000/64) -> 4us/step

  init();
  sei();

  while(1)
  {    
    if(sensor0 >= 2)
    {
      sensor0 = 0;

      lastResult = result;
      result = stopTime - startTime;
      
      // prüfen ob letzter Messwert und neuer Messwert inerhalb der Toleranz sind
      if( ( (lastResult - result) < TOLERANZ) && ((lastResult - result) > - TOLERANZ) )
      {
        if(lastResult != result) 
          display(carId(result), 0);
      }
    }
  }
  return 0;
}
...

Funktioniert hoffentlich auch noch mit 4 Sensoren.

Allen beteiligten ein herzliches Dankeschön!!

MfG
Harry

Hallo,

ich sehe noch Folgendes. In der ISR solltest Du den Befehl "sensor0++;" 
noch in das if mit reinziehen. Sonst könnte es bei extremer Auslastung 
des Prozessors passieren das die Variable sensor0 überläuft und wieder 
bei 0 beginnt.

  if(sensor0<2)
  {
    sensor0++;
    startTime = stopTime;
    stopTime = TCNT0;
  }

Desweiteren sollte das Zurücksetzen der Variablen "sensor0 = 0;" erst 
nach der Übernahme der Werte startTime und stopTime erfolgen:

    if(sensor0 >= 2)
    {
      lastResult = result;
      result = stopTime - startTime;

      sensor0 = 0;

Sonst kann es passieren, daß die ISR schon wieder zuschlägt und die 
Werte verändert bevor sie ausgelesen wurden.

Und noch ein 2.tes Problem

Du musst unter allen Umständen verhindern, dass dir hier in dieser 
Sequenz

    if(sensor0 >= 2)
    {
      sensor0 = 0;

      lastResult = result;
      result = stopTime - startTime;

Der Interrupt zuschlägt und dir 'unter dem Hintern' die Werte verändert. 
Das darf auf keinen Fall passieren. Auch dann nicht, wenn gerade die 
Berechnung von
   stopTime - startTime
im Gange ist. Es muss sichergestellt sein, dass beide Werte aus 
derselben Messung stammen.

Dazu gibt es 3 Möglichkeiten
* entweder du kapselst das alles in eine cli/sei INterruptsperre
* oder du nutzt dein Wissen aus, dass dir die ISR die Werte nicht
  verändern wird, solange sensor0 größer/gleich 2 ist.
  Hier wäre es daher wichtig, dass das 0-Setzen von sensor0 als letztes
  erfolgt, nachdem sicher gestellt ist, dass du die stopTime bzw
  startTime nicht mehr brauchst.
* oder du verlagerst die Differenzberechnung überhaupt in die ISR.
  Das bischen Zeitreserve hast du dort allemal.

Das alles wird sich zum jetzigen Zeitpunkt noch nicht bemerkbar machen. 
Aber wenn dein Programm dann mal ein anderes Timingverhalten hat und die 
Zeiten enger werden, dann kann das zu einem Problem werden.


Edit: Hat sich mit Volkmars Analyse überschnitten.

Volkmar Dierkes schrieb:
> ich sehe noch Folgendes. In der ISR solltest Du den Befehl "sensor0++;"
> noch in das if mit reinziehen. Sonst könnte es bei extremer Auslastung
> des Prozessors passieren das die Variable sensor0 überläuft und wieder
> bei 0 beginnt.
>
>   if(sensor0<2)
>   {
>     sensor0++;
>     startTime = stopTime;
>     stopTime = TCNT0;
>   }

ok neues Rätsel wenn ich das so mache klapt das micht mehr.
Aber warum?

--> OK Kein Rätsel es hat vorher nur andere Messwerte geliefert!!