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