Probleme mit while

Matthias H. Gast #868116
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
yalu Gast #868217
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Matthias H. Gast #868233
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
G. L. #868255
Lesenswert?
• ▲
▼ 
Ein Fehler ist noch drin:

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

1
uint16_t z;

2


3
do

4
{

5
   cli();

6
   z = zCounter;

7
   sei();

8
} while (z < Counter);
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren