Using nano-lib instead of new-lib

[luni]

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

• 68342-std-deque-Won-t-Compile-for-Teensy-3-x
• 68366-std-string-causes-link-error

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?

 

[rbfowler9]

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.

 

[luni]

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/embedded-gcc-libraries-newlib-vs-nanolib/)

 

[Frank B]

Would be interesting to see some benchmarks

 

[Manu]

Hello Luni,

I'd like to see this in VisualTeensy too.

Thank you,
Manu

 

[luni]

Here you are: https://github.com/luni64/VisualTeensy/releases/tag/v1.4.0

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

 

[Manu]

Thank you Luni. Will try it today.

 

[Manu]

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

 

[Frank B]

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?

 

[Manu]

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.