Hi, >From my side, I'm against creating exceptions that go against our main goal (the reason NuttX exists), even more so without proper data to support it, not as a technical argument, but as a commercial decision.
About Zephyr, well, they support 3 (out of 1K+). And, again, we are not Zephyr. People use Zephyr for other reasons. People use NuttX because it's POSIX-compatible. [image: image.png] IMHO, we should not create such a kind of exception. Jumping out of this discussion for now. Best regards, Em qua., 8 de jul. de 2026 às 11:14, Alan C. Assis <[email protected]> escreveu: > Tiago, > support for small MCUs open NuttX usages for new users and scenarios. > > We don't need to do a market analysis to discover it. > All companies' goal is to reduce costs, so they will select the smaller > MCU that solves their issue and the RTOS that fit on it. > > It is not if there is a market for these MCUs (otherwise they shouldn't be > produced) , it is if there is a RTOS for these MCUs. > > And the answer is clear, there is: > https://docs.zephyrproject.org/latest/boards/index.html#ram-max=2&flash-max=16 > > BR, > > Alan > > On Wed, Jul 8, 2026 at 10:44 AM Tiago Medicci Serrano < > [email protected]> 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 >>>> > > >>>> > > 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 >>>> > >>>> >>>> > >>> >>>> >>>
