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