Rebuilding a Atmel studio 7 solution using -mfloat-abi=hard

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am trying to rebuild my solution using the "-mfloat-abi=hard" compile option in an effort to speed my FPU performance on my SAMD51.

 

However, I have linked files that were compiled with the default "-mfloat-abi=softfp" option.  Because of this, I can;t compile using the new =hard FPU option.

 

Is there an easy way to recompile all linked files with "-mfloat-abi=hard"?

 

-Troy

This topic has a solution.
Last Edited: Sun. Dec 1, 2019 - 09:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To be clear, I am getting, for example:

 

Severity    Code    Description    Project    File    Line    Source
Error        hpl/ramecc/hpl_ramecc.o uses VFP register arguments, metro1.elf does not    metro1    c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld.exe    0    Build
 

How can I rebuild all of my libraries like hpl_ramecc.o so they use Hard floating point?

 

-troy

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you tried doing a full rebuild?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, tried numerous clean and rebuild compiles.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the same problem. Did you manage to solve it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, let me try opening a Microchip support ticket to see if they can help us.

 

-troy

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear Troy,

 

any answer from the Microchip support yet how to set the compiler and linker flags to make sure the hardware FPU is used?

 

Best Regards

Markus

Last Edited: Sun. Nov 17, 2019 - 09:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am still working on getting it working, but here are the 2 emails I received from Atmel support.  I am still working on getting arm_math.h added.  Maybe we can both hack away at this?  The first support response had errors, notice the corrections on the second response:

 

FIRST RESPONSE:

--------------------------------------------------------------------------------------------
Comment by : Sathyanarayanan A 11/15/2019 15:33:59 GMT
--------------------------------------------------------------------------------------------

Hi Troy,

 

Thanks for contacting Microchip.

 

Changing from softfp option to hard FP option requires some modifications in toolchain settings. Follow the following steps to resolve the issue:

 

1) Add “-mfloat-abi=hard -mfpu=fpv5-sp-d16” (for single precision) or “-mfloat-abi=hard -mfpu=fpv5-d16” (for double precision) flag in “Project Properties -> Toolchain -> ARM/GNU C Compiler -> Miscellaneous -> Other flags”.

 

2) Add ‘ARM_MATH_CM7=true’ in "Project Properties -> Toolchain -> ARM/GNU C Compiler -> Symbols -> Defined symbols (-D)".

 

3) Remove "__SOFT-FP__" from "Project Properties -> Toolchain -> ARM/GNU C Compiler -> Symbols -> Defined symbols (-D)".

 

4) Include <arm_math.h> file in the main.

 

5) Enable FPU unit in main using "fpu_enable();".

 

6) Change the CMSIS library from "libarm_cortexM7lfsp_math_softfp" to "libarm_cortexM7lfsp_math" from "Project Properties -> Toolchain -> ARM/GNU Linker->Libraries->Libraries(-I).

 

Kindly let us know if this resolves the issue.

 

Warm regards,

Sathyanarayanan.

 

 

 

 

 

SECOND RESPONSE:

 

Hello Troy,

Microchip Technical Support has added a comment on case 00476987.


Case Link: https://microchipsupport.force.com/s/case/5003l00000y11SN


Latest Comment:

Hi Troy,

 

I Apologize for not noticing it's a M4 device.

 

-> In SAMDx/Ex(M4) devices only single precision FPU is available and the flag to be added in GNU compiler is "-mfloat-abi=hard -mfpu=fpv4-sp-d16" not "fpv5".

 

-> Add the same flag in "Project Properties -> Toolchain -> ARM/GNU C Linker -> Miscellaneous -> Other flags".

 

->Add "ARM_MATH_CM4" instead of "ARM_MATH_CM7" in symbols and also add "__FPU_PRESENT=1" in the symbols.

 

->The Atmel start didn't include arm_math.h file by default. So, kindly download standalone ASF4 framework and add arm_math.h header present inside \xdk-asf-3.47.0\thirdparty\CMSIS\Include by right clicking your project name and clicking "add existing item" .

 

-> libarm_cortexM4f_math.a library found in \xdk-asf-3.47.0\thirdparty\CMSIS\lib\GCC should be added by right clicking your project name and clicking "add library".

 

The standalone ASF4 can be downloaded from the following link:

https://www.microchip.com/mplab/avr-support/advanced-software-framework

 

-> Include <arm_math.h> header in your main.c file, Rebuild the project.

 

Hope this resolves your FPU issues.

 

Warm regards,

Sathyanarayanan.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The one thing I can't figure out is what #include I need for the "fpu_enable()"   

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the final response from Microchip support:

 

RESPONSE #3:

 

You don't need to add fpu_enable() in main function as you are adding it in symbols.

Also disable "Use size optimized library" in ARM/GNU Linker->Linker.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The good news is that by following these steps,  you can get compiled using -mfloat-abi=hard.

 

The bad news is that the performance increase isn't that dramatic.  I timed a floating-point heavy routine I have.  It takes 7.25uS to complete compiled -mfloat-abi=soft .  With -mfloat-abi=hard, the time to complete is reduced by 280ns.  Doing some eyeball math, that is what, about 3-4% improvement?

 

YMMV.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That seems unlikely to be the right amount of improvement. Every elementary operation (add/subtract) in floating point should save around 170ns with FPU on that chip -- as a floor. Mul, div, fcos(), etc will be more.

 

Are you using single-precision (c type: float) or double-precision floating point (c type: double)? Double precision operations will not benefit from the SAMD51's single-precision FPU. For double-precision FPU you need the SAMS70/SAMV71 family.

 

Reference: http://www.ganssle.com/tem/tem36...

Josh @ CIHOLAS Inc - We fill the gaps from chips to apps

Last Edited: Tue. Nov 19, 2019 - 02:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Josh, sorry I confused the issue just a bit.  My default setting was -mfloat-abi=softfp, not =soft.

 

From what I understand, the default setting of  -mfloat-abi=softfp still has FP operations use the SAMD's FPU unit.

 

It is just the softfp option adds a thin layer of emulation commands so the the code is more portable across different SAMD chips.  The =hard option makes the code specific to the chip, so some of the emulation overhead is eliminated.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried all these changes to the properties of my SAM E70 project (Cortex-M7 changes) but still floating point does not work.

I manually added the missing llibarm_cortexM7lfsp_math_softfp library and arm_math.h file  . Library properly included in the make, all paths updated, flags added... Compilation and linking went smooth... Except for Linker option --specs=nano_specs cannot be unchecked because code fails...

Nothing makes floating point work.

I guess no more suggestions to expect sad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How many threads are you going to spam with the same problem? Start a new thread and give some context - ie code example and what you did to create and build the code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How many threads you expect to be created on the same topic? And how many times you expect to see the same changes made which are repeated yet again from this topic and from others? Is that not another form of a spam?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You’ve yet to tell us the precise nature of your problem. You’ve jumped into old threads on hardfloat and print formatting problems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The precise nature of my problem was the same as the original post except my target as I mentioned earlier is SAME70. Floating point did not work with hardware FPU and I tried all the changes mentioned earlier in this thread except one (as I mentioned) .

Here is a solution I found after getting some input from tech support.

The changes recommended were similar to the provided in this thread:

1. Compiler and Linker flags:

-mfloat-abi=hard -mfpu=fpv5-d16 -mfp16-format=ieee

(the new option -mfp16-format=ieee is for the choice of half-precision float operations, works faster)

2.  again include in the main()

fpu_enable();

which is some porting work to do from ASF3 because this is not part of the library produced in START/ASF4 , but after I've done this floating point worked on a simple arithmetic but not in sprintf() .

 

Eventually I started another test-bed project to test

3. unchecked linker option "use size optimized library" since my main project fails without this option.

 

Then everything worked with floating point.

So this 3 changes were needed with current ASF4 library and SAME70 MCU to get float working with hardware implementation.

Hope that whoever will come to this thread again will not need to do another search!

Now I got a new unrelated problem to solve : why my main project fails with unchecked "use size optimized library" linker option... Oh well , this is another search :)

Last Edited: Tue. Jan 14, 2020 - 01:37 AM