while( ) >>> mit Bedingungen

__Son´s B. schrieb:
> klappt nicht
> klappt auch nicht
Was "klappt nicht"? Und wie sieht der Rest der Schleife aus? Denn das 
Problem liegt auch hier nicht im geposteten Code...

__Son´s B. schrieb:
> wird die Schleife gestoppt.
Eine Schleife wird nicht "gestoppt", sondern bestenfalls "verlassen"...

while(1) bedeutet, dass die Schleife endlos durch läuft.
Nach meinem Verständniss, bei jeder Schleife prüft, ob while noch "1" 
oder "wahr" ist.
Würde ich hier eine Bedingung einfügen, könnte ich den folgenden 
Schleifendurchlauf stoppen.

Gerhard schrieb:
> if () break;
> ist auch ne Möglichkeit, eine Schelife zu verlassen.
Durch while() scheint mir sehr einfach und schnell, die Schleife zu 
stoppen(!) um es später wieder weiter laufen zu lassen.

Peter II schrieb:
> Eventuell "floatet" ja der Pin.
???

__Son´s B. schrieb:
> Durch while() scheint mir sehr einfach und schnell, die Schleife zu
> stoppen(!) um es später wieder weiter laufen zu lassen.

So funktioniert das aber nicht.

Ist der Grundgedanke while(Bedingung) eigentlich unrealistisch oder 
praxisfern?

__Son´s B. schrieb:
> Ist der Grundgedanke while(Bedingung) eigentlich unrealistisch
> oder praxisfern?

Über den Grund wissen wir nichts, weil du erst mit dem Detail kommt was 
dann aus welchen obskuren Gründen auch immer nicht mehr passt.

while(0) wird jedenfalls nie ausgeführt.

Hi,
Du verläßt hier die Hauptschleife.
Was soll er denn Deiner Ansicht danach tun? Dahinter steht ja nichts.
Somit ist es nicht definiert, was er beim Verlassen dieser Schleife 
macht.

Gruß
Andreas

Andreas B. schrieb:
> Was soll er denn Deiner Ansicht danach tun?
(*) Wenn am PB5 "0" anliegt, läuft die Endlosschleife.
Solang am PB5 eine "1" anliegt, stoppt das folgende Programm, bis PB5 
wieder auf "0" gesetzt ist. Danach (*)

Hi, das Programm kommt aber nicht automatisch wieder an der Schleife 
vorbei, nur weil Dein Eingang wieder den Zustand wechselt.

Anweisungen werden Schritt für Schritt abgearbeitet.

Gruß Bernhard

Viele gut gemeinte Beiträge liefen in die falsche Richtung.

Die while()-Funktion ist mir bekannt, der o.g. C-Code zeigt das.
Mir ging es wie Eingangs beschrieben um eine kleine Abkürzung. Dieses 
steht in keinem Fachbuch - daher scheinbar ein "NoGo" oder zu abstrakt.

__Son´s B. schrieb:
> Die while()-Funktion ist mir bekannt,

while() ist keine Funktion, Klammern hin oder her.

while hat beispielsweise keinen Rückgabewert.

while ist eine Kontrollstruktur, vielleicht noch statement.

Aber keine Funktion.

Und eine if-Schleife auch nicht ...

Ich denke Du willst in einer Funktion warten, bis der PINB5 auf 1 
gegangen ist.

while(!(PINB&0x10));           oder auch
while((PINB & (1<<PB5)) == 0); wie du schreibst sollte eigentlich 
funktionieren.

Hast Du schon mal überprüft, ob der Pin überhaupt als Eingang 
konfiguriert ist?

und lass solche sachen wie "if(..) break" in einer Schleife,
das ist schlechter stiel, und sollte genauso wie continue nicht 
verwendet werden. (MISRA)

sonst nimm

1

int abbruch = FALSE;

2

3

while(!abbruch)

4

{

5

...

6

   if(PINB & (1<<PB5))

7

   {

8

      abbruch = TRUE;

9

   }

10

...

11

}

dabei wird die Schleife zumindest noch zu Ende geführt.

Norbert H. schrieb:
> Hast Du schon mal überprüft, ob der Pin überhaupt als Eingang
> konfiguriert ist?

DDRB &= ~(1<<PB5);

Norbert H. schrieb:
> und lass solche sachen wie "if(..) break" in einer Schleife,
> das ist schlechter stiel, und sollte genauso wie continue nicht
> verwendet werden. (MISRA)

Dank dir für den Tip!

Peter II schrieb:
[c]
> while( interator != list.end() ) {
>    if ( interator == gesucht ) {
>       break;
>     }
> }
[c/]

>
> was ist daran anzusetzen?

[c]

while( interator != list.end() && !(( interator == gesucht )) ) {

}
[c/]

so würde ich das machen.

Gruß
Andreas

Peter II schrieb:
> Ulrich F. schrieb:
>> Ein Seitenausstieg aus einer Schleife, oder auch aus einer Funktion ist
>> schlechter Stil.
>
> was aber bestimmt nicht die allgemeine Meinung ist.

Doch. Jedenfalls unter Leuten, die Programmierrichtlinien nicht 
konsequent ignorieren. Davon gibt es freilich eine Menge ;-)

Der Andere schrieb:
> Dann machst du eine while Bedingung, die 1000 Zeichen lang ist?

Ich (und andere auch) habe nicht behauptet, daß man nie mit break aus 
einer Shliefe gehen soll. Man versucht es nur zu vermeiden. In diesem 
Fall war es einfach.

Allerdings kann man auch in Deinem Fall die Bedingung "interator == 
gesucht" innerhalb der Schleife erzeugen. Das muß nicht in der while 
Bedingung geschehen.

Gruß
Andreas

Der Andere schrieb:
> mr. mo schrieb:
>> Andreas B. schrieb:
>>> while( interator != list.end() && !(( interator == gesucht )) )
>>
>> So einfach das man gar nicht dran denkt. Danke :)
>
> Prima und wenn du dann mehrere Bedingungen hast, und Werte einzelner
> Bedingungen eventuell erst berechnet oder von Unterfunktionen geholt
> werden müssen?
> Dann machst du eine while Bedingung, die 1000 Zeichen lang ist?

Dann fasst man alle möglichen Abbruchbedingungen in einem Flag zusammen, 
welches man im Schleifenkopf abfragt.

Gas_t schrieb:
> Das ist deutlich schlechter lesbar und deswegen für mich schlechter
> Stil. Ein if () break; in einer übersichtlichen Funktion ist da deutlich
> besser in meinen Augen.

Und die break Bedingung dann in der Schleife suchen?
Bei kurzen Schleifen vielleicht...

Kannst es auch so schreiben, wenn Dir das besser gefällt:
while( interator != list.end() &&
    !(( interator == gesucht )) )


Gruß
Andreas

Mark B. schrieb:
>> Dann machst du eine while Bedingung, die 1000 Zeichen lang ist?
> Dann fasst man alle möglichen Abbruchbedingungen in einem Flag zusammen,
> welches man im Schleifenkopf abfragt.

Andreas B. schrieb:
> Und die break Bedingung dann in der Schleife suchen?

Naja, ob ich jetzt am Ende der Schleife weiß, dass "done == true" ist, 
oder ob irgendwo in der Schleife ein "break" gefeuert hat, macht jetzt 
keinen Unterschied.

Im Übrigen bin ich der Meinung, dass Kommentare bei soetwas hilfreich 
sind.

Es gibt da durchaus zwei Ansätze:

1

char * SearchChar(char * String, char Char){

2

  while((*String != '\0) && (*String != Char)){

3

    String++;

4

  }

5

  return (*String == Char) ? String : NULL;

6

}

1

char * SearchChar(char * String, char Char){

2

  while(*String != '\0'){

3

    if(*String == Char){

4

      return String;

5

    }

6

    String++;

7

  }

8

  return NULL;

9

}

Ich bevorzuge die zweite Variante, obwohl das return innerhalb der 
Schleife ist (und somit einem break/goto entspricht) und ich sogar zwei 
davon habe.

Ich handhabe das meistens so:
Wenn es einfach und leserlich möglich ist, verwende ich die Bedingung im 
Schleifenkopf. Ist es hässlich, z.B. Flags über mehrere Ebenen, 
spendiere ich auch mal ein goto, das direkt hinter die Schleife springt. 
Zugegeben, dieser Fall tritt sehr selten auf, zumal ich für jeden 
Scheiss eine Funktion schreibe und dann meist ein return in der Schleife 
steht. Wenn ansonsten nichts in der Funktion gemacht wird (also reines 
Suchen), ist ein return in und eines nach der Schleife meiner Meinung 
nach kein schlechter Stil.

@TO: Warten in einer while-Schleife ist meist eine schlechte Idee, da 
dadurch der Controller auf unbestimmte Zeit blockiert ist. Besser ist 
es, nur auf eine Änderung der Eingangspins zu reagieren (pollen). Wenn 
die Bedingung nicht erfüllt ist, macht der Controller in der 
Zwischenzeit etwas anderes und prüft später nochmals.

Dussel schrieb:
> else  // Wo? welche Fehler war das? Achso, zwei Bildschirmseiten höher

Dann liegt der Fehler aber woanders: Eine Funktion, die über zwei 
Bildschirmseiten geht, ist mit 99% Wahrscheinlichkeit einfach zu groß 
und schlecht designed.

"A function shall do one thing, and only one thing - and do it well".

Ulrich F. schrieb:
> Alles, was die Lesbarkeit beeinträchtigt, ist schlechter Stil.
> Und in der Regel gilt: Je mehr Ausstiegspunkte, desto unübersichtlicher.

Bedingt. Folgendes Beispiel halte ich für leserlich:

1

int foo( /* ... */ ){

2

  if(BedingungA){

3

    return FehlerA;

4

  }

5

  if(BedingungB){

6

    return FehlerB;

7

  }

8

  if(BedingungC){

9

    return FehlerC;

10

  }

11

12

  /* eigentliche Funktion */

13

14

  return Result;

15

}

Aber grundsätzlich gebe ich dir Recht. Funktionen, die über zwei 
Bildschirmseiten ragen und mit returns gespickt sind, sind nicht 
wirklich übersichtlich. Was hälst du von Exceptions? Das sind im Prinzip 
auch returns, einfach ein wenig anders.

Ulrich F. schrieb:
> be s. schrieb:
>> Was hälst du von Exceptions?
>
> In meiner kleinen AVR Welt?
> Nix!
>
> Ansonsten bin ich da ein Freund von und setze sie gerne ein.

Sehe ich genau so.

mr. mo schrieb:
> Andreas B. schrieb:
>> while( interator != list.end() && !(( interator == gesucht )) )
>
> So einfach das man gar nicht dran denkt. Danke :)

Aber unsinnig.

Normalerweise will man ja mit dem gefundenen Element etwas machen (und 
das kann man nicht wenn es nicht gefunden wurde).

1

 while( interator != list.end() ) {

2

    if ( interator == gesucht ) {

3

       do_something(iterator) ;

4

       break;

5

     }

6

 }

geht dann nämlich schon nicht mehr mit Andreas seinem "Pattern".

Michael B. schrieb:
> mr. mo schrieb:
>> Andreas B. schrieb:
>>> while( interator != list.end() && !(( interator == gesucht )) )
>>
>> So einfach das man gar nicht dran denkt. Danke :)
>
> Aber unsinnig.
...
> geht dann nämlich schon nicht mehr mit Andreas seinem "Pattern".

Das ist nicht das Problem mit dem Pattern. Abgesehen davon, dass 
list.end() C++ vermuten lässt, wobei std::find vorzuziehen währe, fällt 
anscheinend niemandem auf, dass man den Iterator in der Schleife erhöhen 
muss oder sonstwie auf das nächste Element setzen sollte.

In C könnte das so aussehen, wenn man es richtig macht:

1

#include <stdio.h>

2

3

int main(){

4

5

  int gesucht = 2;

6

  int list[] = {1,2,3};

7

  int*const list_end = list + sizeof(list) / sizeof(*list);

8

9

  int* it;

10

  for( it=list; it<list_end; it++ )

11

    if( *it == gesucht )

12

      break;

13

14

  if( it == list_end ){

15

    printf("Not found\n");

16

  }else{

17

    printf("Found %d at index %u\n",*it,(unsigned)(it-list));

18

  }

19

20

  return 0;

21

}

Ich finde folgende Lösung deutlich angenehmer zu lesen. Kurz und 
knackig, und der Compiler warnt mich, wenn ich das Array überrenne.

1

#define LIST_SIZE 3

2

int list[LIST_SIZE] = {1, 2, 3};

3

4

for(size_t i = 0; i < LIST_SIZE; i++) {

5

  if(list[i] == gesucht) {

6

    /* tu was */

7

    break;

8

  }

9

}

Wenn im "nicht gefunden"-Fall noch eine spezielle Aktion dazu kommt, 
oder wenn ich wissen will, wie oft ich das Element gefunden habe, dann 
kommt ein Flag (oder Zähler) dazu.

... wegen des originalen Problems des digitalen Eingangs auf PB5.

Jetzt kenne ich die Schaltung der Hardware nicht, aber lt. Programm 
solltest du entweder einen externen Pop-Up Widerstand an PB5 haben, oder 
den internen Pop-Up Widerstand einschalten.

mit

1

DDRB &= ~(1 << PB5);

schaltest du PB5 als Eingang, aber dieser Eingang hängt in der Luft und 
hat keinen definierten Zustand.

mit

1

DDRB &= ~(1 << PB5);

2

PORTB |= (1 << PB5);

schaltest du den internen Pop-Up Widerstand ein .

Gruß,
Ralph

Ralph S. schrieb:
> internen Pop-Up Widerstand

Wo nennt man das so? Üblich ist "pull-up".

Ralph S. schrieb:
> ... wegen des originalen Problems des digitalen Eingangs auf PB5.
So sieht der Kopfbereich aus.
Hier soll das Programm stoppen, wenn PB5 auf Vcc liegt.

int main(void)
{
  DDRB &= ~(1<<PB5);  // Eingang, kein pull-up, via.100k auf Gnd

  while(1)
  {

    //while((PINB & (1<<PB5))==0);  //Versuch1, klappt nicht
    //while(!(PINB & (1<<PB5))==1);  //Versuch2, Stop, wenn PB5 low
    //while(!(PINB & (1<<PB5)));  //Versuch3, klappt nicht
    //while((PINB & (1<<PB5))!=1);  //Versuch4, klappt nicht
    //while((PINB & (1<<PB5))!=0);  //Versuch5, reagiert nicht
    //while((PINB & (1<<PB5))==1);  //Versuch6, Stop, wenn PB5 low
    while(PINB & (1<<PB5));    //Versuch7, Stop, wenn PB5 low
    ...

Ich verstehe nicht, dass die die Prüfung auf 0 (Versuch 6+7) 
funktioniert, die Invertierung aber nicht.
Scheint sich um ein generelles Verständnisproblem zu handeln - aber wo 
steck der Fehler?

__Son´s B. schrieb:
> aber wo steck der Fehler?
Was kommt bei PINB & (1<<PB5) raus?
1) wenn der Pin high ist: 0b00100000 = 0x20 = 32
und es gilt !0b00100000 = 0b00000000 = 0x00 = 0
2) wenn der Pin low ist:  0b00000000 = 0x00 = 0
hier gilt   !0b00000000 = 0b00000001 = 0x01 = 1

So, und jetzt trägst du das einfach mal in deine Abfragen ein:
Bei Eingang high
while(32==0)
while(0==1)
while(0)
while(32!=1)
while(32!=0)
while(32==1)
while(32)

Bei Eingang low
while(0==0)
while(0==1)
while(1)
while(0!=1)
while(0!=0)
while(0==1)
while(0)

Und dann überlegst du, ob die jeweilige Bedingung 0 (=false) ergibt. 
Falls die Bedingung falsch ist oder 0 ergibt, dann wird die Schleife 
abgebrochen. Ist sie ungleich 0 oder wahr, dann wird die Schleife 
ausgeführt. So einfach ist das. Da muss man nicht wirr herumstochern...


EDIT: Korrigiert entsprechend nachfolgendem Post...  :-/

Lothar M. schrieb:
> es gilt !0b00100000 = 0b11011111 = 0xdf = 223

Es gibt da einen kleinen Unterschied zwischen dem Logischen und dem 
Binären nicht, und im code wurde das Logische verwendet. Also 
!0b00100000 = 0b00000000 = 0x00 = 0 und !0b00000000 = 0b00000001 = 0x01 
= 1.
Das Zeichen für Binär nicht ist '~'.

Lothar M. schrieb:
> So einfach ist das.
DANKE!

Lothar M. schrieb:
> Da muss man nicht wirr herumstochern...
Verzweifelungsaktivismus ;-/

Lothar M. schrieb:
> Was kommt bei PINB & (1<<PB5) raus?
> 1) wenn der Pin high ist: 0b00100000 = 0x20 = 32
Folgendes funktioniert leider auch nicht. Habe noch kein Ausgabedisplay 
um interne Zustände sichtbar zu machen.
while((PINB&(1<<PB5))==32); // PB1=1 soll Schleife stoppen

Wie kann ich sicher sein, dass bei
PINB&(1<<PB5) = 0b00100000 = 32
alle Bits ausser PB5, garantiert 0 sind?

Müsste nicht erst einmal der PINB komplet ausgelesen und im Anschluss 
verglichen werden?

__Son´s B. schrieb:
> Wie kann ich sicher sein, dass bei
> PINB&(1<<PB5) = 0b00100000 = 32
> alle Bits ausser PB5, garantiert 0 sind?
Gar nicht, das ist für diese Abfrage auch uninteressant. Hier wird nur 
das Bit PB5 betrachtet (der Profi sagt "verUNDet" oder "ausmaskiert").
Wenn du abfragen willst, ob der gesamte Port genau den Wert 0b00100000 
hat, dann musst du so schreiben:
if (PINB = (1<<PB5)) ...

> Wie kann ich sicher sein, dass bei
> PINB&(1<<PB5) = 0b00100000 = 32
> alle Bits ausser PB5, garantiert 0 sind?
Mal angenommen, der PB wäre real 0b10101010, dann bleibt durch die UND 
Funktion mit (1<<PB5) also 0b00100000 noch genau 0b00100000 übrig.

__Son´s B. schrieb:
> while((PINB&(1<<PB5))==32); // PB1=1 soll Schleife stoppen
Der Compiler wertet nur den Code aus, nicht die Kommentare!
Im Code wird Pin 5 am Eingangsport B abgefragt...

__Son´s B. schrieb:
> Wie kann ich sicher sein, dass bei
> PINB&(1<<PB5) = 0b00100000 = 32
> alle Bits ausser PB5, garantiert 0 sind?

Meinst du auf das Resultat von PINB & (1<<PB5) bezogen?
PB5 ist 5. 1<<PB5 ist 32 ist 0b00100000. Ein einzelnes '&' zeichen ist 
binär und. Es bleibt also so oder so nur das Bit von PB5 übrig:

PINB    a b c d e f g h
1<<PB5  0 0 1 0 0 0 0 0
-----------------------
Result  0 0 c 0 0 0 0 0

Falls du aber wissen willst, ob keines der Bits von PINB ohne PB5 
gesetzt ist, dann wäre dass so: !( PINB & ~(1<<PB5) )

PINB       a b c d e f g h
~(1<<PB5)  1 1 0 1 1 1 1 1
---------------------------
           a b 0 d e f g h

Lothar M. schrieb:
> Wenn du abfragen willst, ob der gesamte Port genau den Wert 0b00100000
> hat, dann musst du so schreiben:
> if (PINB = (1<<PB5))

c'mon, da müssen 2 gleich hin: if (PINB == (1<<PB5))

Daniel A. schrieb:
> c'mon, da müssen 2 gleich hin: if (PINB == (1<<PB5))
Ach schlags kaputt. Ich mache gerade VHDL, da reicht eines...  ;-)

Daniel A. schrieb:
> Meinst du auf das Resultat von PINB & (1<<PB5) bezogen?
Ja, es geht mir nur(!) um den Status von PB5! Daher ist die Maskierung 
richtig.

Ich möchte folgendes;
wenn an PB5 ein high anliegt, soll die Schleife durch while(...); 
gestoppt/angehalten werden. Aber nur dann!

DDRB &= ~(1<<PB5);  // ATTiny85

--Bsp.1--
Wenn also 0b0010 0000 anliegt, sollte der Vergleich
((PINB&(1<<PB5))==32)
"wahr", oder "1" sein!?

--Bsp.2--
Genau so, wenn 0b0010 0000 anliegt, müsste der Vergleich
((PINB&(1<<PB5))!=0)
gneauso "wahr" oder "1" sein!?

Warum klappt das nicht bei mir?

__Son´s B. schrieb:
> soll die Schleife durch while(...); gestoppt/angehalten werden.
Eine kleine Wiederholung: eine Schleife wird nicht "angehalten" oder 
"gestoppt". Sie wird "beendet", denn der Prozessor läuft mit Vollgas 
weiter...

> Wenn also 0b0010 0000 anliegt, sollte der Vergleich
> ((PINB&(1<<PB5))==32)
> "wahr", oder "1" sein!?
Richtig. Und dann läuft die Schleife noch einmal durch. Es reicht aber 
auch aus, auf
if  (PINB&(1<<PB5)) ...
abzufragen, denn dann ist das bei einem High am Pin B5 gleich wie
if (32) ...
und 32 ist ungleich 0 und damit wird die Schleife nochmal durchlaufen.

> Warum klappt das nicht bei mir?
Sehr wahrscheinlich, weil du noch was anderes falsch machst. Gern werden 
z.B. Taster mit Pullups nach GND geschaltet, und dann ist der Eingang 
natürlich '0', wenn die Taste gedrückt ist....

Was spricht eigentlich gegen die Verwendung der Makros "bit_is_set" bzw. 
"bit_is_clear"?

1

bit_is_set(PINB, PB5)

Könnte doch einige Verwirrung vermeiden. Und wenn man partout den 
Programmablauf unterbrechen will gibt es "loop_until_bit_is_set" bzw. 
"loop_until_bit_is_set".

Lothar M. schrieb:
> Richtig. Und dann läuft die Schleife noch einmal durch. Es reicht aber
> auch aus, auf
> if  (PINB&(1<<PB5)) ...
Genau hier setzt mein Verstehen aus, diese Befehlt, egal ob if() oder 
while() funktioniert bei mir nicht. Egal ob 1 oder 0 an PB5, Schleife 
wird nicht ausgeführt.

Lothar M. schrieb:
> Sehr wahrscheinlich, weil du noch was anderes falsch machst. Gern werden
> z.B. Taster mit Pullups nach GND geschaltet, und dann ist der Eingang
> natürlich '0', wenn die Taste gedrückt ist....
Kein Pull-up eingeschaltet.
Externer Pull-down über 100k auf Gnd!

J.-u. G. schrieb:
> bit_is_set(PINB, PB5)
Danke, aber ich möchte erst einmal die Bit-Manipulation und deren 
Vergleiche vollständig verstehen.

__Son´s B. schrieb:
> Kein Pull-up eingeschaltet.
> Externer Pull-down über 100k auf Gnd!
Mal davon abgesehen, dass mir dazu nur "Warum" einfällt: was sagt das 
Messgerät?

Lothar M. schrieb:
> was sagt das
> Messgerät?
Bei externem 10k Pull-down, "0V", solang kein Vcc anliegt.