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.
Float type in LUT not working
Moderator: Benj
- 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
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.
Let us know how you get on.
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.
Let us know how you get on.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Re: Float type in LUT not working
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.
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.
- 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
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.
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.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Re: Float type in LUT not working
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.
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.