Flowcode Support Board

Hi, I need to compare a byte value with its bitwise invert, and I though the '~' would make that possible.
Like I have value1 = 0b10011001 and value2 = 01100110.
The statement value1 = ~value2 should be true, no?
But I get a false result.

Anybode can educate me?

Jan Didden
Linear Audio

Just to check that the second value has a 0b at the front?

Guessing this is for the IR check that second and 4th byte are invert of 1st and 3rd?

What size variable are you using - needs to be a byte (in simulation 32bit variables might be used)

Martin

Yes it is, actually it is the 1st and 2nd byte (address and inverse) and the 3rd and 4th byte (command and inverse).
I'm using an array of 4 bytes, rcvd[0] through rcvd[3]

Jan Didden

I'm not sure why the comparison doesn't work - it's some 'gotcha' with sign extension (for example - print ~rcvd[1] and it = -103)

There is an easy 'fix' (a bit of a kludge) - which is to do - which tests if the two numbers together have all 8 bits set.... (^ is exclusive or (either or))
Martin

Yes, I thought about that but was intrigued why the '~' wouldn't work.
BTW For the msg start it's enough to detect a 13500us start pulse as we were only looking at falling edges.
That simplifies it further, there are now just three states; IDLE, DATA and END.
I still need to fudge in detection of a repeat, will probably just count the repeats for possible later use, although not envisioned right now in my app.

Jan

XOR (or '^' ) doesn't work correctly either.
The attached fragment returns true.

Jan

It seems to need the brackets (see my sample)

(Sorry - I didn't include this in the description - but I did in the sample)

Must be an operator precedence issue with a non 0 result (possibly (rcvd[1] & 0xff) ^ rcvd[0])

Needs:
Works correctly with them in place....

Yes, both '^' and XOR now works correctly. Thanks!

Jan

Phew - glad it's working..

I'm really not quite sure why the initial compare didn't work either - maybe Ben or Martin can shed some light?

'Repeat codes should be easy to check for too - its a 9ms pulse, 2.25ms gap 562us pulse - so checking for 11.25 (+/- a bit) should be okay?

Martin

The simulator like the C code for the embedded device will always assume calculations are 16-bit unless upgraded to be 32-bit.

I think that as your values are 8-bit the upper 8-bits for the 16-bit calc are being treated as the same.

value1 == ~value2
0b10011001 == ~0b01100110

becomes

0b10011001 == 0b1111111110011001

Which are obviously not the same.

What you might have to do to make it work is mask the calculation so that only the lower 8-bits are inverted.

Your decision would then look like this.

value1 == (~value2) & 0xFF
0b10011001 == 0b10011001

or you could do this to force the 16-bit value to be saved back into an 8-bit memory location.

value2 = ~value2

value1 == value2

Hope this helps

Please note the double "==" is only shown that it is a comparison and not an assignment operator "=".
The Decision icon in Flowcode works with both single and double equals for comparisons.