cycles++;
Hello,
I'm wondering what I'm doing wrong in the statement, if I remove the "&& cycles % 10 == 0" then after 20 cycles the EEprom is read and I can see it with the debug pin and the fact it changes the period of the loop which is FR.
Does anyone see what bone head mistake I'm making this time...lol
cycles++;
// modulo operator, a percentage sign (%), gives the remainder of a division of two values
digitalWrite(Debug_IO11, HIGH); //Debug IO13 pin 18
if (cycles > 20 && cycles % 10 == 0){ //debug for rev 1.7 && cycles % 10 == 0
delay(10);
digitalWrite(Debug_IO11, LOW); //Debug IO13 pin 18
FR_INTERVAL = EEPROM.read(13*2+1) * 256 + EEPROM.read(13*2);
delay(10);
//digitalWrite(Debug_IO11, HIGH);
}
Operator precedence is the problem.
When you write a compound conditional like that you really need to parenthesize it so that it will execute the way you want.
However, when I try to "parse" that statement, it seems that it should work the way I showed but without any parentheses to force the order of operations. @rr1024. You've said what happens when you remove "&& cycles % 10 == 0", but you haven't explained what it is doing wrong when you leave it in.
If I leave the "&& cycles % 10 == 0" it never enters the statement, and I know that because the debug pin "Debug_IO11", never changes state.
el_supremo:
However, when I try to "parse" that statement, it seems that it should work the way I showed but without any parentheses to force the order of operations. @rr1024. You've said what happens when you remove "&& cycles % 10 == 0", but you haven't explained what it is doing wrong when you leave it in.
Pete
I'll give your suggestion a try i.e. if ((cycles > 20) && ( (cycles % 10) == 0) ) see if that helps
I would imagine 27 but that part of the code works fine, I have the eeprom read during setup and I know the value that is loaded is correct because it controls the period of a pulse and on the scope it comes out correct.
The reason why I'm reading the value again is because there is abug which is changin or over writing it somethere....so I'm trying track it down
OK, good. So the parentheses do force a different order of evaluation than when they are absent. I'll have to brush up on what I thought I knew about operator precedence and try to figure out what the compiler produces in the absence of the parentheses
and even though I like parentheses myself, this should work anyway because the precedence of the operators in that expression should correspond to that the OP intended.
Can any of the people who claim that parentheses are actually required here, show how the statement without parenthese is actually being parsed in a non-obvious way ?
michinyon:
I don't think there is anything wrong with
if ( cycles > 20 && cycles % 10 == 0 ) { }
Well, if everyone agreed on and remember operator precedence then it's all good to say that.
But for me I was stuck on if it meant:
(cycles > 20) && ((cycles % 10) == 0)
This is the wrong way, and doesn't even make sense.
The left part ( cycles > 20 ) is a logical , it's either bigger than 20 or it isn't.
You want to take a logical and of that with ( cycles % 10 ), which is a number, so it is going to be true if it is non-zero. You combine those two logicals, and then compare the result for equality to zero ???
I guess you could do all that, but it would not make sense. And anyway, that's not how the operator precedence works.
(cycles > 20) && ((cycles % 10) == 0)
is the correct one, and apparently what the OP intended to do. This should be true when cycles = 30 , or 40, or 50, or 60, as someone already said.
