Problem with Bool on target

[ylanchec]

Hi !

If i do a simple program, reading a bit (Bool) and inverting it and printing, it works in simulation.

If i upload it in the target, the NOT does not works.

I also do the test with a byte and it's good.

Strange too, il i say TEST=0 and then TEST=NOT TEST, it works on target.

An idea ?

Yannick

[Steve]

I see the problem, but it might not be easy to fix and I will need to discuss with others here. I hope to have a fix in the New Year.

[ylanchec]

Hi Steve,

I have also this problem on old versions of FC, but now i am on FC7 !

Thank you for your help.

Best regards.

Yannick

[Steve]

Hi Yannick,

We're discussed this issue here and this is the situation...

Flowcode's operators "NOT", "AND" and "OR" are treated as *bitwise* operators in the code. If you know a bit of C code, these are the ~, &, and | equivalents.

If you want to have the equivalent *logical* operators, then you need to use the appropriate symbol !, && and || (these are the logical operators in C).

There's a further complication in that Flowcode's "bool" type is actually defined as a "byte" value in the generated C code. This is due to an issue with the compiler we are using. However, Flowcode's internal simulation treats a "bool" as a single bit. This is where the discrepancy is.

So in the code that runs on the microcontroller, if the bool variable TEST = 1 then NOT TEST = 254 (because it is actually treated as a byte value and in binary, NOT 00000001 is 11111110).

My suggestion is for you to use the symbol "!" in your code instead of "NOT" and it should work as expected in both simulation and on the microcontroller.

I hope this helps,
Steve.

[ylanchec]

Hi Steve,

Thank you for your response. So for the moment we can't use NOT AND OR with a Bool.

Of course, i have change my code and use a byte and it works.

It will be good to correct this bug in the compiler in next versions... Who makes the compiler ?

Usually in tests (IF), i use boolean conditions with OR, AND.... and it works... so it does not seems to be same for boolean conditions that simple vars.

Thank you for your help.

Yannick

[Steve]

Hi Yannick,

The compiler is from Microchip, but it is not a bug as such. There is a limitation in the way a bool variable can be used and Flowcode needs to work around this. The simplest way was to define a bool as a byte.

We will look at what we can do to solve this issue better, but it is not simple and any fundamental change may have unexpected consequences on users' existing code.

For now, the safest thing is to use the logical operators (!, &&, ||) when you are trying to determine a logical outcome (i.e. if a condition or result is true or false).

Regards,
Steve.

[ylanchec]

Hi Steve,

Actually "NOT" -gives "~" in C
Actually "AND" -gives "&" in C
Actually "OR" -gives "|" in C

When the var is Bool, the C could be modified maybe ?

NOT --> !
AND --> &&
OR --> ||

Maybe difficult for old sources....

Yannick

[Steve]

Hi Yannick,

Yes - that is the way NOT/AND/OR work currently in Flowcode. These are the "bitwise" operators.

It does become complicated because you can have a mixture of Bool and Byte variables in a calculation or decision, so it is not so easy just to change it for a Bool type. And yes, it could "break" existing code and so we are reluctant to make the change now. We will consider it again when moving to v8.

Regards,
Steve.

[medelec35]

Also bools are treated differently with FC6 and FC7.
If a bool = 1 then:
If FC6 when added 1 to a bool then bool is still = 1 (in an ideal world I would have thought = 0 due to rool-over).
In FC7 when added 1 to a bool then bool result will increment.
2,3,4,5,6,......255,0 etc.

So it it broken in FC7 anyway?

Martin

[Benj]

I've had another play with the CAL code to try and find a nice solution that works across the board.

However I'm currently coming up short.

We can declare the MX_BOOL type as a bit, this works really well as a variable but causes compile errors if you're using booleans as function parameters or returns.

As the parameters and returns have to work with the boolean type we have resorted to using a char as the MX_BOOL type.

This has the downside of being a 8-bit value and allowing values other than 0 and 1 where anything that is not 0 is true.

For now the only way I can get both code bases working as 1 is to do something like this.

Instead of writing this.

Code: Select all

test = test + 1
output test -> A0

or

Code: Select all

test = NOT test
output test -> A0

I would instead write the following to force the single bit value in the byte.

Code: Select all

test = (test + 1) & 1
output test -> A0

or

Code: Select all

test = (NOT test) & 1
output test -> A0

v6 to v7 was a major compiler change and though BoostC did a lot of things in a none standard way the way they treat booleans seems actually better than the way XC8 does. I'm guessing that XC8 needs the bit type to be global or static is so that the Pro version can try and optimise bits together into bytes. Though I have never seen a compiler do this successfully without having to manually force the compilers hand and create a structure.

So ... I'm not sure that we can do much about it for now without a none trivial maths overhaul in the Flowcode engine.

[ylanchec]

Benj,

Than you for your reply.

Best regard

Yannick