light with push button

I have used arduino mega and reviewed some examples. I tested a led light with push button below


int ledPin=8;
int buttonPin=2;
int buttonState=0;
void setup() {
// put your setup code here, to run once:
pinMode(ledPin,OUTPUT);
pinMode(buttonPin,INPUT);

}

void loop() {
// put your main code here, to run repeatedly:
buttonState=analogRead(buttonPin);
if(buttonState==HIGH){
digitalWrite(ledPin,HIGH);

}
else{
digitalWrite(ledPin,LOW);
}

}


Yesterday, it worked and checked the buttonState values (0 or 1) on Serial monitor. I didn't have any issues.

Today, when trying this, it didn't work. The led light was brinking after connecting the power up and the button was not working. The value of the buttonState on the Serial monitor was coming around 300.

So I suspected that a programming was still running. That was why I didn't get the values of 0 or 1 instead of around 300. My suspect was that a programming of photoresistor is still runing, so the values on the screen were within the ranges which I tested it yesterday.

My question is how to clear this.

Thanks, Jae

  buttonState=analogRead(buttonPin);
  if(buttonState==HIGH){

It's pretty unlikely that a reading in the range 0 to 1023 will be EXACTLY 1.

(This isn't an installation or troubleshooting question)

Please remember to use code tags when posting code

And when you do change to digitalRead() - remember the pull-up / or resistor if not already there

Observations: //*** suggestions

int ledPin=8;     //*** replace with: static const byte ledPin = 8;
                  //*** constants should be declared as const; the compiler can
                  //*** generate better code
int buttonPin=2;  //*** replace with: static const byte buttonPin = 2;
int buttonState=0 //*** There is no reeason to declare this as a global variable; make it a local
//*** Leave at least one blank line before function definitions.  Makes the code more readable

void setup() {
  // put your setup code here, to run once:
  pinMode(ledPin,OUTPUT);
  pinMode(buttonPin,INPUT);  //*** should be INPUT_PULLUP, button grounds pin

}

void loop() {
  // put your main code here, to run repeatedly:
  buttonState=analogRead(buttonPin); //***buttonPin is not an analog pin!
  int buttonState = digitalRead(buttonPin); //*** This is the correct way to read a digital pin
 //*** Note that since buttonState is only needed inside loop(), it should not be declared
 //*** at any greater scope

  if(buttonState==HIGH){  //*** If using INPUT_PULLUP, HIGH means button *not* pressed
                                         //*** You did not specify the circuit, but thre correct circuit would be

    //***   |  o----------------| 2           |
    //***  -|                   |    Arduino  |       R1             LED
    //***   |  o-----+          | 3         8 |---/\/\/\/\/\---------|>|------- GND
    //***            |          :
    //***           GND         :
     
    digitalWrite(ledPin,HIGH);   
  }
else{
digitalWrite(ledPin,LOW);
  }

} // loop  //*** I have found this convention to improve readability

//*** This whole loop contains unnecessary complexity.  The entire body of loop() should be
  void loop()
    {
     digitalWrite(ledPin, !digitalRead(buttonPin));
    }

You could also use a pulldown resistor, with the button connecting to +V, so LOW means "not pressed" and HIGH means "pressed", but pulldown resistors are uncommon, and INPUT_PULLUP saves you putting an explicit pullup resistor in place.

You can't give a software example like this without specifying the schematic of what it is getting as input and how the output is controlled.

The input to a pin must always be well-defined. That is, it can be HIGH or LOW, but it cannot be "unconnected". INPUT_PULLUP puts an ~50K pullup resistor connecting the pin to HIGH, and pushing the button sets it to LOW. If it is unconnected, you will see random behavior. And analogRead is "not defined" for a digital input pin, and thus is free to do anything, such as have a behavior indistinguishable from calling random().

Note that this works OK with an LED, but if you care about the button presses, you will have to "debounce" the button, because the button will produce more than one "pressed" signal and more than one "released" signal; you have to wait 5-10ms before trusting the button state. Google for "debounce" and study the code. Any form of delay() is usually considered a bad idea, so look for non-delayed debouncing. For complex code with real-time constraints, delay() can be fatal to correct response.
joe