atmega324p TIMER0 INT0 verständnis Problem

[Harry (Gast)]

Hallo zusammen,

bin gerade dabei wie schon in diesem Artikel beschrieben,

Beitrag "Carrera Digital 132 Zeitmessung / Rundenzähler"

eine Erfassung für Carrera digital1xx Autos zu realisieren.
Die Autos senden über eine IR LED 4000000/1024*256*n an einen 
Phototransistor. Soweit alles klar ich bekomme ein schönes 
rechtecksignal mit schönen Flanken.

Mein bisheriger Ansatz mit INT0 und Timer0 liefert jedoch nicht das 
gewünschte resultat.

#define F_CPU 16000000L

volatile int countSensorA = 0;
volatile char Buffer[20];
volatile int last = 0;
volatile int count = 0;


SIGNAL (INT0_vect)
{
  // steigende flanke kommt
  countSensorA++;
  // Timer0 in betrieb setzen
  if(countSensorA == 1)
  {
    TIMSK0 |= (1<<TOIE0);    
  }
}


SIGNAL (TIMER0_OVF_vect)
{
  // Timer overflow
  cli();

  // Timer ausschalten
  TIMSK0 &= ~(1<<TOIE0);
  if(countSensorA > 5)
  {
    // pulse anzeigen
    itoa( countSensorA, ( char* ) Buffer, 10 );
    Oputs(( char* ) Buffer);
    Oputs(" Pulse gezählt\r\n");

  }      
  // zähler auf 0
  countSensorA = 0;
    
  // bischen warten bis Auto weg ist
  _delay_ms(500);
  count = 0;
  sei();
}


void initIo()
{
  EICRA |= (1<<ISC01) | (1<<ISC00);  // Steigende Flanke von INT0 als auslöser
  EIMSK |= (1<<INT0);          // interruptmaske
  EIFR |= (1<<INTF0);

  // Timer 0 mit Prescaler 1024
    TCCR0B |= (1<<CS02) | (1<<CS00);     
}

Ist meine Ansatz der falsche oder hab ich was übersehen?

Gruß Harry

[Düsendieb (Gast)]

Hallo Harry,
dein Ansatz ist unglücklich. so viel Programm packt man nie in einen 
Timerinterrupt und ein delay schon gar gar gar nicht.

Lass mit dem Timerinterrupt eine Variable meinetwegen in 0,1sec takt 
hochzählen und im Eingangsinterupt wird die Variable abgefragt und 
wieder auf Null gesetzt.


Axel

[STK500-Besitzer (Gast)]

Harry schrieb:
> Die Autos senden über eine IR LED 4000000/1024*256*n an einen
> Phototransistor.

Eier, Kartoffeln? Liter?
Besitzt der MEGA324P eine Input-Capture-Unit?
Dann solltest du diese benutzen.

Harry schrieb:
> SIGNAL (TIMER0_OVF_vect)
>
> {
>
>   // Timer overflow
>
>   cli();
>
>
>
>   // Timer ausschalten
>
>   TIMSK0 &= ~(1<<TOIE0);
>
>   if(countSensorA > 5)
>
>   {
>
>     // pulse anzeigen
>
>     itoa( countSensorA, ( char* ) Buffer, 10 );
>
>     Oputs(( char* ) Buffer);
>
>     Oputs(" Pulse gezählt\r\n");
>
>
>
>   }
>
>   // zähler auf 0
>
>   countSensorA = 0;
>
>
>
>   // bischen warten bis Auto weg ist
>
>   _delay_ms(500);
>
>   count = 0;
>
>   sei();
>
> }

"cli" und vor allem "sei" haben in einer ISR nichts zu suchen!

Deine Messmethode muss man nicht verstehen, oder?
Kannst du die mal in Worten beschreiben?
Vielleicht auch noch ein paar Angaben zum Takt?

[Tommy T. (tommy2000)]

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.

[Harry (Gast)]

Die IR LED der Autos senden permanent mit 4MHz/(256*CARNUMBER)

IR LED Auto_1 sendet 15625 Hz
.
.
.
IR LED Auto_6 sendet 2604 Hz
IR LED Auto_7 sendet 2232 Hz

Mein Ansatz war Auto fährt über den Sensor INT0 wird ausgelöst, TIMER0 
startet, INT0 zählt bis TIMER0 Overflow erreicht und das soll dann das 
Messergebnis sein.

Gibt es AVR's mit 4 ICP Modulen?

Überarbeite gerade die ISR

Gruß Harry

[MWS (Gast)]

Harry schrieb:
> TIMER0 startet,

Der startet aber nicht dadurch, dass man den Overflowinterrupt erlaubt, 
sondern der läuft dauernd bei Deinem Code.

Was passiert eigentlich, wenn mehrere Fahrzeuge gleichzeitig den Sensor 
durchfahren ?

> Gibt es AVR's mit 4 ICP Modulen?

XMega.

Aus dem momentanen Code zu urteilen wird das aber noch ein weiter Weg, 
zudem die XMega's um Einiges komplexer sind.

[Karl H. (kbuchegg)]

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.

[MWS (Gast)]

Karl Heinz Buchegger schrieb:
> Für mich ist da
> nicht wirklich erkennbar, was eigentlich gemessen werden soll.

Also der prinzipielle Wille ist aus dem Code schon erkennbar :D

[Harry (Gast)]

MWS schrieb:
> Was passiert eigentlich, wenn mehrere Fahrzeuge gleichzeitig den Sensor
> durchfahren ?

Die Autos überfahren den Sensor. D.h. pro Spur nur 1 Auto am Sensor. 
Aber 4 Spuren.

Das ganze ist keine neue Erfindung von mir ich möchte es nur 
nachstellen.

Die Harware steht schon. Es wurde damals auch nicht mit ICP gemacht, 
sondern mit mega88 über PD2(INT0), PD3(INT1), PD7(AINT1) und PD4(T0).

Leider hat der Herr (www.slotbaer.de) keine Zeit mehr.

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

Gruß Harry

[Karl H. (kbuchegg)]

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.

[STK500-Besitzer (Gast)]

Karl Heinz Buchegger schrieb:
> Oder du lässt deinen Timer überhaupt einfach durchlaufen und vergleichst
> die Zählerstände bei 2 aufeinanderfolgenden Interrupts.
manuelle ICP.. ;)

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

Es interessier ja auch nur die Periodendauer...

Wie schnell mag so ein Auto über den Fotosensor fahren?
2-3 Perioden?

Harry schrieb:
> Eine Anzahl von Pulsen(15,5 kHz - 2,2kHz) in einer bestimmten
> Zeit(5-10ms)

Auch eine Möglichkeit, aber auch das macht der Code oben sicher nicht.

[STK500-Besitzer (Gast)]

Harry schrieb:
> Eine Anzahl von Pulsen(15,5 kHz - 2,2kHz) in einer bestimmten
> Zeit(5-10ms)

5ms sollten auf jeden Fall reichen. Das auto 7 hat mit seiner Frequenz 
eine Periodendauer von 0,5ms. Das wären für schon 10 Perioden.
Bei Auto 1 ist die Periodendauer nur noch 64µs lang - das wären dann 
entsprechend mehr Perioden/Impuls pro 5ms.

[Harry (Gast)]

Ok besten Dank für eure Hilfe. Bau mal den Code entsprechend um und 
Poste in dann nochmal

Gruß Harry

[MWS (Gast)]

Harry schrieb:
> Aber 4 Spuren.

Basierend auf Deinem momentanen Konzept (Messung über Torzeit) 
bräuchtest Du 4 unabhängige voneinander zu startende Timer, in HW hast 
Du die nicht, könnte man in SW bauen.

Oder in der ext. Int den Zähler sampeln und nach soundsoviel Differenz 
eine Messung als beendet betrachten, hat aber auch Nachteile.

Oder Periodenzeitmessung, wobei im worst-case bei 4 konkurrierenden 
Signalen, also 4 Autos gleichzeitig, eine ausreichend genaue Messung der 
Periodendauer stattfinden muss.

Zeit also sich über's später verwendbare Konzept Gedanken zu machen und 
dann den Code daraufhin ausgerichtet zu beginnen.

Harry schrieb:
> PD2(INT0), PD3(INT1), PD7(AINT1) und PD4(T0).

Unwahrscheinlich. Sinnvoll war Int1 & 2, als auch 2 der PCInts, für den 
M324 dann Int0-2 & ein PCInt, oder PCINT0-3.

[Harry (Gast)]

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 ;-)

Später werd ich das über die PCINT lösen.

mfg
Harry

[Karl H. (kbuchegg)]

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 (Gast)]

@Karl Heinz Buchegger
  danke für den Hinweis hab mal etwas gerechnet:

FCPU=16Mhz, prescaler=0, 16MHz/256 = 62,5kHz 1/62,5kHz = 16us

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

mfg
Harry

[Karl H. (kbuchegg)]

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 (Gast)]

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

Du meinst ich soll den 16bit Timer nehmen und mich da mit den prescaler 
an meinen Bereich nähern?

Ich hab 0, 8, 64, 256, 1024 als Prescaler.

[spess53 (Gast)]

Hi

>Ich hab 0, 8, 64, 256, 1024 als Prescaler.

Beim Timer2 hättest du auch 32.

MfG Spess

[Karl H. (kbuchegg)]

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.

[Harald M. (_harry_)]

>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

[Volkmar D. (volkmar)]

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();
    }

[Harald M. (_harry_)]

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

[Karl H. (kbuchegg)]

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

[Karl H. (kbuchegg)]

> 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 H. (kbuchegg)]

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.

[Karl H. (kbuchegg)]

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.

[Karl H. (kbuchegg)]

> 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 :-)

[Harald M. (_harry_)]

@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

[Volkmar D. (volkmar)]

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.

[Karl H. (kbuchegg)]

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.

[Harald M. (_harry_)]

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!!