• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 2042 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

F28075 calucurate

Hiroyasu Tazawa1
Guru 12350 points
Other Parts Discussed in Thread: CONTROLSUITE

Hi, Everyone

I need your help.
We use control card of F28075.

We try to execute this code.

==================
float32 a,x,y;

 x = 0.523598F;
 y = sin(x);
 a = y/x;
 a = y * x;
==================

We calculate on CCS

Run -> clock -> enbale

this cycle is 145 cycle.

but we include math.h.

==================
#include "math.h"
float32 a,x,y;

 x = 0.523598F;
 y = sin(x);
 a = y/x;
 a = y * x;
==================

this cycle is 308 cycle.
Do you know why ?

Best Regards
Hiroyasu

  • 0
    Guru 192875 points
    Hi Hiroyasu-san,

    You're observation are very correct. Math.h is the standard math.h file as dictated by the C- compiler, this is supported using the Runtime support library for a device. Hence, its effectiveness would be less if compared to the FPU of the device.
    Instead of Math.h you can try IQMath for better performance. You can refer the document here for the same:
    C:\ti\controlSUITE\libs\math\IQmath\v160\doc

    Regards,
    Gautam
  • 0 in reply to Gautam Iyer
    Guru 12350 points
    Hi, Gautam

    When we used F28069 and include math.h, 130 cycles.
    but When we used F28075 and include math.h, 308 cycles.

    Why cycles is increaced on F28075 ?

    Best Regards
    Hiroyasu
  • 0 in reply to Hiroyasu Tazawa1
    Guru 192875 points

    Hiroyasu said:
    When we used F28069 and include math.h, 130 cycles.
    but When we used F28075 and include math.h, 308 cycles.

    Why cycles is increaced on F28075 ?

    That's odd! I hope you're operating F28075 at max clock right. If not, your statement seems to contradict as F28069 has a max clock of 90MHz and F29075 120MHz.

    Regards,

    Gautam

  • 0
    TI__Mastermind 20850 points
    Hiroyasu-san,

    The F28075 has the TMU (trig math unit). You can use it to minimize execution time. You enable it in the project properties by setting --fpu_support=fpu32, --tmu_support=tmu0, --fp_mode=relaxed. You dont have to change your code, the compiler will automatically substitute TMU instructions for the sine and divide operations.

    Now to the original problem itself, can you post the disassembly of the snippet you have shown, with and without math.h? Also could you post the compiler settings
  • 0 in reply to Vishal_Coelho
    Guru 12350 points

    Hi, Vishal_Coelho

    I show you disassembly without math.h and compiler Setting.

    blinky_cpu01.zip

    I understand We use TMU without math.h.
    but I do not understand why F28069 is not delay with math.h.

    Do you know why?

    Best Regards
    Hiroyasu

  • 0 in reply to Hiroyasu Tazawa1
    TI__Mastermind 20850 points

    Looks like the sin and FS$$DIV functions are in FLASHB, which is probably wait-stated, and that is probably why you are seeing the delay. I recommend you copy these functions over to RAM at run time and run them. You can see this post on how to do that

    e2e.ti.com/.../1617791

  • 0 in reply to Vishal_Coelho
    Guru 12350 points

    Hi, Vishal_Cpelho

    I already try to be run on RAM.
    But it is not improve.
    Did you try on my code ?

    Best Regards
    Hiroyasu

  • 0 in reply to Hiroyasu Tazawa1
    TI__Mastermind 20850 points

    Hi, Sorry i didnt see your reply. I checked out your code - i dont see the changes you made. The project files link to the source code in controlsuite. you probably changed the blinky.c file but did not package it with this zip. In any case i put in your code and this is what i get for the case where math.h is not included (by the way, I see a warning that sin is declared implcitly)

    It takes 115 cycles (sin = 67, divide = 5, x = 0.523598, y = 0, a = 0 ), calls the sin and FS$$DIV functions from the standard run-time support library BUT y = sin(x) gives 0 which when you feed as an argument to divide will cause it to jump to the last branch(divide by zero branch) and exit, which is why it takes 5 cycles

    Now when i include math.h it takes 307 cycles (sin = 67, divide = 233,  x = 0.523598, y = 0.4999993, a = 0.9549298 then 0.2617987) , the additional cycles is from the FS$$DIV() but the answers are all correct

    In the first case (without math.h) sin was called it calculates 0.499993 and stores it in R0H, but then the compiler overwrites this value with what is in the accumulator (probably 0) and then passed it to the divide function, which is why it executes quickly (divide by zero exit)

    63      	 y = sin(x);
0080a7:   E2AF0044    MOV32        R0H, *-SP[4], UNCF
0080a9:   FF69        SPM          #0
0080aa:   7640B793    LCR          sin
0080ac:   3B01        SETC         SXM
0080ad:   85A9        MOV          ACC, @AL
0080ae:   BDA90F12    MOV32        R0H, @ACC //<---- R0H is being overwritten by ACC (0)
0080b0:   7700        NOP          
0080b1:   7700        NOP          
0080b2:   7700        NOP          
0080b3:   7700        NOP          
0080b4:   E6890000    I32TOF32     R0H, R0H
0080b6:   7700        NOP          
0080b7:   E2030046    MOV32        *-SP[6], R0H
64      	 a = y/x;
0080b9:   E2AF0144    MOV32        R1H, *-SP[4], UNCF
0080bb:   76408000    LCR          FS$$DIV
0080bd:   E2030042    MOV32        *-SP[2], R0H

    Now in the case where you include math.h, you see the difference immediately, R0H is preserved before calling divide

    63      	 y = sin(x);
0080a7:   E2AF0044    MOV32        R0H, *-SP[4], UNCF
0080a9:   FF69        SPM          #0
0080aa:   7640B793    LCR          sin
0080ac:   E2030046    MOV32        *-SP[6], R0H
64      	 a = y/x;
0080ae:   E2AF0144    MOV32        R1H, *-SP[4], UNCF
0080b0:   76408000    LCR          FS$$DIV
0080b2:   E2030042    MOV32        *-SP[2], R0H

    The compiler does give a warning that sin() is implicitly declared in the first case, so it does not know that the output of sine (in R0H) is going to be consumed by a later functions and just overwrites it.