Less Than operator not working?

Troubleshooting
1

I know this sounds as crazy as the day is long, but I’m having difficulty figuring out why the “<” less-than operator isn’t working in my IF statement. Somehow, it always returns TRUE.

“chDat”, “rVal”, “tmp”, etc. are all type INT.

        chDat = analogRead(A6);
        rVal = ReadEEWord(cfgRulesVal);

        tmp = rVal / 20;      // set "about" to 10% up/down (5% either way)
        switch (rChan >> 6)   // returns 0-3; rChan is a CHAR (byte)
        {
          case 1: if (chDat < rVal) goto Trap;                                      // LESS THAN
          case 2: if ((chDat > (rVal - tmp)) && (chDat < (rVal + tmp))) goto Trap;  // ABOUT
          case 3: if (chDat > rVal) goto Trap;                                      // MORE THAN
        }
        // 4: If we got here, the condition does not match.
        continue;   // Jump to the next iteration of the FOR{}

        // 4: Condition matches
Trap:   {...}

The “more than” works perfectly, as does the first half of “about.” BUT…if “less than” is specified, execution always jumps to Trap: regardless of the input value. I don’t need BREAKs on the SWITCH, as the GOTO pretty much takes care of that. (Yes, harp on me about using GOTO all you want…but AFAIK, that’s not the problem!)

As in:
condition LESS THAN: chDat = 501, rVal = 58 -> Trap (Condition TRUE)?!?!?!
condition LESS THAN: chDat = 0, rVal = 58 -> Trap (TRUE)
(There’s no way to make this condition return false)

condition ABOUT: chDat = 0, rVal = 2984 -> continue (FALSE)
condition ABOUT: chDat = 2888, rVal = 2984 -> Trap (TRUE)
condition ABOUT: chDat = 4096, rVal = 2984 -> Trap (TRUE)!?!??!?!

MORE THAN works as expected:
condition MORE THAN: chDat = 2986, rVal = 3686 -> continue (FALSE)
condition MORE THAN: chDat = 4032, rVal = 3686 -> Trap (TRUE)


What in the world is going on? Is it my code, or a seemingly impossible bug in the Core firmware? All my FOR{var, var < 45; var++} loops are working correctly, so I'm really confused.
2

Have a printout of all the variables in your condition.
e.g. in case 2, if tmp is actually negative you might get unexpected results.
Where does rChan come from?

As @peekay123 also points out goto only takes care when if() hits.

3

@WebDust21, you need to track which case statement jumped to Trap. Based on your rules, the first item on your list (chDat = 501, rVal = 58) will get to Trap from case 3 since there are no breaks in your code. Both case 1 and 2 will fail and fall to case 3.

I believe you are trying to test that chDat is WITHIN a 5% upper and lower bound. Your case 2 seems to do that but not cases 1 and 3. :smile:

2 Likes
4

@peekay123 Ah, well…now I feel so dumb. I do need those BREAKs after all. How dumb…bummer!
I was figuring that it was extremely unlikely that “<” didn’t work… :grimacing:

@scruffR…TMP can’t be negative. rVal will be from 0-4095.

1 Like
5

rVal comes from ReadEEWord(), have you checked that you actually do get the correct values back?

Anyway, the missing break solves it anyway :wink:

6

@ScruffR @peekay123 Well, it works perfectly with the BREAKs. I’m generally not one to post a question until I’ve pretty much given up on finding a solution, but sometimes I forget I’m programming in C, not BASIC. Thank you both for putting up with my dumb question.

@ScruffR: rChan comes from a byte EEPROM read, which is based on the For{} loop’s variable.

(P.S. @peekay123 2 coffees if I’m ever in Canada… :wink:)

1 Like