# modulo operator, a percentage sign (%)

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
delay(10);
//digitalWrite(Debug_IO11, HIGH);

}
``````

if (cycles % 20 == 0)

totally guessing cause' you don't state what you want.

Sorry the intent of this is if the cycles are evenly divisible by 10 then read the eeprom if cycles are above 20.

What you have should go through for 30, 40, 50, 60, etc, etc.

What values of cycles are you actually seeing it go through for?

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.

``````      if ((cycles > 20) && ( (cycles % 10) == 0) ){ //debug for rev 1.7 && cycles % 10 == 0
``````

Pete

Bitwise and bitshift operators in particular are not executed in the order you'd intuitively expect.

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

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

DO you expect 27 here or 39 ?

@rr1024 - sorry, somehow I missed your explanation in msg #2. Try parenthesizing the statement as I showed and see if that works.

Pete

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

If that part of the code works fine, what exactly is it we’re supposed to be helping you with?
Post your code. All of it. In code tags.

Pete

Thanks Pete, that seem to do the trick ;-)

el_supremo: @rr1024 - sorry, somehow I missed your explanation in msg #2. Try parenthesizing the statement as I showed and see if that works.

Pete

Sorry Pete that post about "that part of the code works" was concerning someone elses comment about "FR_INTERVAL = EEPROM.read(13*2+1)

DO you expect 27 here or 39 ?"

You hit the nail on the head, it was the braces

el_supremo: If that part of the code works fine, what exactly is it we're supposed to be helping you with? Post your code. All of it. In code tags.

Pete

This seem to do the trick thanks

if ((cycles > 20) && ( (cycles % 10) == 0) ){ //debug for rev 1.7 && cycles % 10 == 0 FR_INTERVAL = EEPROM.read(13*2+1) * 256 + EEPROM.read(13*2); }

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

Pete

I don't think there is anything wrong with

``````if ( cycles > 20 && cycles % 10 == 0 ) { }
``````

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)

or

((cycles > 20) && (cycles % 10)) == 0

Operator precedence tables tells me it is:

(cycles > 20) && ((cycles % 10) == 0)

Is that what you interpreted it as ?

((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.

If the OP is claiming that his program didn't work with

if ( cycles > 20 && cycles % 10 == 0 ) { }

and does work with

if ( (cycles > 20) && ((cycles % 10) == 0) ) { }

then if that is really the only difference between the two versions of his sketch, I'd be quite concerned.