bitwise invert/complement?

[jan.didden]

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

[mnfisher]

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

[jan.didden]

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

[mnfisher]

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

Code: Select all

if rcvd[0] ^ rcvd[1] = 0xFF

- which tests if the two numbers together have all 8 bits set.... (^ is exclusive or (either or))

invert test 2.fcfx

(15.64 KiB) Downloaded 64 times

Martin

[jan.didden]

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

[jan.didden]

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

Jan

[mnfisher]

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:

Code: Select all

(rcvd[0] ^ rcvd[1]) = 0xFF

Works correctly with them in place....

[jan.didden]

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

Jan

[mnfisher]

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

[BenR]

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.