Possible inconsistency in DECISION handling?

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 2 and 3.

Moderators: Benj, Mods

Post Reply
cleverchip
Posts: 7
Joined: Wed Sep 05, 2007 4:58 pm
Location: Leeds
Contact:

Possible inconsistency in DECISION handling?

Post by cleverchip »

Here's the scenario:

I have a byte variable, 'my_variable', which may have a particular bit set. If I have a DECISION block which contains the following statement:

IF... my_variable AND 1 = 0

the simulator does the predictable thing, and performs a bitwise AND. If the appropriate bit (least significant in this example) is clear, then the conditional branch is taken. But downloading this to the hardware fails (the condition is always false, regardless of the value of my_variable).

However... if I write

IF... (my_variable AND 1) = 0

it works in both simulator and hardware.

I know there are several ways to do 'bit tests', and I also know that using parenthesis makes the statement clearer to 'read'. But... why the inconsistency betwen simulated response and hardware?

I'm planning to use FlowCode to teach my students... and differences between simulator and hardware behaviour will destroy their confidence in the whole process, so I need to know what's going on!

Chet
Posts: 61
Joined: Thu Oct 13, 2005 5:05 am
Location: USA
Has thanked: 2 times
Contact:

Post by Chet »

Try "&&" instead of AND.

User avatar
Steve
Matrix Staff
Posts: 3426
Joined: Tue Jan 03, 2006 3:59 pm
Has thanked: 114 times
Been thanked: 422 times
Contact:

Post by Steve »

"&&" is a logical AND, and "&" is the bitwise AND - so your use of "&" in this example is correct.

The C code generated for your decision icon looks like this:

Code: Select all

//Decision
//Decision: x AND 1 = 0?
if( FCV_X & 1 == 0 )
It looks like the C compiler is performing the "==" operator before the "&" operator, which always results in 0 (ie.e a false result).

One book I have lists the order of precedence of these operators as equal, but another lists them with "==" before "&".

Either way, the compiler seems to be doing the correct thing and the simulation has a small bug. I'll look into the simulation side of things to see if I can tweak it.

But I would treat this as a great example of why you should use brackets to make your intentions clear.

ASIDE: because I work in an environment where source code is created and shared between developers, code readability and unambiguity is a really important issue - I'd put it almost as important as understanding it!

Post Reply