I have three variables to represent RGB colour values and I am getting an unexpected result. When I start to debug I notice that the readings were also unexpected.
If I just read G it now reads 51.
If I read any of the three variables seperately they read 51.
If I read G and B it reads 0 and 51 respectively.
If I read R and G it reads 51 and 0 respectively.
If I read B, R and G it reads 0, 51 and 2167 respectively. B and R swapped values.
FYI all three analogRead() equal an expected 1023.
My question is how can the variables change just by the way they are read?
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
}
void loop() {
// put your main code here, to run repeatedly:
int a, b, c;
for (int i = 0; i < 20; i++) {
a += 1;
b++;
c++;
}
Serial.print(a);
Serial.print(" ");
Serial.print(b);
Serial.print(" ");
Serial.println(c);
}
The value of local variables declared but not initialised in a function is undefined, ie they could have any value and that value could be different in subsequent calls to the function.
Variables declared as global (and local static variables) have an initial value of zero unless another value is defined for them
Not sure what the calculations are supposed to be doing, but they are certainly not going to do what you expect. You are doing integer divide of a number between 0 and 1023, by 1023. The only result you'll ever see from that division is 0 (for any analogRead result between 0 and 1022) or 1 (for and analogRead result of 1023).
analogRead returns an integer.
1023-analogRead() will still be an integer.
Therefore, the divinsion will be an integer division and it will round down to zero.
This means that the result of the expresssion will be 255 if analogRead() is zero, 255 otherwise.
Thanks for all of your quick responses, but I do find that the responses thus far have been difficult to accept as truth. I will make a few changes (using map()) - though the code runs fine.
My original question was why am I getting different results from my Serial print but no one seems to have come across this issue before. I suspect that the Baud rate slows the program upon Serial print thus shifting the results. I also forgot to mention that the problem occurs when I switch off the analog device and get a 1023 result on each of the analogRead() inputs. Though the results dont account for the wrong results that I am getting. (1023 -1023)/1023*255 = 0
Ray & Pauls comment confuses me - are you saying that the scope of the formula (1023 - analogRead(sensorPinR)) / 1023 * 255 is considered integer during calculation? - I always assumed it became integer once stored in senseR. Im geting good results here so my assumption seems sound.
This type of programming is unforgiving and consideration of chip architecture processes is needed.
For example, in C the use of any automatic variable before it has been initialized yields undefined behavior, ...
Which is exactly what you are doing.
And:
In the C community, undefined behavior may be humorously referred to as "nasal demons", after a comp.std.c post that explained undefined behavior as allowing the compiler to do anything it chooses, even "to make demons fly out of your nose".
So, as I mentioned, you are lucky that demons did not fly out of your nose. Very lucky.
Efly:
This type of programming is unforgiving and consideration of chip architecture processes is needed.
It's C++. Forgiving or not, you need to learn it. People programming Macs, Windows, Androids - they all need to learn how C++ works. It has fundamental rules about the way integers are treated. The compiler implements them. If it didn't people would complain.
