5 Replies Latest reply on Nov 26, 2014 5:06 AM by userc_12119

    math library support in wiced sense build

      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. Re: math library support in wiced sense build

          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)

          • 3. Re: math library support in wiced sense build

            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 ..

            • 4. Re: math library support in wiced sense build

              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.
              • 5. Re: math library support in wiced sense build

                awsme great info . thanks tjaekel