math library support in wiced sense build

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

hi all

i need to use math library for my application ..

but  for every function call like sqrt(), atan() sin() i m getting undefined reference error  like below

C:\Users\knayak\Documents\WICED\WICED-Smart-SDK-2.1.1\WICED-Smart-SDK\Wiced-Smart\spar/../../Apps/hello_sensor/hello_sensor.c:468: undefined reference to `sqrt'

make.exe[1]: *** [../../build/hello_sensor-BCM920736TAG_Q32-rom-ram-Wiced-release/A_20736A1-hello_sensor-rom-ram-spar.elf] Error 1

makefile:152: recipe for target '../../build/hello_sensor-BCM920736TAG_Q32-rom-ram-Wiced-release/A_20736A1-hello_sensor-rom-ram-spar.elf' failed

Makefile:329: recipe for target 'hello_sensor-BCM920736TAG_Q32' failed

make: *** [hello_sensor-BCM920736TAG_Q32] Error 2


i included #include <math.h> in the source file

i could see that the build system can not able to link to libm.a (which is a math library)


this build is using arm-none-eabi-  cross toochain.  i came to know that to link to math library i have to add "-lm"  flag

but i really dont know where to modify..



can anybody faced this issues. or have any solutions pls help .


thanks in advance


1 Solution
Anonymous
Not applicable

My experience with embedded processors and systems:

  • Avoid to use functions which result in heavy library code needed and loaded.
    Example: just doing a printf("%d") can result in getting all functions potentially needed, e.g. also for "%f" even never used (check the list file for functions). A single printf even for just a "%x" can blow up your code by many KB). Therefore, using instead:
        str = itoa(val, str, 16);
        puart_write(str);
    might be more efficient instead of doing printf("%x", val);
  • Avoid floating point. Instead go with fixed point (e.g. as the sensor values are already, e.g. 280 as 28.0,
    so I.F as fixed point where F is /10 part.
  • Do not use real math libs. Use other approaches to do calculations. If just one function is needed, e.g. simple SQRT() but nothing else: implement this yourself. It helps to reduce the code size.
    Consider also that working with fixed point might make things easier: example: instead of 10.12345
    you can convert all into fix point representation 1012345 (all multiplied by 100000). So, you can use just integers (long or long long). Just when you print you do the "conversion":
    printf("val: %d.%d", val / 100000, val % 100000);
    And a SQRT on int instead of float can be much easier and shorter.
  • It might be needed to fight really for code size (or speed - but also having code size in mind).
    Programming on Embedded System is very different to programming on PCs. Your system is not a PC. Few KB of code and data size can matter (if it fits or not into ROM/SRAM).
    When you gain some SRAM - it is worth to use it instead for buffers, FIFO etc. To have it just allocated by a LIB and never used is quite inefficient.
  • Avoid to use malloc() on Embedded Systems: large overhead, slow, memory fragmentation and very risky with small SRAM size: often people do not check if malloc was successful or system is out of memory. Very risky on embedded systems (you cannot recover anyway if Out of Memory happens). Have your own, dedicated and predictable buffer management (often RTOS's use the "pool" idea with fix sized segments).
  • Avoid large local variables (as auto, stored on stack):
    Example:
    void myFunction(void) {
         char largeBufferOnStack[2048];
    This can generate stack overflows without any warnings. During runtime you might hit data segment and you destroy other regions.
    Example: you have just 8K of SRAM, 1K is intended to be used as stack. Just doing this code above results in: no compile error, no complain about code size too large - but during runtime you crash ! You use 2K of stack region just for this variable.

View solution in original post

5 Replies
Anonymous
Not applicable

There was a discussion on community about similar issue: floating point support.

I think: floating point and esp. math lib will not fit into memory and is not enabled (more then my guess, an expectation).

It is a tiny embedded processor, already running an RTOS.

Maybe you can modify makefiles and add such libs but potentially your code will get too large.

(it would be quite slow anyway on CM3 with 27 MHz)

0 Likes
Anonymous
Not applicable

thanks guys.. so i need try something else

but i found something like "You can also consider using a fixed point math library like libfixmath" in the below post

Re: Floating-Point Arithmetic

i couldnt find this library. if its der . which build file i have to modify ?, so that the linker can find it ..

0 Likes
Anonymous
Not applicable

My experience with embedded processors and systems:

  • Avoid to use functions which result in heavy library code needed and loaded.
    Example: just doing a printf("%d") can result in getting all functions potentially needed, e.g. also for "%f" even never used (check the list file for functions). A single printf even for just a "%x" can blow up your code by many KB). Therefore, using instead:
        str = itoa(val, str, 16);
        puart_write(str);
    might be more efficient instead of doing printf("%x", val);
  • Avoid floating point. Instead go with fixed point (e.g. as the sensor values are already, e.g. 280 as 28.0,
    so I.F as fixed point where F is /10 part.
  • Do not use real math libs. Use other approaches to do calculations. If just one function is needed, e.g. simple SQRT() but nothing else: implement this yourself. It helps to reduce the code size.
    Consider also that working with fixed point might make things easier: example: instead of 10.12345
    you can convert all into fix point representation 1012345 (all multiplied by 100000). So, you can use just integers (long or long long). Just when you print you do the "conversion":
    printf("val: %d.%d", val / 100000, val % 100000);
    And a SQRT on int instead of float can be much easier and shorter.
  • It might be needed to fight really for code size (or speed - but also having code size in mind).
    Programming on Embedded System is very different to programming on PCs. Your system is not a PC. Few KB of code and data size can matter (if it fits or not into ROM/SRAM).
    When you gain some SRAM - it is worth to use it instead for buffers, FIFO etc. To have it just allocated by a LIB and never used is quite inefficient.
  • Avoid to use malloc() on Embedded Systems: large overhead, slow, memory fragmentation and very risky with small SRAM size: often people do not check if malloc was successful or system is out of memory. Very risky on embedded systems (you cannot recover anyway if Out of Memory happens). Have your own, dedicated and predictable buffer management (often RTOS's use the "pool" idea with fix sized segments).
  • Avoid large local variables (as auto, stored on stack):
    Example:
    void myFunction(void) {
         char largeBufferOnStack[2048];
    This can generate stack overflows without any warnings. During runtime you might hit data segment and you destroy other regions.
    Example: you have just 8K of SRAM, 1K is intended to be used as stack. Just doing this code above results in: no compile error, no complain about code size too large - but during runtime you crash ! You use 2K of stack region just for this variable.
Anonymous
Not applicable

awsme great info . thanks tjaekel

0 Likes