Odd behaviour on "~"

[Trikkitt]

I'm decoding an incoming message, the protocol is old and out of my control.  There is one important number contained in the message stored in a byte array, first it is sent true and then sent as 1s complement.  In my code I used the line:

Code Select Expand

If RX1Buffer[1]= ~ RX1Buffer[2] Then
However this always failed validation. So I re-wrote it to XOR the two numbers together which should result in all bits set:

Code Select Expand

RXdecode=RX1Buffer[1] ^ RX1Buffer[2]
If RXdecode=255 Then
The use of XOR works perfectly.  Any idea what I'm doing wrong with the ~ operator?  Does it just not work within an IF statement?

I'm using the latest compiler version posted on here.

[RGV250]

Hi,
Have you tried to use a temporary variable for the inverted value before the compare. I have found a few times that things do not always work with inline commands like that.
Something like
Temp = ~RX1Buffer[2]
if RX1buffer[1] = Temp then

Bob

[Trikkitt]

Have you tried to use a temporary variable for the inverted value before the compare. I have found a few times that things do not always work with inline commands like that.

Thanks! I haven't but I have a feeling it must be the inline part of the IF statement that is the issue.  I've used ~ elsewhere in the code but always straight to variables and those are working just fine.  It'd be nice if the compiler told you it couldn't do something, because it took quite a while to track this issue down.

[Pepe]

you must write

Code Select Expand

If RX1Buffer[1]= ~RX1Buffer[2] Then

not

Code Select Expand

If RX1Buffer[1]= ~ RX1Buffer[2] Then


[RGV250]

Hi,

If RX1Buffer[1]= ~RX1Buffer[2] Then

Interesting that the space causes different code where all the other logical operators can have a space. Perhaps if this is the case then the compiler should issue a warning / error that there is a space after the ~

Bob

[streborc]

I encountered a similar anomaly in some code I was writing in which I was storing bit values in an array.  A couple of the stored bits required inversion.  A stored value %00000001 needed to be inverted to %00000000, and %00000000 needed to be inverted to %00000001.  The tilda (~) function caused %00000001 to become %11111110 and %00000000 to become %11111111.  This messed things up because I wasn't masking the upper 7 bits.  The XOR function does this implicitly making %00000001 become %00000000 and %00000000 become %00000001.  Not sure if this related to the OP, but it's something worth remembering when juggling bits.

[RGV250]

Hi Streborc,

The tilda (~) function caused %00000001 to become %11111110 and %00000000 to become %11111111

From what you say I assume that you used the ~ on the whole word and not just bit.0 so it is working as it should.

Regards,
Bob

[Frizie]

From the manual: Bitwise Complement '~' reverses the bits in a variable.
So it does exactly what it's supposed to do

~%11110001 should become %00001110, etc.

[trastikata]

I think he is confusing bit masking/selection with the binary representation of a number ...

@streborc

%00000001 is just the binary form of the number 1, it means the same as 1 or (0x01 in hex format), "%" is not used as a bit mask or bit selection.