I would like to know when it is best to use a switch case versus an If..then?
Is the core interpreted the same by the arduino ?
I have to sensors connected to two different inputs. These inputs then trigger two corresponding triggers.
// Code for First Sensor
if (VoltageX < 10)
{
digitalWrite(Pin12, HIGH);
delay (5000);
digitalWrite(Pin12, LOW);
}
else
{
digitalWrite(Pin12, LOW); // this line is there to reset the pin to low. is it really needed? is there a better way to do this? I dont want the pin to float.
}
// Code for Second Sensor
if (VoltageY < 10)
{
digitalWrite(Pin11, HIGH);
delay (5000);
digitalWrite(Pin11, LOW);
}
else
{
digitalWrite(Pin11, LOW); // this line is there to reset the pin to low. is it really needed? is there a better way to do this? I dont want the pin to float.
}
along the fact that is makes is easier to code etc, I read the switch cases are not evaluated in order like an IF then statement?
this suggest that the case is more efficient and in a way simultaneously evaluates each scenario?
Well, you can. But you need two switch statements. You can also use the default case to provide the 'else' part as well as to finish when a pin is set high.
makes sense, (somewhat).
so I need to pick a specific value and map it to a case.
Is there a way to say that if the sensorvalue is 5 then do the default case (Pin to low) and any other value to run another case which sets the pin to high? or is the sensorvalue falls within a range go to this case etc?
Maybe something like:
int range = map(sensorReading ==5, 0);
int range = map(sensorReading !=5,1,2);
please forgive the bad or incorrect syntax. I am trying to digest a ton of info right now.
Basically, if the sensor reading is 5 then go to case 0, otherwise go to case 1 and 2
Delta_G:
Switch isn't really appropriate for ranges. You can do it, but it's not really worth it compared to an if/else structure when you have ranges.
Where switch really pays is when you have discrete values of something, like how many coins were put into the machine or what number choice did the user select.
I see, can you maybe answer this?
I have several sensors with if's then's. They all work independently from each other but some may trigger the same output etc.
does the order in which I program they IF statements have any implication of their operation versus he case?
Delta_G:
Switch isn't really appropriate for ranges. You can do it, but it's not really worth it compared to an if/else structure when you have ranges.
Rubbish, far less work. What do you think C++11 added ranged switches for??
0 ... 9 compared to ( x >= 0 && x <= 9 )
crullier:
Thanks Pyro makes sense,
but regardless I have to assign/map a specific "sensorvalue" (analogread) to each case.
Is there a way to say that if the sensorvalue is 5 then do the default case (Pin to low) and any other value to run another case which sets the pin to high? or is the sensorvalue falls within a range go to this case etc?
You can setup your switch to look for single values or a range:
switch( x ){
case 0: break;
case 256: break;
case 512: break;
case 768: break;
}
switch( x ){
case 0 ... 255: break;
case 256 ... 511: break;
case 512 ... 767: break;
case 768 ... 1023: break;
}
Your problem more specifically can be :
switch( sensorvalue ){
case 0 ... 4:
case 6 ... 9:
break;
default: //5 will enter here.
digitalWrite( pin, LOW );
}
You might want to see what the compiler does either way. Might be the same, might not.
switch( x ){
case 0 ... 255: break;
case 256 ... 511: break;
case 512 ... 767: break;
case 768 ... 1023: break;
}
if ( x < 256 ) // given x is unsigned or always 0 or more
{
// code
}
else if ( x < 512 ) // one compare per slice
{
// code
}
else if ( x < 768 )
{
// code
}
else if ( x < 1024 )
{
// code
}
else
{
// error code?
}
When I've looked at AVR code produced by a swicth statement, it's usually identical to an if/else string.
There may be cases where the values are particularly "dense" and a jump table is generated instead.
I'd use whichever made more sense from a logic point of view, and then MAYBE test the other way if the code turned out to be too slow or big.
One other thing. The regularity of those ranges leaves me wondering if what each case does is similar enough to package the whole into a single formula that doesn't need any branching or code-per-case at all.