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