logische Verknüpfung als Bedingung für Abbruch while-Schleife (Atmega / Atmel Studio 7)

[Zi P. (zippo)]

Hallo,

ich stehe momentan auf dem Schlauch und auch nach 3h habe ich meinen 
Fehler nicht gefunden vielleicht kann ja einer von euch mir sagen was 
ich falsch mache.

Ich möchte eine while-Schleife abbrechen wenn entweder PinC0 gedrückt 
wird oder die Schleife 2 mal durchlaufen wurde. Wenn ich das Ganze auf 
dem Atmega88 habe, wird aber nur wenn der Taster losgelassen wird (mit 
internen Pullup eingeschaltet daher die Negation) die Schleife 
verlassen. Die Durchläufe interessieren mein Progamm nicht.
Ich habe schon verschiedene Klammern gesetzt aber keine brachte mich zum 
Erfolg.

Installiert ist das Studio 7.0 mit AVR GCC

  MAX7219_On();
  uint8_t i = 0;  
  
  while ( !(PINC & (1 << PC0)) && (i < 2) ){    
    _delay_ms(500);
    MAX7219_shutdown();
    _delay_ms(200);
    MAX7219_On();
    i++;}

Beste Grüße

[Christian M. (christian_m280)]

Zi P. schrieb:
> oder

Zi P. schrieb:
> &&

Merkst es?

Gruss Chregu

[Wegstaben V. (wegstabenverbuchsler)]

Zi P. schrieb:
> Ich möchte eine while-Schleife abbrechen wenn entweder PinC0 oder die
> Schleife 2 mal durchlaufen wurde.

> while ( !(PINC & (1 << PC0)) && (i < 2) ){

allgemein:
while Bedingung-zutrifft
   do action

--> versuch es mal mit der logischen "oder" Verknüpfung || anstelle 
eines "und" &&

[Harald K. (kirnbichler)]

Zi P. schrieb:
> while ( !(PINC & (1 << PC0)) && (i < 2) )

Die Schleife wird solange durchlaufen, wie PC0 nicht gesetzt ist und i 
kleiner ist als 2.

Zi P. schrieb:
> Ich möchte eine while-Schleife abbrechen wenn entweder PinC0 oder die
> Schleife 2 mal durchlaufen wurde.

Etwas unklar ist, was mit "entweder PinC0" gemeint ist, da fehlt ein 
Satzteil.

[Zi P. (zippo)]

Hallo,

ich bin gerade außer Haus und kann nicht am Rechner sogleich testen, 
aber ich will doch eine "while" Schleife unterbrechen und das geht doch 
nur wenn die Bedingung NULL wird -> while (0)

Wenn ich jetzt wie vorschlagen die ODER-Verknüpung nehme heißt es doch 
-> while (0 || 1)
Und das würde doch keinen Ausbruch aus der Schleife erzeugen außer ich 
lasse beide Bedingungen zu NULL werden.

Bitte korrigiert mich wenn ich falsch liege, ich bin erste gerade dabei 
mich wieder in AVR und GCC einzuarbeiten... ging in den Jahren einiges 
an Wissen den Berg hinunter.

[Zi P. (zippo)]

Harald K. schrieb:
> Zi P. schrieb:
>> while ( !(PINC & (1 << PC0)) && (i < 2) )
>
> Die Schleife wird solange durchlaufen, wie PC0 nicht gesetzt ist und i
> kleiner ist als 2.


Danke für den Hinweis, ist korrigiert.

Undn nein genau wie du es beschreibst sollte es meiner Meinung nach auch 
laufen ... tut es nur nicht. i > 2 erzeugt keinen Abbruch

[Harald K. (kirnbichler)]

Man könnte den Kram natürlich auch anders formulieren:

  uint8_t i;  
  MAX7219_On();

  for (i = 0; i < 2; i++)
  {
    if (PINC & (1 << PC0))
      break;

    _delay_ms(500);

    MAX7219_shutdown();

    _delay_ms(200);

    MAX7219_On();
  }

aber das, was da eingangs steht, sollte auch funktionieren.

[Wegstaben V. (wegstabenverbuchsler)]

du könntest dir ja auch einfach mal die Werte ausgeben lassen

[Oliver S. (oliverso)]

Zi P. schrieb:
> wird aber nur wenn der Taster losgelassen wird (mit
> internen Pullup eingeschaltet daher die Negation) die Schleife
> verlassen. Die Durchläufe interessieren mein Progamm nicht.

Woher weißt du das?

Oliver

[Peter D. (peda)]

Zi P. schrieb:
> Wenn ich das Ganze auf
> dem Atmega88 habe, wird aber nur wenn der Taster losgelassen wird (mit
> internen Pullup eingeschaltet daher die Negation) die Schleife
> verlassen.

Dann macht das Programm ja genau das, was Du hingeschrieben hast.

Zi P. schrieb:
> Die Durchläufe interessieren mein Progamm nicht.

Sicher?
Dazu muß aber die Taste permanent gedrückt sein.

[Pilot P. (klatschnass)]

In C hat der Operator ! laut Doku eine höhere Priorität als &&.
In Python hat dein Konstrukt funktioniert.

Probier's mal mit:
 while ( (!(PINC & (1 << PC0))) && (i < 2) ){

Gruß klatschnass

Edit: Ok, das war Quatsch.
Der while-Ausdruck funktioniert so, wie er ist.
Das Problem liegt wohl eher daran, dass die Taste in der delay-Pause 
gedrückt und wieder losgelassen wird. Das bekommt die Schleife dann 
natürlich nicht mit. Deswegen hattest du auch den Eindruck, dass du die 
Taste langsam loslassen musst, damit es funktioniert. Da musst du wohl 
statt der Pause mit Interrupts arbeiten.

[Spess53 .. (hardygroeger)]

Hi

> Da musst du wohl statt der Pause mit Interrupts arbeiten.

Aber Timer-Interrupts.

MfG Spess

[N. M. (mani)]

Pilot P. schrieb:
> Da musst du wohl statt der Pause mit Interrupts arbeiten.

Oder einfach mit freilaufendem Timer und einer kleinen Statemachine.

Pilot P. schrieb:
> Das Problem liegt wohl eher daran, dass die Taste in der delay-Pause
> gedrückt und wieder losgelassen wird. Das bekommt die Schleife dann
> natürlich nicht mit.

Ja, das ist natürlich Quatsch. Da muss man ja jede nach dem bis zu 700ms 
den Taster drücken.

[Zi P. (zippo)]

Also der Code funktioniert so wie er soll, mein Problem lag eine Zeile 
weiter. Dort habe ich im prinzip ein Signal erhalten, deswegen gab es 
immer wieder einen Rücksprung in die while Schleife.

Danke für eure Unterstützung.

Und die 700ms machen für mich schon Sinn da ich erst nach kurzem halten 
der Taste in ein Menü gelangen möchte.

Grüße

[Wegstaben V. (wegstabenverbuchsler)]

Zi P. schrieb:
> mein Problem lag eine Zeile
> weiter. Dort habe ich im prinzip ein Signal erhalten, deswegen gab es
> immer wieder einen Rücksprung in die while Schleife.

dein oben gezeigter Code-Schnipsel gibt das aber nicht wieder.
Wie geht denn ein "_Rücksprung_ in eine While-Schleife?"
Echt? Sprung in eine Schleife hinein???? STAUN

[Hugo H. (hugo_hu)]

Wegstaben V. schrieb:
> Wie geht denn ein "_Rücksprung_ in eine While-Schleife?"

Kennst Du keine Funktionsaufrufe?

MAX7219_...();

scheinen SPI-Kommunikation "durchzuführen" ...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Hugo H. schrieb:
> Wegstaben V. schrieb:
>> Wie geht denn ein "Rücksprung in eine While-Schleife?"
> Kennst Du keine Funktionsaufrufe?
> MAX7219_...();
> scheinen SPI-Kommunikation "durchzuführen" ...
Und wieso würde da dann irgendwas "springen"?
Die Funktionen geben ja nicht mal einen Wert zurück.

Zi P. schrieb:
> Und die 700ms machen für mich schon Sinn
Für mich sind die 700ms delay() ein Programmfehler, weil sie nur nutzlos 
Rechenzeit vergeuden.

[Christopher B. (chrimbo)]

Wegstaben V. schrieb:
> Echt? Sprung in eine Schleife hinein???? STAUN
da gibt es schon Wege

[Hugo H. (hugo_hu)]

Lothar M. schrieb:
> Die Funktionen geben ja nicht mal einen Wert zurück.

Werden aber aufgerufen und kehren wohl auch wieder zum Statement nach 
dem Aufruf zurück.

[Stefan F. (Gast)]

Der Fehler ist (wie so oft) nicht im gezeigten Stück Code. Das heißt, du 
konzentrierst dich auf die falsche Stelle.

Denn folgendes Testprogramm läuft auf meinem PC nämlich tadellos:

#include <stdio.h>
#include <stdint.h>

void _delay_ms(int ms)
{
    printf("_delay_ms(%d)\n", ms);
}

void MAX7219_On()
{
    puts("MAX7219_On()");
}

void MAX7219_shutdown()
{
    puts("MAX7219_shutdown()");
}

#define PC0 0
#define PINC 0

int main()
{
    MAX7219_On();
    uint8_t i = 0;

    while ( !(PINC & (1 << PC0)) && (i < 2) )
    {
      _delay_ms(500);
      MAX7219_shutdown();
      _delay_ms(200);
      MAX7219_On();
      i++;
    }
}

Ausgabe:

MAX7219_On()
_delay_ms(500)
MAX7219_shutdown()
_delay_ms(200)
MAX7219_On()
_delay_ms(500)
MAX7219_shutdown()
_delay_ms(200)
MAX7219_On()