Compiler interpretation of "Types"

I'm having trouble with my firmware when I pass a value to a function that receives a float (The controller won't initialize correctly).
The function is as follow:

u16 u16SUPPLY_REF; //Global

void Switcher_Mode(float Voltage) {

float fSUPPLY_REF;
s16 s16SUPPLY_REF;

fSUPPLY_REF = Voltage * 38.7;
s16SUPPLY_REF = (s16)fSUPPLY_REF;
u16SUPPLY_REF = (u16)s16SUPPLY_REF;
}

And I will pass a value to the function like this:

Switcher_Mode(9);

But when I pass the value like this:

Switcher_Mode(9.0f);

The controller will initialize correctly.
I'm not sure if the above will make a difference to my porblem because I've tried a few other things that worked for a while.

I know the 'f' is not added to the end of the value, the compiler won't know as what type it should interpret the value.

I'm not sure what causes the controller not to initialize but I'm SURE it has something to do with the passing of the value to the function. Also when I change the receiving type of the function to byte, then the controller will initialize. But I must use a float.

Some ideas and help please.

 RE: Compiler interpretation of "Types"

If the function is defined or a prototype for it is declared before it is used, the compiler will convert the integer 9 to its floating point equivalent.

The 'f' suffix for the floating point constant 9.0f is unnecessary. The decimal point is enough to tell the compiler that it is a float.

9.0 is a floating point constant
9. is a floating point constant
9 is an integer constant

 More information needed.

I'm having trouble with my firmware when I pass a value to a function that receives a float (The controller won't initialize correctly).

Did you check what value Voltage has inside the function if you call Switcher_Mode(9); (with an integer argument instead of float) ?

Is the initialization time-critical, i.e. could run-time conversion from integer to float disturb it ?

But I must use a float.

Is there hard reason for this ? Will a fixed-point variable be insufficient ?

floats are rarely necessary in control application and come with their very own set of problems (value-dependent granularity, for example). There's usually some way to avoid using floats - fixed point numbers being the most likely candidate.

 Avoiding Floating Point

"Will a fixed-point variable be insufficient ?"

Or could you just work in mV (millivolts) instead of volts?

Or cV (centivolts)

Or dV (decivolts)

http://www.8052.com/forum/read.phtml?id=108347

http://www.keil.com/forum/docs/thread8815.asp
http://www.keil.com/forum/docs/thread8278.asp

 RE: Avoiding Floating Point

Thnx Andy,

Should use my mind like yours.
I will try the mV, then I can use an integer.
Still need to do the multiplication inside the function but at least a don't have to pass a float.

Still can't see why I should have so much trouble to pass a float. Anyways let me try the mV.

 Assembly ?

Still can't see why I should have so much trouble to pass a float.

Can you post the assembly code generated by the two different function calls ?

I assembled both

Switcher_Mode(9);

and

Switcher_Mode(9.0);

and got exactly the same assembly each time (so the conversion is done at compile time).

 RE: Assembly ?

Hi Christoph

In the example I use a fixed value '9' but in my real situation I pass different values at runtime. But it is good to know that the Assembly is the same for both. What if you used 9.0f?

Thnx for the help.

 RE: Assembly ?

In the example I use a fixed value '9' but in my real situation I pass different values at runtime.

As constants or as variables ?

If they are passed as variables, the MCU will spend quite a bit of time turning them into floats before actually entering the function.

How critical is the timing of the function ?

 RE: Assembly ?

How critical is the timing of the function ?
and, how much time do you have avalilable totally. Often the tree (the function) is in the way of seeing the forest (the program).

Many have failed because some function "ate" time sometime infrequently required for something else and that, ladies and gentlemen, is a debug you do not want to go through. There is no worse bug to trace than "once a week it burps"

Erik