I'm learning the Switch Case, Control Structure but there seems to be a problem with the board or my equipment somewhere.
I'm working on the example #2 (SwitchCase2). While the leds do turn on when I enter the specified input through the Serial Monitor ('a', 'b', 'c', etc), they instantly turn off.
As far as I understand the leds should remain ON [digitalWrite (x, HIGH)], and only turn off if there was an input different from the 'cases' that I have assigned, correct?
Any ideas what might be happening for the leds NOT to stay ON as they should? I can't work it out!
OK. It's the IDE "File\Examples\05.Control\switchCase2", but here it is:
/*
Switch statement with serial input
Demonstrates the use of a switch statement. The switch
statement allows you to choose from among a set of discrete values
of a variable. It's like a series of if statements.
To see this sketch in action, open the Serial monitor and send any character.
The characters a, b, c, d, and e, will turn on LEDs. Any other character will turn
the LEDs off.
The circuit:
* 5 LEDs attached to digital pins 2 through 6 through 220-ohm resistors
created 1 Jul 2009
by Tom Igoe
This example code is in the public domain.
http://www.arduino.cc/en/Tutorial/SwitchCase2
*/
void setup() {
// initialize serial communication:
Serial.begin(9600);
// initialize the LED pins:
for (int thisPin = 2; thisPin < 7; thisPin++) {
pinMode(thisPin, OUTPUT);
}
}
void loop() {
// read the sensor:
if (Serial.available() > 0) {
int inByte = Serial.read();
// do something different depending on the character received.
// The switch statement expects single number values for each case;
// in this exmaple, though, you're using single quotes to tell
// the controller to get the ASCII value for the character. For
// example 'a' = 97, 'b' = 98, and so forth:
switch (inByte) {
case 'a':
digitalWrite(2, HIGH);
break;
case 'b':
digitalWrite(3, HIGH);
break;
case 'c':
digitalWrite(4, HIGH);
break;
case 'd':
digitalWrite(5, HIGH);
break;
case 'e':
digitalWrite(6, HIGH);
break;
default:
// turn all the LEDs off:
for (int thisPin = 2; thisPin < 7; thisPin++) {
digitalWrite(thisPin, LOW);
}
}
}
}
Wow, that's cool, now I can actually 'see' the information that I'm sending to the board.
Using Serial.println(inByte), if I type an: 'a' it triggers:
97
13
10
Using Serial.println(inByte, HEX), if I type an: 'a' it triggers:
61
D
A
I somewhat understand the output of 'Serial.println(inByte)', but have no idea about the one of 'Serial.println(inByte, HEX)'.
My keyboard input was obviously triggering some more cases than what I was intending to and noticed that there is a drop menu on the serial monitor that was set to 'BOTH NL & CR'. I have no idea what this is, but when I change it to 'No line ending', now it works! (Serial.println(inByte) returns a 61 when I enter an 'a' as expected).
Thank you guys! May I ask what this drop menu options are? No stress about replying I can look for that information somewhere else. Now the main problem is solved!
As I suspected, the carriage return/line feed characters were triggering the defaut case.
If you don't want that, set line endings to "none".
A normal serial terminal sends a character when you press a key, but the serial monitor sends all the characters in one go when you click the "send" control.
There are several conventions for marking the end of a line - either a CR (carriage return), an LF (Linefeed, also called NL, for newline), or both CR and LF. IIRC, unix-like OS's use LF, and windows uses CR LF, and pre-OS-X macs used CR alone. (this is why when you open a text file from a linux machine in many windows text editor, all the linebreaks are gone).
In the same vein, CR and/or LF are often used as end-of-line or end-of-command markers in serial communication to mark the end of a command (so the receiving code will add the bytes it gets to a buffer until it sees it's preferred end-of-line marker, at which point it would try to parse what it has sitting in it's buffer)
So in the monitor, when you press enter, it sends what you've typed immediately followed by the selected line ending.
If your code knows about this, it's a useful feature. If it doesn't, it does stuff like this
