Need some help to understand the "while(digitalRead())" command

Hi, guys!

I'm just getting started with Arduino, and I need to make a simple ON/OFF toggle switch, that will turn a LED ON/OFF by pressing it.

Doing some research, I made the code work, but I can't understand the "while" part, so I'd be gratuful if someone could explain it to me! Here's the code:


int ledPin = 12; 
int buttonPin = 4;
int buttonState = false;

void setup()
{
  pinMode(ledPin, OUTPUT);
  pinMode (buttonPin, INPUT);
 }

void loop()
{
  if  (digitalRead(buttonPin)== false){
    buttonState = !buttonState;
    digitalWrite(ledPin, buttonState);
}
  while(digitalRead(buttonPin));
  
  delay(50);
}

So the question is: why it that while command there? And my main question: in the while command, wouldn't the syntax be something like "while(CONDITION) {do something}"?

The way it's written sounds weird to me, because as I read it, it just states the condition, not what it should do when the condition is met (as it happened with the "if" that came before).

The while reads the button pin and loops if the pin is high. When the pin is high it is read as 1 which is treated as true, so it loops until the pin goes low.

yes.
But if you do not need do nothing - the braces can be omitted.

Could also be 'for (;digitalRead(buttonPin););' and other ways..

You can also write a function 'void foo();' or 'void foo(){}; that does nothing...

Anything with a conditional will resolve to a true/false for the machine to act on. More specifically any non zero result is true.


Many functions you can call will return a status code to let the caller know what happened during the call, success/failure... any non zero return from most of these functions are some type of error... Unix in general works this way.

:smiley_cat:

As explained, hangs doing nothing while the digitalRead is HIGH.

Here it would make more sense to

 while(digitalRead(buttonPin) == false);

or equivalent

while(!digitalRead(buttonPin));

then the code woukd read

do something if the read is false
then hang out while it remains false

The delay(50) is a poor man's debouncing solution.

a7

It's while this condition is true, do this. There is just nothing for it to do, except go back and do the 'read' again.

You've changed the condition to the opposite state.

:smiley_cat:

Oh, I guess I got it! Your way of explaining made sense to me! So it's like something to make the "if" from before keep that way, right?

Just one more thing: I had found out that

while(digitalRead(buttonPin));

in this case is the same thing as

while(digitalRead(buttonPin) == false);

But what made me confused was that if I change the false into true, the code works as intended as well...

Let me see if I get this: it's like something to make the "if" from before keep that way, right? So the said "while" depends on some previous condition command. Something link that?

Have you tried:

digitalWrite(ledPin, digitalRead(buttonPin)); 

?

nope
it is the same as

while(digitalRead(buttonPin) == true);`

No you can’t

1 Like

That's the thing that tipped me off: if I change it whether to true or false, the code works as intended.

because it doesn’t make any noticeable difference to the code. Delay is too small to notice.

Also the correct way would be to compare the digitalRead result to HIGH or LOW not true or false

Actually it seems quite likely you aren't getting what you think. Here's the origianl code, more or less, in the wokwi.

Keep your finger on the button. Surprise!

The true behaviour is masked by the speed and how you press the button and so forth.

I placed a comment where it can be fixed, I think @alto777 suggested that.

int ledPin = 12; 
int buttonPin = 4;
int buttonState = false;

void setup()
{
  Serial.begin(9600);
  Serial.println("Hello Whirled!\n");

  pinMode(ledPin, OUTPUT);
  pinMode (buttonPin, INPUT);
 }

void loop()
{
  if (digitalRead(buttonPin) == false) {
    Serial.println("tokkling the LED because");
    buttonState = !buttonState;
    digitalWrite(ledPin, buttonState);
  }

// see this not work. change to (!digitalRead(buttonPin) to fix it
  while (digitalRead(buttonPin)) {
    Serial.println("hanging on that input");
    delay(200);
  }
  
  Serial.println(" a brief delay");

  delay(500);
}

Just to promote the wokwi - I now use it to get most of the logic of a sketch properly functioning, then start all the trouble the real world can bring along.

HTH

a7

There are structures like:
1. if-else

if(conditionIsSatisfied)
{
     //do this
}
else
{
     //do that
}

2. if()

if(conditionIsSatisfied)
{
    //perform these tasks
}

3. do-while

do
{
      //perform these codes
}
while(conditionRemainsSatisfied);     //; (C's line terminating character is here)

4. while-do

while(conditionRemainsSatisfied)
{
    //perform these codes
}

5. Now applying the syntax rules to re-format your sketch of post #1; where, if() and while-do structures are clearly visible.

int ledPin = 12; 
int buttonPin = 4;
int buttonState = false;

void setup()
{
  pinMode(ledPin, OUTPUT);
  pinMode (buttonPin, INPUT);
}

void loop()
{
  if  (digitalRead(buttonPin) == false) //if()
  {
      buttonState = !buttonState;
      digitalWrite(ledPin, buttonState);
  }
  
  while(digitalRead(buttonPin))   //while-do
  {
       ;     //null-statement
  }  
  delay(50);
}

In any case, sketches like this will go easier, once you have a free running loop (thousands of times a second), if you "look at the clock" just once, at the top of your loop, viz:

  unsigned long now = millis(); // time for all this run of the loop

and solicit the inputs that will inform your logic just once, at the top of your loop:

unsigned char buttonReading = digitalRead(buttonPin);

and use now and buttonReading everywhere below that in the loop().

If your logic creates new output values, those could plausibly be digitalWritten, so to speak, atr the end of loop(), which would logically be the same as at the very beginning, because loop(), well, loops.

This is the IPO model of processing. Google it for other exposures:

https://press.rebus.community/programmingfundamentals/chapter/input-process-output-model/

a7

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.