Help with IF statement??????

[armondo_522]

Hello,
I am using Ver 4.114 of the PCD compiler. I am trying to make a simple IF compare statement. Basically, I take an A/D sample and put it in an Float array. I then want to compare that element to a limit. If true set a bit, if false unset the bit. I know the inter value is 1.6. when I go into the if statement it always comes up with a false(else) answer. Could this be a compiler issue. The program originally worked with version 4.087.

Any suggestion would be appreciated.

Code is below.
Thanks :

[pmuldoon]

I would start by forcing 'inter' to the value you think you know it is.
My guess is it is not what you assume it to be.
Either way, it will give you a better idea of what is broken.

Something like:

[pmuldoon]

I have had a lot of issues with the PCD, so it could very well be a compiler bug.

My general suggestion is don't do anything fancy in your code. Keep it as simple and basic as possible.

I've looked at the assembly mneumonics for the 30F chips I was working with and don't blame CCS for having trouble with the compiler. It's hugely more complex than the old 18F world.

[armondo_522]

Thank you for the response.

It is correct, I can only get it to work when I hard code in
IF(1.6>1.3) this works every time. Its only when I pass variables to the IF statement it doesnt work. I am sure of what the variables are. I have them in a watch window. And The code does work with Version 4.087 with no problem. I suspect the compiler to be at fault. I am no to proficent is assembler at this time.

Thanks again,

[pmuldoon]

You might want to consider converting your limit to an int16 and doing everything with int16's instead of floats. You only have the resolution of the 10 or 12 bit (not sure of your chip) AD converter anyway.
I'm sure integers would compare properly. And the code will run faster as well.

[armondo_522]

Thanks,
I was thinking of trying that. It will mean changing quite a bit of code coming out of AD routine, Which I change to volts so other functions can massage the data in volts..

Regards,

[PCM programmer]

[armondo_522]

DSPIC30F6015.

Works great except for this bug..

[FvM]

I checked the arithmetic operation with the below code extracted from your example, and it works correctly in PCD V4.112 and V4.114. Please try to make a short complete example that reproduces the problem for further tests. Otherwise I assume, that the problem is either located in a part of the code not shown yet, e.g. loading the array, or it only occurs under specific conditions.

[armondo_522]

Thanks FVM,

The only thing not shown, is the loading of the array, which comes from an A/D capture routine. The float #'s are more like 1.336464784 etc. The other puzzling part is that it works perfectly with compiler version 4.087. Another interesting thing, is the listing for both routines is substantually different. Another interesting glitch I found is:

#define FALSE 0
#define TRUE 1

#define BYTE unsigned int8
#define BOOLEAN int1


byte x;
Byte samples =130;

For(x=0,x<=samples,x++)
//do something

the interesting part is that samples comes up as -126 and the loop never runs. by changing samples to long the routine works correctly. I thought a byte was unsigned and the max was 255.It appears that byte is a signed number even when defined as unsigned.

[FvM]

I didn't want to doubt, that you observed a bug related to V4.114. It won't be the first newly introduced one. But I couldn't reproduce it under the reported circumstances. To avoid guessing and possible misunderstandings, I think, it would be reasonable to provide a short complete example application, that allows to reproduce the bug.

I could not reproduce the other issue. By the BRA NC instruction, the compiler is performing an unsigned compare. But accessing a byte variable on an odd memory location by a shift operation seems to be a new kind of PCD confusion. (not using MOV.B 923 W4L)

[Douglas Kennedy]

There can be confusion about floats. The coder enters values in base ten notation specifically in this example 1.6. The floating point is also notational but the base is binary and it is further normalized ( an implied 0.bbbbb...bbb). Now when the floating pt notation is 64 bit binary ( as on most PC's) the differences in notation base 10 to base two are less noticeable except in compares ( if x==y )where a single bit difference in bit 63 matters.
Frankly it is often better just to use floating pt in multiplications and or divisions that result in a very broad range of results. For compares a cast after scaling to an integer produces a more certain result. Some coders throw in fudge factors that they call rounding but it's really just notational issues. The good news is that the notation of integers is compatible ( loss less) for all bases. The compiler can have bugs but remember 0.1 in decimal can't be notated in binary loss lessly just as 1/3 can't be notated as 0.33333....333 in base ten losslessly.
There is no mathematical error or compiler error here it is just we use notation to represent numbers and changes in notation like translations from different spoken languages introduce variances.

[armondo_522]

Thanks to everyone who responded. I changed all the float arrays to INT16 and the program is now working. I can't explain why the floats didn't work, but I will not use floats unless absolutely necessary in the future.

Regards to All.

[FvM]