Hallo Leute,
ich habe Probleme mit folgendem Stück Code:

...
volatile uint16_t zCounter

...

ISR(INT0_vect)
{
  if (PINC & (1 << PINC0)) zCounter++;
..
}

..

int main (void)
{
  uint16_t Counter;

..
  Counter = 300;
  zCounter = 0;
 sei();
  PORTC |= (1 << PC0);

  while (zCounter < Counter);

  PORTC &= ~(1 << PC0);
  cli();
..
}

Die while- Schleife wird einfach übergangen. Wenn ich da "while
(zCounter != Counter);" schreibe, klappt alles. Im INT0-Eingang befindet
sich ein Encoder, dessen Signal ich zählen möchte. An PC0 hängt der
Motor. Ich hoffe, der Code-Auszug reicht, um das Problem darzustellen.

Sieht so aus, als ob du den Code hier eingetippt hast. Das ist keine
gute Idee, poste lieber den echten Code. Da ist vermutlich ein
Flüchtigkeitsfehler drin, der hier nicht drin ist.

das Problem ist, dass ich mit einem anderen Rechner im Netz bin. Hab
leider im Moment keine Möglichkeit, den Code zu kopieren.

Kann es sein, dass der Compiler die While-Schleife einfach mal
wegoptimiert?
Wobei das "volatile" das je verhindern sollte.
Definiere "Counter" doch auch mal volatile.

Da ist nichts wegzuoptimieren, es muss auch ohne volatile bei Counter
funktionieren.

Paranoia: du benutzt nicht zufälliger Weise WinAVR-20080402?

genau den benutze ich. Gibt es da Probleme?

Wie ist der INT0 konfiguriert, als Flanken- oder als Level-Interrupt?
Was veranlasst dich zur Vermutung, dass die While-Schleife
übersprungen wird?

Meine Vermutung: INT0 ist als Level-Interrupt konfiguriert, und der
Low-Pegel am Interrupteingang dauert so lange an, dass der
Interrupthandler währenddessen mindestens 300mal direkt hintereinander
abgearbeitet werden kann. Weil das schneller geht, als dein Auge es
erfassen kann, denkst du, die While-Schleife wurde übersprungen.

Warum verhält sich das Programm bei "while(zCounter != Counter);"
anders?

Da zwischen zwei Interrupthandleraufrufen genau eine Instruktion der
main-Funktion ausgeführt wird, wird zwischen zwei Prüfungen der
While-Bedingung der Counter mehrmals inkrementiert. Je nach Timing
kann es deswegen passieren, dass in einem Schleifendurchlauf bspw. der
Wert 299 gesehen wird, im nächsten Durchlauf steht er aber schon auf
einem Wert >300, so dass die Schleife nicht abbricht. Vielleicht tut
sie dies aber, nachdem Counter ein oder mehrere Male bei 65535
überlaufen ist und die While-Abfrage irgendwann doch bei exakt 300
stattfindet. Bis dahin hat sich die Schleife aber zigtausende Male
gedreht, so dass dein Auge die Verzögerung tatsächlich wahrnimmt.

>genau den benutze ich. Gibt es da Probleme?

Wurde wegen Bugs gestrichen.
Nimm erstmal den 200705xx.

holger wrote:
>>genau den benutze ich. Gibt es da Probleme?
>
> Wurde wegen Bugs gestrichen.
> Nimm erstmal den 200705xx.

Quatsch. Nimm einfach einen aktuelleren:
http://sourceforge.net/project/showfiles.php?group_id=68108

Die neueste Version ist vom 12.5.

oh Mann, richtig. Ich hab mich beim MCUCR vertan und den Low Level als
Interrupt definiert. So ist das, wenn man den nur als Hex-Zahl schreibt.
Dann wird die Fehlersuche schwer. Vielen Dank für den Tipp, yalu. Das
Kann dann natürlich nichts werden, wenn ich nur den Home-Puls des
Encoders nutze und er die meiste Zeit Low ist.

Upgrade trotzdem das WinAVR.  Die Version 20080402 hatte einen richtig
üblen Bug.  Einer der Patches für den Xmega hatte unbeabsichtigterweise
einen Einfluss auf nicht-Xmega-CPUs und hat bei diesen komplett falsche
Sprünge generiert.

Ein Fehler ist noch drin:

while (zCounter < Counter);

Das sind 16-Bit-Werte. Da AVR 16 Bits nicht atomar laden kann, kann es
sein, daß zwischen dem Einlesen der einzelnen Bytes eine IRQ getriggert
wird. Dann würde das eingelesene zCounter aus zwei Teilen bestehen:
einem alten Byte von vor Ausführung der ISR, das schon in einem Register
steht, und einem neuen Byte, das durch die ISR verändert wurde.

Daher muss atomar auf zCounter zugegriffen werden, um sporadische
Fehlfunktion zu vermeiden:

uint16_t z;

do
{
   cli();
   z = zCounter;
   sei();
} while (z < Counter);

@Georg-johann Lay
 es sind zwar jetzt noch keine Probleme aufgetreten, aber ich werde dies
ändern. Klingt auch einleuchtend.