Hi Sebastien, Now we have it for each PR on github.
BR, Alan On Wed, Jul 8, 2026 at 11:47 AM Sebastien Lorquet <[email protected]> wrote: > micropython devs are always adding before/after size measurements to > their pull requests IIRC > > That would be a good thing to become more aware of the impact of additions. > > Sebastien > > > On 7/8/26 16:40, Peter van der Perk wrote: > > Hi all, > > > > I'd like to add one point to this discussion. > > > > We should be careful about adding new functionality that becomes > mandatory for everyone. For example, > https://github.com/apache/nuttx/pull/7724 added hex parsing support to > strtod(), but there was no way to disable it. > > As a result, every target using strtod() picked up ~2 KB of additional > flash usage. Luckily with https://github.com/apache/nuttx/pull/17789 we > can opt-out now. > > > > But in general, if a feature has a non-trivial code size impact, it > would be good to have a Kconfig option for it to be able to opt-out. > > > > On the topic of making NuttX smaller again, it may be worth auditing > features that have been added over the years without such an opt-out. There > may be some easy wins there for size-constrained targets. > > > > Regards, > > > > Peter > > > > -----Original Message----- > > From: Alan C. Assis <[email protected]> > > Sent: Wednesday, July 8, 2026 4:25 PM > > To: [email protected] > > Subject: [EXT] Re: Make NuttX Tiny Again (pun intended) > > > > > > > > Tiago, > > In this case we are not introducing a hidden incompatibility, the > developer needs to disable it intentionally. > > > > Remember: the POSIX is a moving target, so even time 32-bit used to be a > POSIX standard. > > > > And since 64-bit time is supported, then the new POSIX standard is > compliant for users who want to use it with supported hardware. > > > > BR, > > > > Alan > > > > > > > > On Wed, Jul 8, 2026 at 11:05 AM Tiago Medicci Serrano < > [email protected]> wrote: > > > >> Hi, > >> > >> If we intend to use the `INVIOLABLES.md`, we need to use it fully. > >> This isn't a question about it, IMHO. > >> Strict POSIX compliance > >> > >> - Strict conformance to the portable standard OS interface as > defined at > >> OpenGroup.org. > >> - A deeply embedded system requires some special support. Special > >> support must be minimized. > >> - The portable interface must never be compromised only for the > sake of > >> expediency. > >> - *Expediency or even improved performance are not justifications > for > >> violation of the strict POSIX interface.* > >> > >> Best regards, > >> > >> Em qua., 8 de jul. de 2026 às 10:48, Sebastien Lorquet < > >> [email protected]> > >> escreveu: > >> > >>> Hello > >>> > >>> Quoting INVIOLABLES.md > >>> > >>> > >>> All Users Matter > >>> > >>> ... > >>> > >>> # We should seek to expand the NuttX user base, not to limit it for > >>> reasons of preference or priority. > >>> # We must resist the pull to make NuttX into a Linux-only, GCC-only, > >>> and ARM-only solution. > >>> > >>> > >>> > >>> Sebastien > >>> > >>> > >>> On 7/8/26 15:44, Tiago Medicci Serrano wrote: > >>>> Hi! > >>>> > >>>> Do we have any metrics about such chips? Does anyone use them? > >>>> This is important to build a strong opinion on whether to create > >>>> exceptions > >> given > >>>> our limited resources and the availability of more modern chips > >>>> and features to be implemented. > >>>> > >>>> My point is all about focusing on what matters. Eventually, some > >>>> chips > >>> may > >>>> be lost while NuttX (or any other OS) evolves. This is something > >> natural > >>>> for any project. To create exceptions, we need to think of NuttX > >>>> as a product. Do we have customers that require it? How important is > that? > >>>> > >>>> Best regards, > >>>> > >>>> Em qua., 8 de jul. de 2026 às 10:27, Alan C. > >>>> Assis<[email protected]> > >>>> escreveu: > >>>> > >>>>> Exactly! That is the point! > >>>>> > >>>>> It will be an option for people using MCUs with < 64KB Flash memory. > >>> Thank > >>>>> you Karel. > >>>>> > >>>>> My suggestion add inside: > >>>>> RTOS Features --> > >>>>> [*] Disable NuttX interfaces > >>>>> [*] Disable POSIX Compatibility (default N and depends > >>>>> on > >>>>> DEFAULT_SMALL) > >>>>> Only after this option user will be able to disable > >>>>> TIME64 > >>> and > >>>>> LIBC_LONG_LONG > >>>>> > >>>>> Also, I think the "DEFAULT_SMALL" symbol is a confusing name, I > >> suggest > >>>>> renaming it to "SMALL_KERNEL" or similar. > >>>>> > >>>>> BR, > >>>>> > >>>>> Alan > >>>>> > >>>>> On Wed, Jul 8, 2026 at 10:07 AM Karel Kočí<[email protected]> wrote: > >>>>> > >>>>>> Hi > >>>>>> > >>>>>> My two cents: > >>>>>> > >>>>>> * Nobody is suggesting to break POSIX compatibility for everyone. > >>> Alan's > >>>>>> suggestion is to have option to break it to reduce the size. > >>>>>> * It might be worth it to explicitly track chips that do support > >> POSIX > >>> in > >>>>>> NuttX > >>>>>> fully and those that need compromises. > >>>>>> > >>>>>> Just two cents.. > >>>>>> Karel > >>>>>> > >>>>>> > >>>>>> On Wed 08 Jul 2026 07:49:10 AM , Tiago Medicci Serrano wrote: > >>>>>>> Hi! > >>>>>>> > >>>>>>> I don't think NuttX getting bigger is an issue at all. Of > >>>>>>> course, we > >>>>>> should > >>>>>>> care about code size: this is an important metric to be aware > >>>>>>> of, > >> and > >>> we > >>>>>>> should avoid unnecessary code. > >>>>>>> > >>>>>>> This is not the case here. The recent code changes are required > >>>>>>> to > >> be > >>>>>>> compatible with modern POSIX systems. Removing them just to fit > >>>>>>> on > >>>>>> smaller > >>>>>>> MCUs would be intentionally making NuttX worse just to make it > >>>>>>> fit > >>> into > >>>>>>> MCUs that we don't have any usage analytics for. > >>>>>>> > >>>>>>> Systems evolve. Linux kernel is deprecating support for older CPUs. > >>>>>>> > >>>>>>> People use NuttX because it's POSIX-compatible and the burden > >>>>>>> of > >>>>>> migrating > >>>>>>> applications is lower: that's the goal we should pursue first, > IMHO. > >>>>>>> People use Zephyr for other reasons. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> > >>>>>>> Em ter., 7 de jul. de 2026 às 17:08, Alan C. Assis< > >> [email protected]> > >>>>>>> escreveu: > >>>>>>> > >>>>>>>> I know it was discussed a lot, but I think removing > >>>>>> CONFIG_LIBC_LONG_LONG > >>>>>>>> alone (because TIME64) added about 2KB: > >>>>>>>> > >>>>>>>> Current mainline: > >>>>>>>> > >>>>>>>> $ arm-none-eabi-size nuttx > >>>>>>>> text data bss dec hex filename > >>>>>>>> 64008 1548 3996 69552 10fb0 nuttx > >>>>>>>> > >>>>>>>> Beforehttps://eur01.safelinks.protection.outlook.com/?url=http > >>>>>>>> s%3A%2F%2Fgithub.com%2Fapache%2Fnuttx%2Fpull%2F18840&data=05%7 > >>>>>>>> C02%7Cpeter.vanderperk%40nxp.com%7C5508779984014a12f84008dedcf > >>>>>>>> cd56a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63919117564 > >>>>>>>> 9181727%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > >>>>>>>> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > >>>>>>>> %7C0%7C%7C%7C&sdata=ixH56rTc0oI90Fd6R%2B6FjdD1eE9IUbuLGTFOR0sE > >>>>>>>> PTw%3D&reserved=0 (at commit > >>>>>>>> 4f6e695f7c56aa5a321008ca8e5ddd47e1959e4d) : > >>>>>>>> > >>>>>>>> $ arm-none-eabi-size nuttx > >>>>>>>> text data bss dec hex filename > >>>>>>>> 61936 1548 3764 67248 106b0 nuttx > >>>>>>>> > >>>>>>>> For 64KB Flash, these 2KB doesn't appear too much, but > >>>>>>>> consider > >> that > >>>>>> these > >>>>>>>> are 2KB that we never can get rid of. > >>>>>>>> > >>>>>>>> So, few years ago NuttX was able to fit inside a 32KB and 4KB > >>>>>>>> RAM > >>> MCU: > >>>>>>>> (LPC1114FN28: > >>>>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2 > >>>>>>>> F%2Fwww.flickr.com%2Fphotos%2F79703543%40N00%2F18013069041%2Fs > >>>>>>>> izes%2Fl%2F&data=05%7C02%7Cpeter.vanderperk%40nxp.com%7C550877 > >>>>>>>> 9984014a12f84008dedcfcd56a%7C686ea1d3bc2b4c6fa92cd99c5c301635% > >>>>>>>> 7C0%7C0%7C639191175649210604%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > >>>>>>>> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > >>>>>>>> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=muw9UJ4uaWmpMyXoGv4mp > >>>>>>>> 2xabbDv8eKlohI2y56G%2Fm0%3D&reserved=0 ) > >>>>>>>> > >>>>>>>> If we keep increasing at this rhythm very soon people will > >>>>>>>> have > >>>>>> another > >>>>>>>> reason to use > >>>>>>>> Zephyr:https://eur01.safelinks.protection.outlook.com/?url=htt > >>>>>>>> ps%3A%2F%2Fgzm-emb.com%2Fblog%2Fzephyr-16kb%2F&data=05%7C02%7C > >>>>>>>> peter.vanderperk%40nxp.com%7C5508779984014a12f84008dedcfcd56a% > >>>>>>>> 7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63919117564922653 > >>>>>>>> 0%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >>>>>>>> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 > >>>>>>>> C%7C%7C&sdata=dk8D2fWCU96547zs50pNqsMR7s8Kmn3ruvjfGEENbV0%3D&r > >>>>>>>> eserved=0 (in > >> this > >>>>>>>> example it was 105KB Flash and 16KB, so we still have hope). > >>>>>>>> > >>>>>>>> The same way we reconsidered the signals, I think we should > >>>>>>>> give > >> the > >>>>>> user > >>>>>>>> the option to disable TIME64 and LIBC_LONG_LONG and run NuttX > >>>>>>>> on > >>>>>> small MCUs. > >>>>>>>> BR, > >>>>>>>> > >>>>>>>> Alan > >>>>>>>> > >>>>>>>> On Tue, Jul 7, 2026 at 12:17 PM Alan C. > >>>>>>>> Assis<[email protected]> > >>>>>> wrote: > >>>>>>>>> Hi Michael, > >>>>>>>>> > >>>>>>>>> Thank you very much, in fact the printf implementation that > >>>>>>>>> NuttX > >>>>>> uses > >>>>>>>>> currently was contributed by Keith Packard himself some years > ago. > >>>>>>>>> > >>>>>>>>> But I don't know how it compares to his new picolibc. > >>>>>>>>> > >>>>>>>>> BR, > >>>>>>>>> > >>>>>>>>> Alan > >>>>>>>>> > >>>>>>>>> On Tue, Jul 7, 2026 at 11:50 AM Michael Jung < > >>> [email protected] > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Hi Alan, all, > >>>>>>>>>> > >>>>>>>>>> I believe picolibc has a very size efficient implementation > >>>>>>>>>> of > >>>>>> printf > >>>>>>>>>> and scanf. See Keith's talk > >>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F% > >>>>>> 2Fwww.youtube.com%2Fwatch%3Fv%3De3Vxr0iLIUE&data=05%7C02%7Cpeter > >>>>>> .vanderperk%40nxp.com%7C5508779984014a12f84008dedcfcd56a%7C686ea > >>>>>> 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C639191175649240882%7CUnkno > >>>>>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA > >>>>>> iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata > >>>>>> =2JatMPbzPcH5%2FvacbNclAG6WZzejCp6e%2F86O8knfbDA%3D&reserved=0 > >>>>>>>>>> at minute 13:06. > >>>>>>>>>> > >>>>>>>>>> Bye, > >>>>>>>>>> Michael > >>>>>>>>>> > >>>>>>>>>> On Tue, Jul 7, 2026 at 4:33 PM Alan C. > >>>>>>>>>> Assis<[email protected]> > >>>>>> wrote: > >>>>>>>>>>> Hi Everyone, > >>>>>>>>>>> > >>>>>>>>>>> Seems like we NuttX got great in the last few years. > >>>>>>>>>>> > >>>>>>>>>>> Although in general it is still using very little RAM > >>>>>>>>>>> memory and > >>> it > >>>>>>>>>>> uses a lot of Flash. > >>>>>>>>>>> > >>>>>>>>>>> So, even boards with 64KB of Flash are breaking: > >>>>>>>>>>> > >>>>>>>>>>> > >> ====================================================================== > >> ============== > >>>>>>>>>>> Cmake in present: > >>>>>>>>>>> nucleo-f302r8/ihm07m1_b16,CONFIG_ARM_TOOLCHAIN_GNU_EABI > >>>>>>>>>>> Configuration/Tool: > >>>>>>>>>>> nucleo-f302r8/ihm07m1_b16,CONFIG_ARM_TOOLCHAIN_GNU_EABI > >>>>>>>>>>> 2026-07-07 13:44:43 > >>>>>>>>>>> > >> ---------------------------------------------------------------------- > >> -------------- > >>>>>>>>>>> Cleaning... > >>>>>>>>>>> Configuring... > >>>>>>>>>>> Select HOST_LINUX=y > >>>>>>>>>>> TOOLS_DIR path is "/github/workspace/sources/nuttx" > >>>>>>>>>>> HOST = Linux > >>>>>>>>>>> Disabling CONFIG_ARM_TOOLCHAIN_GNU_EABI Enabling > >>>>>>>>>>> CONFIG_ARM_TOOLCHAIN_GNU_EABI Building NuttX... > >>>>>>>>>>> TOOLS_DIR path is "/github/workspace/sources/nuttx" > >>>>>>>>>>> HOST = Linux > >>>>>>>>>>> [1/5] cd > >>>>>>>>>>> /github/workspace/sources/nuttx/build/libs/libc/misc && > >>>>>>>>>>> /usr/local/bin/cmake -E touch > >>>>>>>>>>> /github/workspace/sources/nuttx/libs/libc/misc/lib_utsname. > >>>>>>>>>>> c [2/5] Linking C executable nuttx > >>>>>>>>>>> FAILED: nuttx > >>>>>>>>>>> : && /tools/ccache/bin/arm-none-eabi-gcc > >>>>>>>>>>> --specs=nosys.specs -Wl,--print-memory-usage > >>>>>>>>>>> -Wl,--entry=__start -nostdlib > >>>>>> -Wl,--gc-sections > >>>>>>>>>>> -Wl,--cref -Wl,-Map=nuttx.map @CMakeFiles/nuttx.rsp -o > >>>>>>>>>>> nuttx && > >> : > >> > /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: > >>>>>>>>>>> nuttx section `.data' will not fit in region `flash' > >>>>>>>>>>> > >> > /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: > >>>>>>>>>>> region `flash' overflowed by 4 bytes Memory region Used > >>>>>>>>>>> Size Region Size %age Used > >>>>>>>>>>> flash: 65540 B 64 KB 100.01% > >>>>>>>>>>> sram: 5556 B 16 KB 33.91% > >>>>>>>>>>> collect2: error: ld returned 1 exit status > >>>>>>>>>>> ninja: build stopped: subcommand failed. > >>>>>>>>>>> cp: cannot stat 'nuttx.hex': No such file or directory > >>>>>>>>>>> cp: cannot stat 'nuttx.bin': No such file or directory > >>>>>>>>>>> cp: cannot stat 'nuttx.hex': No such file or directory > >>>>>>>>>>> cp: cannot stat 'nuttx.bin': No such file or directory > >>>>>>>>>>> /github/workspace/sources/nuttx > >>>>>>>>>>> /github/workspace/sources/nuttx > >>>>>>>>>>> > >>>>>>>>>>> It is important to notice that CONFIG_DEFAULT_SMALL is > >>>>>>>>>>> already > >>>>>> defined > >>>>>>>>>>> to it. > >>>>>>>>>>> > >>>>>>>>>>> Analyzing the 20 biggest functions there is not a single > >> culprit, > >>>>>> so > >>>>>>>>>>> probably we need to reduce the overall functions size: > >>>>>>>>>>> > >>>>>>>>>>> $ arm-none-eabi-nm --print-size --size-sort --radix dec -C > >> nuttx | > >>>>>> grep > >>>>>>>>>>> ' [TtWw] ' | tail -20 > >>>>>>>>>>> 134243508 00000390 t pwm_configure > >>>>>>>>>>> 134217728 00000392 T _vectors > >>>>>>>>>>> 134229344 00000396 t adc_read > >>>>>>>>>>> 134249208 00000400 t file_vioctl > >>>>>>>>>>> 134218408 00000424 T stm32_configgpio > >>>>>>>>>>> 134269892 00000448 T motor_aobserver_nfo_b16 > >>>>>>>>>>> 134231544 00000448 t uart_writev > >>>>>>>>>>> 134239368 00000460 t stm32_foc_setup > >>>>>>>>>>> 134261888 00000468 T parse_args > >>>>>>>>>>> 134264176 00000500 T foc_motor_init > >>>>>>>>>>> 134263096 00000540 T foc_fixed16_thr > >>>>>>>>>>> 134256256 00000540 T nxsig_tcbdispatch > >>>>>>>>>>> 134233432 00000540 t uart_ioctl > >>>>>>>>>>> 134265056 00000612 T foc_motor_control > >>>>>>>>>>> 134265668 00000648 T foc_motor_handle > >>>>>>>>>>> 134231992 00000652 t uart_readv > >>>>>>>>>>> 134260828 00000692 T foc_main > >>>>>>>>>>> 134252412 00000700 T __udivmoddi4 > >>>>>>>>>>> 134245448 00000860 t nsh_parse_command > >>>>>>>>>>> 134258408 00001234 t vsprintf_internal.constprop.0 > >>>>>>>>>>> > >>>>>>>>>>> I can't resist to ask the Claude to analyze these data, and > >>>>>>>>>>> it > >>>>>> gave us > >>>>>>>>>>> some picture of current code tree: > >>>>>>>>>>> > >>>>>>>>>>> [image: image.png] > >>>>>>>>>>> > >>>>>>>>>>> And seems like NSH and printf (vsprintf) are the biggest > >>> offenders: > >>>>>>>>>>> [image: image.png] > >>>>>>>>>>> > >>>>>>>>>>> So, if someone has some suggestions on how we can improve > >>>>>>>>>>> this scenario, please let me know. > >>>>>>>>>>> > >>>>>>>>>>> At least now we have the option to disable some important > >> features > >>>>>> like > >>>>>>>>>>> signals (that unfortunately will break POSIX > >>>>>>>>>>> compatibility). But > >>>>>> maybe we > >>>>>>>>>>> can apply some diet to NSH and printf to improve it. > >>>>>>>>>>> > >>>>>>>>>>> BR, > >>>>>>>>>>> > >>>>>>>>>>> Alan > >>>>>>>>>>> >
