Variable never assigns value

I'm trying to debug something, so this code doesn't do anything useful. It does, however, reproduce the bug I'm trying to understand.

Basically, I have a button sensor connected to digital pin 10. Strangely, when not pressed, the button reads digital "HIGH" and when pressed, reads "LOW."

This is not the problem.

I want to run a function called confirm() that will output the opposite of the button press, AND assign the value of the press, swState, to another variable, swState_0.

Everything happens except for the assigning of variable swState_0.

If I can understand why this doesn't work, then I can get my main sketch to work. Please see serial monitor output attached as an image.

const int sw = 10;

bool swState;
bool swState_0;

void setup() 
{
  Serial.begin(9600);

  pinMode(sw, INPUT);

  swState_0 = digitalRead(sw);
}

void loop() 
{
  Serial.print("swState: ");
  Serial.print(swState);
  Serial.print("   ");
  Serial.print("swState_0: ");
  Serial.print(swState_0);
  Serial.print("   ");
  Serial.print("Confirm: ");
  Serial.println(confirm());
}


 
bool confirm()
{
  swState = digitalRead(sw);
  
  if(swState == LOW)
  {
   return HIGH;
  }
  else
  {
   return LOW;
  }

  swState_0 = swState;
  
}

serial.png

What do you think happens in a function when you hit a "return"?

CPmkI:

bool confirm()

{
  swState = digitalRead(sw);
 
  if(swState == LOW)
  {
  return HIGH;
  }
  else
  {
  return LOW;
  }

swState_0 = swState;
 
}

The function returns (exits) before the assignment can happen. The last statement is unreachable code.

It's not good practice to change the value of global variables inside of your functions. You can never be sure of the side effects when calling such a function, making it a nightmare to debug, and it is not easy to read and understand your code.

Your approach to inverting the value can be done more efficiently:

swState_0 = !swState;

Reference logical not operator

Pieter

Basically, I have a button sensor connected to digital pin 10.

You have a sensor that senses buttons? That makes no sense.

PaulS:
You have a sensor that senses buttons? That makes no sense.

It makes perfect sense!

Only the presence of a button can trigger this sensor.

AWOL:
What do you think happens in a function when you hit a "return"?

I guess I thought it would continue to execute the rest of the code after returning the value.
Buuuuuuuut, I guess not.

Thanks! Now I can move forward.

CPmkI:
It makes perfect sense!

Only the presence of a button can trigger this sensor.

Can you post a link to the sensor that can sense buttons?

CPmkI:
Basically, I have a button sensor connected to digital pin 10. Strangely, when not pressed, the button reads digital "HIGH" and when pressed, reads "LOW."

this is not strange depending on how the button is wired... an INPUT_PULLUP would do this

CPmkI:
I want to run a function called confirm() that will output the opposite of the button press, AND assign the value of the press, swState, to another variable, swState_0.

why don't you just compare with LOW for pressed ? you know it's wired that way, why do extra computation to fit your mental model..

Alternatively your could do#define BUTTON_PRESSED LOWand when you need to test doif(digitalRead(buttonPin) == BUTTON_PRESSED) { ...then the code is self documenting.

Also - call me picky - but LOW and HIGH are not boolean concepts. true and false are boolean values. So use the right concepts in the right place. if your confirm() function needs to return something, then use the right values.

PieterP:
It's not good practice to change the value of global variables inside of your functions.

During run-time, the only place the value of a global (or any) variable can be changed is inside a function.

I guess it could happen via DMA, but that's not applicable here.

J-M-L:
this is not strange depending on how the button is wired... an INPUT_PULLUP would do this

why don't you just compare with LOW for pressed ? you know it's wired that way, why do extra computation to fit your mental model..

Alternatively your could do#define BUTTON_PRESSED LOWand when you need to test doif(digitalRead(buttonPin) == BUTTON_PRESSED) { ...then the code is self documenting.

Also - call me picky - but LOW and HIGH are not boolean concepts. true and false are boolean values. So use the right concepts in the right place. if your confirm() function needs to return something, then use the right values.

Yes, in my actual project, I am using the values produced by the button directly; no problems there, and no need to convert. My mental model as presented here was just to get feedback on why I was able to get certain values to change, but not the reassignment of swState_0. That's clearly due to my misunderstanding of how return works.

Your point about my use of the wrong values for boolean variables brings up another question I've been wondering about: most example sketches I've come across use int type variables to represent an on/off situation. But if only 0 and 1 are being used, why use a variable type that can support so many more values? Is there a good reason to use int instead of bool in the case of a variable that can only take on two different values?

Is there a good reason to use int instead of bool in the case of a variable that can only take on two different values?

There is a reason - laziness. It is NOT a good reason.

CPmkI:
Is there a good reason to use int instead of bool in the case of a variable that can only take on two different values?

yes if these values needs to be something else than 0 and 1 and won’t fit in a int8_t...