If we are 2Kb short of 64Kb, then we are already at that threshold of 64Kb support. You probably cannot make a legitimate application that actually does anything on the effected platforms now. A 2Kb savings now would only be a stopgap measure as the size will certainly continue to grow and will likely consume that freed 2Kb in a few months. What would you do then? Put in another POSIX compliancy to work around the addition al size.
It seems to me that unless there is an effort with larger scope than this then we can write off 64Kb support either now or in the next few months but bad bandages. Bandages will not do the job in the long term. In the long term they only corrupt the POSIX compliancy and the clean design. ________________________________ From: Alan C. Assis <[email protected]> Sent: Wednesday, July 8, 2026 6:27 AM To: [email protected] <[email protected]> Cc: Tiago Medicci Serrano <[email protected]> Subject: Re: Make NuttX Tiny Again (pun intended) 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 > > > > > > Before https://github.com/apache/nuttx/pull/18840 (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://www.flickr.com/photos/79703543@N00/18013069041/sizes/l/ ) > > > > > > If we keep increasing at this rhythm very soon people will have another > > > reason to use Zephyr: https://gzm-emb.com/blog/zephyr-16kb/ (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://www.youtube.com/watch?v=e3Vxr0iLIUE > > >>> 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 > > >>>> > > >>> >
