PBASIC Question

undermutt

I'm new to robotics. It was something I wanted to do as a kid but wasn't able to until now. I stumbled across the BOE-BOT a couple of months ago and fell in love.

My little creation consists of a bsp24 master and bs2 slave. The slave controls a soundPal, a servoPal, wheel encoders, an accelerometer, and 4 QTI sensors. The master controls, at the moment, a temperature sensor and a serial LCD. The master also controls a Ping sensor, photo resistor, ir detector, and ir LED mounted on a turret.

I have both master and slave reliably doing what they need to be doing.
I also have master and slave passing commands and responses as they should, not so reliably.

While working on the communication problem I came across a programming thing that drove me nuts for a bit.

Why does this work...
IF listening = no THEN

but not this...
IF NOT listening THEN

listening is a bit
yes = 1, no = 0

Am I missing something, (won't be the first time)??????

I've attached the code and some screen shots of the output.

Thanks,

Rick.

Zoot

NOT is an operator, so it "inverts" the value you are checking then evaluates the if/then. So these are functionally equivalent, presuming "listening" = 0:

IF NOT listening THEN
' do something
ENDIF

IF listening = 1 THEN
' do something
ENDIF

listening = ~listening
IF listening THEN
' do something
ENDIF

undermutt

Zoot,

Thanks for the reply.

I realize that what you say is true and that is what I expected to happen.
Unfortunately that is not what my code actually does. If you look at the code snippets I attached and the screen shots of the output you'll see that even with listening = 1, the if decision still falls through.

Is it a bug in the code or something about the way I am using it? I've looked at it for too long. I need some new eyes to take a look.

Zoot

Oh, I see what you're talking about. Actually, thinking about it now, since NOT is an operator, I'm presuming that Pbasic moves the evaluation into "16 bit work space" as it does for most evaluations, so the NOT of a bit does "not" equal 0, but rather %1111111111111110.

Whether you realize it or not, all evaluations in Pbasic take place in a "hidden" 16 bit work space, then the evaluation(s) are performed, then the results (if any, like in a math operation) are moved back into whatever variable space you've assigned.

A simple example:

x VAR Byte
y VAR Byte
z VAR Byte

z = x + y

You would "think" that it adds bytes and then you've got your Z byte. But it doesn't. The Stamp first converts each value to the right of the = into "Words", then does the math, then converts back to a byte for the Z val. Most of the time this is invisible and is fine (it's also how you can do things like z = x + y MAX 255 without worrying about "rollover" in the x + y byte addition).

So in the case of NOT and other LOGICAL operations (rather than the binary operators like ^ & | ~), if you have bit only values you could get unexpected results:

x VAR Bit
x = 1
NOT x

In the above, when X is "moved" into Word space, you get %0000000000000001, then you NOT it and the result is %1111111111111110. If the end of your evaluation is to reassign that internal Word to the bit, you'll get the 1 you expect, but if you check the result in an evaluation (say, IF THEN), then a simple 1 or 0 or true or false won't work because %1111111111111110 does not equal 0, but rather -1.

And lo, in the Stamp manual it discusses this very "trap" on page 224 of manual version 2.1:

flag VAR Bit

Setup:
flag = 1

Test:
IF flag THEN Is_True
DEBUG "False"
END

Is_True:
DEBUG "True"
END

Since flag is 1, IF...THEN would evaluate it as true and print the message
“True” on the screen. Suppose you changed the IF...THEN command to
read “IF NOT flag THEN Is_True.” That would also evaluate as true.
Whoa! Isn’t NOT 1 the same thing as 0? No, at least not in the 16-bit world
of the BASIC Stamp.

Internally, the BASIC Stamp sees a bit variable containing 1 as the 16-bit
number %0000000000000001. So it sees the NOT of that as
%1111111111111110. Since any non-zero number is regarded as true, NOT
1 is true. Strange but true.

The easiest way to avoid the kinds of problems this might cause is to
always use a conditional operator with IF...THEN. Change the example
above to read IF flag = 1 THEN is_True. The result of the comparison
will follow IF...THEN rules. Also, the logical operators will work as they
should; IF NOT Flag = 1 THEN is_True will correctly evaluate to false
when flag contains 1.

This also means that you should only use the "named" conditional logic
operators NOT, AND, OR, and XOR with IF...THEN. The conditional logic
operators format their results correctly for IF...THEN instructions. The
other logical operators, represented by symbols ~, &, |, and ^ do not; they
are binary logic operators.

Zoot

P.S., I would expect this to work the way you anticipate:

IF ( NOT listening & %1 ) THEN
' do something
ENDIF

undermutt

Now I get it. This is my first time into the micro controller world. I guess I need to learn it's environment a little better.

And who reads documentation anyway? )

Thanks.

Zoot

Not all micros are like this by any means. Remember that the Stamp is actually a microcontroller that runs a program that "is" Pbasic -- your program tells the program that never changes inside the Stamp what to do. This is what is meant by an "interpreted" language such as Pbasic.