Checking Pin Status In If Statement Works Backwards

[Dave E]

Hello everyone.
I have run across an odd one. I am using a 14M (9B) and have this statement:

IF X > Y AND PIN3 = 0 THEN
BLAH
ENDIF

Pin3 (Input 3 pin, physical pin 4) is a button input that is normally low. The issue is that "blah" never happens even if x is greater than y and the button is not pressed. The other odd thing is that if I change the statement to:

IF X > Y AND PIN3 = 1 THEN

Then "blah" happens without pressing the button. It is like the PIN3 statement works backwards. And yes, I have confirmed the wiring of the switch.
Another piece of the puzzle is that I have another statement:

IF PIN3 = 1 THEN
DO THIS
ENDIF

This statement works. When the button is pressed, "DO THIS" happens.

It seems that if the PIN statement is used with another condition, it works backwards.
I do not have a DIRS statement. Not sure if I need one.

I looked in the manuals but did not see anything that would explain this issue. Of course it is possible that I do not quite understand the PIN / DIR statements.
If anyone can shed some light on this matter it would be appreciated.

Thanks,
Dave E

 

[hippy]

There does appear to be an issue with that particular IF-AND-THEN statement though I am seeing slightly different behaviour than you do; you did not say what X and Y values were so that could account for the difference.

I do not know what the actual issue is but we will investigate it.

In the meantime, "IF X > Y AND pin3 = 0 THEN ... END IF" can be replaced with the following which should work -

IF X > Y THEN
  IF pin3 = 0 THEN
    BLAH
  END IF
END IF

 

[Dave E]

Thanks for the quick reply, hippy.

X is actually a READADC10 result and Y is a constant (2782) that X is being compared to so that if the battery voltage is above a charge-to voltage and the button on PIN3 is not pressed, then set BIT0 that toggles an LED indicator.

I think I have a version "D" chip somewhere. I'll give that a try in the morning to see if that makes a difference.

Dave E

 

[BCJKiwi]

Max value of ReadADC10 is 1023 so X will never be > 2782!

 

[Dave E]

Good catch, BCJ
A goof in my writing. I actually take multiple ADC readings and average them. X and Y are both WORD sized. 2782 * 5 / 1023 = 13.6 i.e. battery voltage.


I tried a test with a firmware version 9.D and a similar issue is present.
If I run:

W1 = 5000
W2 = 2000
DO
IF W1 > W2 AND PIN0=1 THEN
HIGH 5
ELSE
HIGH 3
ENDIF
LOW 3
LOW 5
LOOP

Output 5 will not go high when input pin0 is high.

If this program runs:

W1 = 5000
W2 = 2000
DO
IF W1 > W2 THEN
IF PIN0 = 1 THEN
HIGH 5
ELSE
HIGH 3
ENDIF
ENDIF
LOW 3
LOW 5
LOOP

Everything works OK.

I also noticed that if the (W1 > W2) statement is substituted with (PIN1 = 1) in either of the above examples then both examples work properly. So it looks like the issue is with the comparison.

Dave E

 

[hippy]

I'm not sure exactly what the issue is; "IF X>Y AND pin3=1 THEN" fails but "IF pin3=1 AND X>Y THEN" seemed to work but I have not done extensive testing ( being a weekend and all that ). Other tests one might have expected to also fail did not so it's hard to say what the interaction problem is at this time but we will investigate further.

It highlights the perennial problem that, no matter how much verification, how comprehensive testing and beta testing is, there are so many combinations, possibilities and time required that it is impossible to test everything exhaustively. To test "IF var op var THEN" exhaustively would take over 50 billion separate test cases to cover all possibilities. If they took one millisecond each that would take two years to test, just for one statement !

Sensibility dictates that exhaustive testing isn't realistic so subset plus random testing is done which is designed to catch issues with a smaller test set in a reasonable time. Unfortunately it means that some of the more unusual interactions can sometimes escape through the net and this seems to be one of them.

 

[Dave E]

WOW, 50,000,000,000 combinations. You're right, it is not something someone really thinks about especially when order of arrangement comes into play. At least now you don't have to worry about what to do Monday when you get back to the office.

Thanks again for working on the weekend. I would have wasted hours on this.
I confirm that changing the order does work on both "B" and "D" firmware.

Dave E