Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 10 of 10

Thread: Using nano-lib instead of new-lib

  1. #1
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,651

    Using nano-lib instead of new-lib

    From time to time weird issues and workarounds pop up when using the STL with Teensies. Latest examples:


    Simon.M found that switching to optimizer setting "smallest code" fixes some of those issues. This setting not only sets the -Os flag but also changes the used c-library from new-lib to nano-lib which fixes the issue regardless of the -Os setting.
    Besides handling the STL much better than new-lib, nano-lib also dramatically reduces the memory footprint for sketches using the STL. E.g. on a T3.2 the simple deque code from the linked deque post above uses some 28% flash with new-lib and only 3% with nano-lib. I'm aware that, by default, nano-lib deactivates float support for printf but that is easy to activate by using --specs=nano.specs -u _printf_float. With activated float support the example needs about 7% flash which is still only a quarter of the new-lib version.

    So, my question is: are there any disadvantages of nano-lib vs new-lib? If not, would it be feasible to switch to nano-lib by default?

  2. #2
    Junior Member
    Join Date
    May 2021
    Location
    Canada
    Posts
    9
    Well I don't have much technical information, but I've switched to nano-lib about a year ago on a couple of Teensy 3.2 firmwares I build that were already barely fitting in the 256k flash space, and I haven't noticed any functional difference so far, even float support and printf/scanf formatters work the same. And average firmware size went down to about 190k.

  3. #3
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,651
    Thanks for the info. I think I'll add an option for an easy switch between new-lib and nano-lib in VisualTeensy and see if I observe some disadvantages in the next months.
    Besides the impressive space savings it seems to really fix some of the STL issues.

    I also did some googling regarding differences and found this:
    Nanolib is smaller and faster than newlib by code and data size reduction through optimization and removal of non-MCU features. Nanolib was originally developed as part of the GNU Arm Embedded Toolchain but is now the standard GCC embedded C library for microcontrollers. For ARM distributors, some optimized routines written in ARM assembly are used to further reduce the code size and run time.
    (https://imagecraft.com/blog/2019/04/...ib-vs-nanolib/)

  4. #4
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,435
    Would be interesting to see some benchmarks

  5. #5
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    160
    Hello Luni,

    I'd like to see this in VisualTeensy too.

    Thank you,
    Manu

  6. #6
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,651
    Here you are: https://github.com/luni64/VisualTeen...ses/tag/v1.4.0

    You can switch now between the standard newlib and newlib-nano in expert settings mode:

    Click image for larger version. 

Name:	Screenshot 2021-10-17 205532.png 
Views:	13 
Size:	32.8 KB 
ID:	26209

  7. #7
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    160
    Thank you Luni. Will try it today.

  8. #8
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    160
    A fast test. Optimisation is set to "faster":

    With NEWLIB-STANDARD :
    [LD] .vsteensy/build/CAN_GPS-T3.elf ←[38;2;255;159;159m
    Memory region Used Size Region Size %age Used
    FLASH: 73172 B 256 KB 27.91%
    RAM: 14196 B 64 KB 21.66%
    ←[38;2;179;255;179mUser code built and linked to libraries

    With NEWLIB-NANO :
    [LD] .vsteensy/build/CAN_GPS-T3.elf ←[38;2;255;159;159m
    Memory region Used Size Region Size %age Used
    FLASH: 57396 B 256 KB 21.89%
    RAM: 12144 B 64 KB 18.53%
    ←[38;2;179;255;179mUser code built and linked to libraries
    Software seem to operate normaly. Have to test it more to be sure.
    Thank you

  9. #9
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,435
    While it's nice that the code is smaller, it only has an effect if you need 100% flash or RAM otherwise.

    Is it faster?

    @Luni: don't you use the Teensy size tool?

  10. #10
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    160
    Agree about code size. It's usefull when you are near the max flash or ram. But I like to know what I can do if I reach one of this limits one day.

    No, it's not faster with my current code. Loop is about 4ÁS in each case. My current code is mostly driven per Timers so it's difficult to see if it's really change the speed without adding many lines to check. A fast test seem to show that it don't.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •