_CTRL_Obj_ fields using fpu

I see now that even the labs that are using the fpu32 are not using the files in the /float directories.  I guess they are just a decoy.

I think I got it mostly figured out.  I realize now that I made this way more complicated than I think I needed to but at this point I might as well see it through.  

When I #defined MATH_TYPE FLOAT_MATH in IQmathLib.h I had to change a few logical shifts to multiplication.  There's one last bit of code that has to be changed for it to compile.  I'm not very familiar with IQ math (the main reason I originally wanted to switch everything to float) but I think I figured it out.  Maybe you could confirm it for me.

In the ctrl.h file in the function CTRL_angleDelayComp(), starting at line 1859 I think I can replace:

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

// mask the angle for wrap around
// note: must account for the sign of the angle
angleComp_pu = _IQabs(angleTmp_pu) & angleMask;

// account for sign
if(angleTmp_pu < 0)
{
angleComp_pu = -angleComp_pu;
}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

with

angleComp_pu = fmodf( angleTmp_pu, 1.0);

Does that make sense?

I confirmed that in MW _13 all of the \float directories should not have been released. They are part of the fully floating point version of the library we are developing internally for future devices.  Please ignore, we will remove for _14.

I can't comment on your float code, let me send to someone else.

Sean Hanley said:

angleComp_pu = fmodf( angleTmp_pu, 1.0);

Yes, that looks ok. I would personally do it without a function call. So:

if(angleTmp_pu >= 1.0)
  {
    angleTmp_pu = angleTmp_pu - 1.0;
  }
else if(angleTmp_pu <= -1.0)
  {
    angleTmp_pu = angleTmp_pu + 1.0;
  }

That would get you an angle from 0 to 1 in CW and -1 to 0 in CCW. If you want the angle 0 to 1 regardless of direction, then add this:

if(angleTmp_pu < 0.0)
  {
    angleTmp_pu = angleTmp_pu + 1.0;
  }

-Jorge

Hello,

I trying too to add fpu32 support in my project, using Motorware 13. see that there are 2 IQmathLib.h files, one in the 32b and one in the float folder. Assuming that the float folder has been included by mistake, I conclude that the use of FPU is enabled by setting MATH_TYPE = FLOAT_MATH before IQmathLib.h in the 32b folder is included. However, even in the Motorware labs where FPU is used I cannot find out how MATH_TYPE is defined to FLOAT_MATH, so that I can do the same in my application.

I Have tested the examples with FPU support, but I now need to add FPU support to an existing project of mine.

So far I have tried this by din the following:

1. Set floating point support to fpu32 in the compiler options
2. Replace all libraries used with the FPU32 versions
3. Use the updateGlobalVariables_motor() from fpu-enabled projects, which uses an integer as the return value for all Estimator function calls

Unfortunately this is not enough to make my project work. I am suspecting that MATH_MODE may be the problem, but I haven't been able to find out if and how MATH_MODE is defined in fpu-enabled projects.

Thank you Chris, using the fpu32 libraries in the project link order seems to fix the problem.

However, this means that MATH_TYPE is still set to IQ math, i.e. all the IQ types are still defined in IQmathlib.h as integer and not float, and all MotorWare modules that use IQ types do not use the FPU.

Can you please explain if this is the case and if yes, wether there is any merrit it using fpu operation in the control modules? Also, with the FPU enabled how does the speed of float operations compares to that of IQ math?

Thank you in advance,

GIannis

Hi Glannis,

The IQmath library included in all motorware projects uses MATH_TYPE = IQ_MATH instead of float, even for the floating point examples. This is because all the library internally uses IQmath (fpu engine not enabled).

The floating point examples, for example lab3c, are intented to help execute much faster math calculations that require fpu engine, outside of the basic functionality of the lab. For example, if in lab3c, you have other math calculations using pure floating point math, you shouldn't have any issues, since fpu engine is already enabled for the floating point exampled.

The intention is not that the lab itself uses less CPU bandwidth doing the same basic functions of the lab.

Cheers!

-Jorge