- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In below discussion, i was informed that:
floating point arithmetic are not included within the ROM and SDK because they consume a lot of precious resources.
I made some simple tests best on hello sensor app on WICED 2.1.1
Test 1,
float a = 1.4;
float b = 2.9;
float c = a * b;
float d = b / a;
ble_trace2("c=%d, d=%d", c, d);
build passed and the output is c=4, d=2, which is a correct result.
However from the generated assembly(hello_sensor.s), i did not find any symbol like __aeabi_fmul or __aeabi_fdiv.
Test 2,
float my_fmul(float x, float y)
{
return x*y;
}
float my_fdiv(float x, float y)
{
return x/y;
}
float a = 1.4;
float b = 2.9;
float c = my_fmul(a, b);
float d = my_fdiv(b, a);
ble_trace2("c=%d, d=%d", c, d);
build passed and the result is "c=4, d=2" which is also a correct result.
From hello_sensor.s, i found below symbols:
.global | __aeabi_fmul |
bl | __aeabi_fmul |
.global | __aeabi_fdiv |
bl | __aeabi_fdiv |
I try to search which module did those two symbol reside in. Below is what i found in the generate list file:
_aeabi_cdrcmple ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_d2ulz ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_dadd ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_ddiv ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_dmul ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_drsub ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_dsub ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_fdiv ../../build/hello_sensor_tmp-BCM920736TAG_Q32-rom-ram-Wiced-release/hello_sensor.o
__aeabi_fmul ../../build/hello_sensor_tmp-BCM920736TAG_Q32-rom-ram-Wiced-release/hello_sensor.o
__aeabi_lasr ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_llsl ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_llsr ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_memclr ../tier2/brcm/mandatory/bld/20736/patch.elf
__aeabi_memclr4 ../tier2/brcm/mandatory/bld/20736/patch.elf
I still have no idea where did these symbol come from:-(
Test 3:
A little bit modification on below function:
float my_fmul(float x, float y)
{
x =x*y*x; // added
return x*y;
}
Build OK.
Test 4:
Added one more line:
float my_fmul(float x, float y)
{
x =x*y*x;
y = x*y*x; // added
return x*y;
}
Clean and build again, but this time i got many errors like:
C:\Data\Work\Broadcom\BLE\WICED_Smart_SDK\WICED-Smart-SDK-2.1.1\WICED-Smart-SDK_Test\Wiced-Smart\spar/../../Apps/hello_sensor_tmp/hello_sensor.c:398: undefined reference to `__aeabi_fmul'
I also check __aeabi_fmul and __aeabi_fdiv, they still appear in the hello_sensor.s and ***.list file.
why, why, why?
Any one can help me?
thanks
Solved! Go to Solution.
- Labels:
-
SDK 2.X
- Tags:
- wiced
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This has been discussed over in this thread: Re: Floating-Point Arithmetic
Essentially, the recommendation was to use a fixed point math library like libfixmath.
With caching and the look-up-table disabled, this library compiles to under 2K. Unused function elimination is enabled by default for all applications in the SDK. So only functions that are accessed by the application will be included in the final image.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For what I know:
You can use floating point on ARM processors in two ways:
a) HW floating point (if core as SIMD, for instance), b) SW floating point.
But might result in having a run time lib bound to your FW, a standard ARM lib.
The compiler has options to specify which flavor, maybe also a need to add a LIB and path (-l and -L).
If you use floating point (which should work, at least as SW FP, I am sure), you might miss some compile and linker options. It depends on the makefile.
Some instructions, sometime also just an integer multiplication, uses a run time function (rt_mul or something like this).
It looks to me, a lib or compiler options is "just" missing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks.
There is no HW FPU for Cortex-M3. So, usually compiler/tool vendor like keil and IAR will provide the software float point library by themselves.
But as far as I know, WICED Smart does not have software float point lib.
However, on test 1, i did not see any build error and the float point operation works fine. It is so strange.
You can make same tests on your side and you may get different result
thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see, I have to find time to test it.
BTW: doing floating point with variable and printing it via printf are different issues: it can happen that you can do
floating point operations but printf("%f") is not supported. (just to mention).
Anyway, I think an issue with the compiler and linker options. It "must" be possible to use SW floating point, even with printf supporting it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi, tjaekel,
Yes, i did NOT use printf("%f").
In the previous tests, i only use ble_trace("%d").
Please share your result after your test
thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This has been discussed over in this thread: Re: Floating-Point Arithmetic
Essentially, the recommendation was to use a fixed point math library like libfixmath.
With caching and the look-up-table disabled, this library compiles to under 2K. Unused function elimination is enabled by default for all applications in the SDK. So only functions that are accessed by the application will be included in the final image.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, mwf,
Yes, this has been discussed but it did not solve the issues i mentioned in this discussion.
If the WICED Smart 2.1.1 does NOT support SW FPU, why there is no build error and the float operations in test 1 and 2 is correct?
If support, why so many build errors in test 4?
thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello roger_lu,
The SDK 2.1.1 does NOT support SW FPU.
Thanks,
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, J.t
Thanks for your quick reply.
So, in float operations in above tests, why there is no build errors and the result is even correct?
Can you please also verify my test result in the top?
thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello roger_lu
Sorry for the lack of support for FPU Libraries.
I don't have an exact reason why Test 1,2 and 3 should pass.
Because of the lack of available memory in our BLE devices and our stack being in ROM, we avoid the SW FPU.
Again, apologize for the lack of support for the FPU library,
Thanks
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi, j.t
thanks for your confirmation.
I'll try to find some third-party SW FPU later.
If you have some good recommendations(not fix point), let me know
BTW: Does WICED 2.1.1 support assembly file to work together with C source file?
thanks again.
Roger