Hi. I am working on a code that turns on different colored lights based on three button inputs but even after many little tweaks I keep getting
Arduino: 1.6.5 (Mac OS X), Board: "Arduino/Genuino Uno"
sketch_nov16a.ino: In function 'void loop()':
sketch_nov16a:18: error: expected primary-expression before 'digitalRead'
sketch_nov16a:18: error: expected ')' before 'digitalRead'
sketch_nov16a:22: error: expected primary-expression before 'digitalRead'
sketch_nov16a:22: error: expected ')' before 'digitalRead'
sketch_nov16a:26: error: expected primary-expression before 'digitalRead'
sketch_nov16a:26: error: expected ')' before 'digitalRead'
expected primary-expression before 'digitalRead'
This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.
const int GREEN = 13;
const int YELLOW = 12;
const int RED = 11;
const int GreenButton = 4;
const int YellowButton = 3;
const int RedButton = 2;
void setup()
{
pinMode(GREEN, OUTPUT);
pinMode(YELLOW, OUTPUT);
pinMode(RED, OUTPUT);
pinMode(GreenButton, INPUT_PULLUP);
pinMode(YellowButton, INPUT_PULLUP);
pinMode(RedButton, INPUT_PULLUP);
}
void loop()
{
if (boolean digitalRead(GreenButton) == HIGH)
{
digitalWrite(GREEN, HIGH);
}
else if (boolean digitalRead(YellowButton) == HIGH)
{
digitalWrite(YELLOW, HIGH);
}
else if (boolean digitalRead(RedButton) == HIGH)
{
digitalWrite(RED, HIGH);
}
else
{
digitalWrite(GREEN, LOW);
digitalWrite(YELLOW, LOW);
digitalWrite(RED, LOW);
}
}
Yeah. That's not how you cast (when you cast, you put the datatype in parenthesis) - but you don't need to. Even if HIGH and LOW were booleans, it wouldn't matter - for one thing, boolean isn't a builtin type, it's just a uint8_t (unsigned 8-bit, same as a byte or unsigned char), defined by a typedef in Arduino.h - and the C implicit type promotion can handle comparing datatypes of different sizes.
But they're not even booleans!
HIGH is #defined as 1, LOW is #defined as 0. So they're ints!
I agree @Delta_G . I only looked into boolean but not if it actually was needed in this, but all it turned out to do was hurt, because these aren't true/false booleans. Thanks
Ya I guess I thought for some reason that 1(HIGH) / 0(LOW) was like true/false . Thanks @Drazzy
It would not have mattered if digitalRead() returned true or false, as opposed to HIGH or LOW, since true and HIGH and 1 are all the same numeric value, and false, LOW and 0 are all the same numeric value.
The point is that the TYPE did not belong there. The function definition may say that the type it returns is boolean, or will fit in a boolean, but that matters only when you are trying to define a variable to hold the return value.
You COULD have tried simply removing the boolean type from the statement, to see what (positive) effect that had, and not looked like a moron posting crappy code. And then trying to justify the crappy code.
PaulS:
You COULD have tried simply removing the boolean type from the statement, to see what (positive) effect that had, and not looked like a moron posting crappy code. And then trying to justify the crappy code.
