We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
My problem is that I have integer constants coded as compile-time constant floating equations to avoid having to use the floating point library... let me explain...
Take some code that does not use floating point operations - say:
void main(void) { unsigned int i = 1000; for (; i; i--) ; }
Under Projects / Options / C/C++ / Misc Controls: add the directive:
--fpu=none
since we don't need FPU support.
Like this, the program will compile.
Now, ask the compiler to do some compile-time floating-point calculation that results in an integer - insert at head of file:
unsigned int j = (unsigned int)(1.0*3.0);
The RealView compiler refuses to compile the line, even though we don't need FP support at run-time.
Is there a way round this?
With --fpu=none you basically disable all floating point support. Even when your code compiles into a simple constant, the compiler traps floating point operations in such cases.
So to avoid this type of errors just write:
unsigned int j = 1*3;
Hello Reinhard,
This is a pity - this decreases the readability of the source code. An explanation...
The floating point (constant) calculations are needed in the following lines which translate a voltage to a byte value driving a D-to-A:
/* // Vpp is driven from a +15V feed, divided by an 8-bit value. // This gives a multiplier of +15V/255 of the programmed value. // The byte value sent to the encoder is the rounded up version of // the voltage divided by the DAC const (15/255=0.0588235). */ #define DAC_const (15.0/255) #define VPP_5V (BYTE)((5.0/DAC_const)+0.5) #define VPP_12V (BYTE)((12.0/DAC_const)+0.5) #define VPP_OFF (BYTE)((0.0/DAC_const)+0.5
Because of this limitation, the code has to be written:
#define VPP_5V (BYTE)(85U) #define VPP_12V (BYTE)(204U) #define VPP_OFF (BYTE)(0U)
which is not as good.
It's a pity - thanks for the explanation, though.
Jason.
That conclusion is premature.
The standard practice for this kind of job is to slightly reorder the equation:
#define DAC_numerator 15 #define DAC_denominator 255 #define VPP_5V (BYTE)((5 * DAC_denominator) / /DAC_numerator)
I'll leave the addition of the 0.5 term as an exercise.
I like Hans-Bernhard's suggestion, but also you could just remove the "--fpu=none" statement.
All the statement does is cause an error when you try and use a floating-point type. It does not actually make your code any smaller. (At least it does not for mine). It is fully a "compile time" option and not a "run time" or "Code Generation" option.
Shame - you fell short of having to encode 0.5 as a fraction with a denominator of 15... I know, and I know you know, how to fix this, but the resulting code would still require a word or two of explanation (denominator of "15*2"?) - hence the word "shame" [as in pity]...
No much shame, since the "workaround" is trivial - as long as the compiler have the numeric range.
... just remove the "--fpu=none" statement.
Interesting... without this, I get inclusion of the libraries and the FP library is initialised.
Thanks for the suggestions, guys - I will try both.
Sorry if your target includes floating point libraries behind the scenes. If I do not use floating point calulations at run time, no support is added in my builds (and therefore also not initialized). (My target is STR71X). It would be interesting to know why it is including floating point libraries AND initializing them if you are not using them. Maybe your map file would give a hint as to why they were being included. Maybe not.
but the resulting code would still require a word or two of explanation
Well, if the answer was completely obvious, it wouldn't have been much of an exercise to be left to the reader, now would it? ;-)
#define DAC_const (15.0/255) #define VPP_5V (BYTE)((5.0/DAC_const)+0.5) #define VPP_12V (BYTE)((12.0/DAC_const)+0.5) #define VPP_OFF (BYTE)((0.0/DAC_const)+0.5
If you changed the definitions to the following they would be the same as the floating point versions
#define VPP_5V (BYTE)(86U) //(BYTE)((5.0/DAC_const)+0.5) evaluates to 86 not 85 #define VPP_12V (BYTE) (205U) #define VPP_OFF (BYTE) (1U) #define ONE_OVER_DAC_CONSTANT (17U) // Because 1 / DAC_const is an exact integer (17) , you could do 5 * 17 and just add 1 because you are rounding up.
Sorry I believe I got my "rounding" (or truncating) wrong. But these numbers do come out to be EXACT integers. There should be no need to use floating point.