TMS320F28069M: The TMS TMU optimized sin : through hw, compiler

Nothing additional should be required here. If it works with the C library's implementation of sin(), it should work with the TMU's implementation. When the TMU is enabled under processor options, and relaxed floating point mode is set, the compiler will replace calls to sin() with __sin(), the intrinsic that maps to the TMU sin instruction.

See excerpt from the compiler's math.h below.

/*---------------------------------------------------------------------------*/
/* TMU SUPPORT AND RELAXED MODE: USE INSTRINSICS. */
/*---------------------------------------------------------------------------*/
#if defined(__TMS320C28XX_TMU__) && !__TI_PROPRIETARY_STRICT_FP_MACRO

.

.

#define sin __relaxed_sin
__inline double __relaxed_sin(double x)
{
return __sin(x);
}

Hey Sira,

No that is not the issue, issue is the results / outputs of the functions differ, drastically it seems. Both are documented as taking rads in, yet the TMU version really doesn't like what I give  ? 

Here is example, just first iteration giving angle of 0, and  invoking sin() and __sin(), while  keeping floating point as "strict": see, they start go wildly different straight from first call/iteration, i'm lost :

That is strange - so if you are directly using the intrinsic, then the floating point mode (strict/relaxed) does not matter, so yes, you should get the same results. So something else is in play here. Let me look into this a bit more - I'll check if there have been similar issues other users have faced. It's something you can do as well.

Thanks,

Sira

Sira Rao80  anything you 've found?

I tried re-inserting my code into a floating point project example provided by TI, (fp hw one), and I still get the same behaviour. So I'm out of ideas: I thought its specific compiler  / library mismatch, but that now prob not the case.

Sira Rao80 said:

so if you are directly using the intrinsic, then the floating point mode (strict/relaxed)

That's probably partially is the case:  the __sin  , the compiler intrinsic, as I understand, is not available unless i enable TMU0 support for the project build settings - the linker fails to find the symbol and linking fails. 

So if that intrinsic generated code relies on hw initialization, may be I'm missing hardware initializiation ..

@Chester Gllion, 

I may have then assumed wrong, the TMU0 was the option enabled by / compiler flag which i have in project, and which the compiler does not complain about given the target.

So,  am I wrong then assuming it does, and compiler also then not picking up the target correctly. 

..and you right,  i have wrong lauchpad then... 

why would ti not put one with TMU on it., bah.

e2e.ti.com/.../ccs-tms320f28069m-tmu-results-on-c28x-is-not-correct