This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Trying to understand FPU and 'float' terminology

Other Parts Discussed in Thread: MOTORWARE, TMS320F28069M

I must be confused about some terminology and would appreciate some clarification.

I am using LAB09A as a basis for a field weakening project using custom hardware.

LAB09A is described as: "Lab09 with fpu32".

Question1;

This project links hal.c at:

C:\ti\motorware\motorware_1_01_00_14\sw\modules\hal\boards\hvkit_rev1p1\f28x\f2806x\src\hal.c

as opposed to:

C:\ti\motorware\motorware_1_01_00_14\sw\modules\hal\boards\hvkit_rev1p1\f28x\f2806x\src\float\hal.c

Is this correct - and fr so - what is the intended purpose of the ...\float\hal.c etc.

Question2:

PROJ_LAB09A.C appears to have special code in it to work around a compiler issue with the FPU. e.g.;

// when calling EST_ functions that return a float, and fpu32 is enabled, an integer is needed as a return
// so that the compiler reads the returned value from the accumulator instead of fpu32 registers
// get the magnetizing current
tmp = EST_getIdRated(obj->estHandle);
gMotorVars.MagnCurr_A = *((float_t *)&tmp);

Is this a compiler bug - and if so does it still exist and if so - will it be fixed at some point? Or am I misinterpreting the above comments.

Thanks.

Richard.

  • The existing ROM library is written in IQmath fixed point as it is used on fixed point devices as well. There is no floating point code used at all. That's the first thing to understand.


    Q1: The float HAL files should not have been released in MotorWare. They are from our internal repository as we move the entire library / MotorWare over to pure floating point for next generation devices. There are several examples of this inside the MotorWare sw\ directory. I filed this as a bug for correction some time ago...

    Q2: No, this is not a compiler bug. Since the F2806x has an FPU, if you enable the FPU, it treats the floating point variables differently than our IQMath ROM library is expecting them, hence we have to "trick" the compiler into keeping them in the correct format. This will not be "fixed" on existing devices. As noted above though future new devices will have pure float libraries so this won't be necessary.
  • Thanks Chris. That explains most of the mysteries...

    I should ignore all those "float" folders in motorware. They apply only to future hardware.

    It looks like the "special code" in LAB09A is more due to a "rom bug" or "rom incompatibility" where the rom code doesn't return floats in the correct place (FPU Registers) when FPU is enabled. Have I got that right?

    Richard.

  • "I should ignore all those "float" folders in motorware. They apply only to future hardware."
    correct

    "It looks like the "special code" in LAB09A is more due to a "rom bug" or "rom incompatibility" where the rom code doesn't return floats in the correct place (FPU Registers) when FPU is enabled. Have I got that right?"

    ROM incompatibility would be more correct, yes.
  • Hi again Chris...

    Not sure if you are still monitoring this thread - but a related issue has arisen.

    We are using the TMS320F28069M  part in a Motorware FOC motor controller based on LAB09A.

    We are adding some code to do some filtering. The question is whether we should use "IQMath" or the FPU?

    Can you give us guidance on whether the FPU is as fast or faster than the IQmath library?

    Presumably - if we use LAB09A as the basis of our code  - any floating point math will automatically use the hardware FPU. Right? From a processor bandwidth point of view - are we better of using the FPU - or using the IQmath types and functions?

    Thanks Chris.

    Richard.

  • it completely depends on the operations. you may want to ask the general IQmath vs. FPU question in the C2000 forum.

    Yes - using lab09a the FPU is active and the compiler will use when it can.