Float type in LUT not working

A forums to allow bugs and problems with Flowcode v7 to be reported and resolved.

Moderator: Benj

Post Reply
SteveF
Posts: 3
Joined: Thu Dec 21, 2017 2:42 pm
Contact:

Float type in LUT not working

Post by SteveF »

Hi,

Board : EB064, DsPic30F4013.

FC : 7.2.1.4

I've created a small LUT of type Float (Options on the component pulldown being 8, 16, 32bit or Float).

I then try to compile to Hex.

The compiler returns an error as follows..

expected '=',',',';','asm' or '__attribute__'before 'FCD_00fb1_lut1_FLOATLIST_LUT

The offending line of code is the ROMARRAY_(MX_FSINGLE) FCD_00fb1_lut1__FLOATLIST_LUT ROMARRAY E =

I believe the issue might be the use of MX_FSINGLE? Looking through the support files, I can only see a definition of MX_FLOAT which is double but I can't see MX_FSINGLE anywhere.

How can I create an LUT containing Float values?

Regards,

Steve.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Float type in LUT not working

Post by Benj »

Hi Steve,

Many thanks for letting us know. The attached file should solve the problem. Simply copy to your "Flowcode 7\CAL\PIC16BIT" folder and the compilation error should then be solved.
PIC16BIT_CAL_TypeDefs.c
(2.33 KiB) Downloaded 147 times
Let us know how you get on.

SteveF
Posts: 3
Joined: Thu Dec 21, 2017 2:42 pm
Contact:

Re: Float type in LUT not working

Post by SteveF »

Yes, that appeared to fix things, thanks.

A couple of other observations.

1. There seems to be a mixed use of float and double in the header files. From the 'add variables' perspective of FC7, only float is selectable. This declares 'double' precision floats (from what I can see anyway). In the case of the LUT, this is declared as a single precision float...but they're both called 'float' leading you to think they're declared as the same type.

But, through the use of the XC16 compiler switch, -fno-short-double, double becomes a different beast altogether. It would be better to enable the user to choose the use of float or double as required.

2. I tried to include _fractional data types through the supplementary code section, also allowing the appropriate switch in the compiler command line. The compiler complained saying that the data type was not allowed for this device.

I know that they (30f4013) are so I think the problem may be that the switch ( -menable-fixed) I placed in the compiler options window may not have been picked up. Should the option be entered (edited) in the compiler batch file itself?

Thanks.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Float type in LUT not working

Post by Benj »

Hello,

1) As far as I know we only use the single precision floats in all instances as not all compilers support the double data type. The AVR compiler for instance defines the double data type but it defines it as a float and so it's very misleading. Which specific headers have you seen with reference to double? We could support double variable types based on target device but this leads to problems porting code between micros.

2) I think that the compiler switch should be added to the batch file and not the compiler options. You can create a second batch file with edits and then point to this using the compiler options to allow you to easily switch between modes.

SteveF
Posts: 3
Joined: Thu Dec 21, 2017 2:42 pm
Contact:

Re: Float type in LUT not working

Post by SteveF »

The define is in PIC16BIT_CAL_TypeDefs.c

the line..

typedef double MX_FLOAT; // In BoostC, needs '#define MX_FLOAT float'

This will be single precision unless you use the compiler switch, in which case it takes the double precision form according to the XC16 compiler.

If you select 'float' as a variable type in FC7, then it produces the following..

MX_GLOBAL MX_FLOAT FCV_TESTVARIABLE;

Which, given the typedef in the header, will be double not float. As you can see from your comments, I think it used to be float for the BoostC compiler.

I'd say it's not a game changer but if the interface could allow explicit selection of either float or double that would prevent any mix ups.

Post Reply