Hello again everyone.
I've been tinkering for a couple of hours now and I'm not getting anywhere so i thought i might pitch it here to see if anyone knows what i should do next.
Lets start with the problem code.
for (int i = fade_min(adjust) ; i <= 1023 ; i+=fade_increment){
set_rgb(analogRead(red_in)/1023 * i,
analogRead(green_in)/1023 * i,
analogRead(blue_in)/1023 * i);
fade_delay(adjust);
}
fade_min(adjust) returns zero.
Fade_increment is 1.
Fade_delay(adjust) just delays for a few milliseconds.
Basically, the calculation that happens to divide by 1023 then multiply by i seems to randomly return zero sometimes.
I did a serial print in the set_rgb routine and get this kind of thing in hyperterminal.
notice the rouge zero?
I thought maybe its the analog inputs, but they work perfectly smooth for a manual mode i have.
I also tried splitting up the parts of the calculation and then feeding only a variable to the set_rgb line thinking it was too much for one step, but none of that seems to change anything.
The zero could also show up on either the red, green or blue column.
Hi,
If you divide by 1024 you are in effect going to get a number less than 1 and so it goes to zero. This is because you have an integer division.
So convert or cast to float before the division or find an integer way of expressing what you want to do.
In general, do any multiplications BEFORE doing any divisions, and ensure your variable type can fit the product without overflowing. Since 1024 is 210, you need at least 20 bits for 1024*1024, bigger than a 16-bit int but well within the range of a 32-bit long.
For some ungodly reason, casting to float at the very beginning seems to have fixed it.
set_rgb((float)analogRead(red_in)/1023 * i,
(float)analogRead(green_in)/1023 * i,
(float)analogRead(blue_in)/1023 * i);
What i don't understand is why its all perfect, but then just randomly goes to zero. In my previous hyperterminal example, they were all just basically counting up to 1023 since the analog inputs were all set to max.
It just doesn't bode well in my mind.
I want to test it more to figure out whats going on, but its pretty late so i need to call it a night.
I think i originally wrote it similar to what you suggested halley, but i thought i should divide then multiply to stop the numbers getting too big. I generally like to work with ints (they are nice) but set_rgb fundamentally uses floats for scaling, so the float solution is probably simpler.
Thanks Grumpy Mike (as usual) and Halley for replying nice and quick to help me out!
The reason is that the division was being done with integer arithmetic, as others have said.
What i don't understand is why its all perfect, but then just randomly goes to zero
It wasn't random, it was giving you a zero every time the result of division by 1023 gave a result that was less than 1. This is what you'd expect with integer division. Floating-point division will give you a fractional result, which makes the overall calculation give you the result you want. It's much slower, of course.
But each column carries out the exact same operation since the red, green and blue channels were all set to maximum. Why does only the calculation on the red go to zero for just 1 value in a nice simple count?
if it did it for all of them, i would understand, and i get what you guys are saying about dividing going below zero, but it works 99% of the time with that occasional hiccup. (as i saw from hyperterminal)