micropython devs are always adding before/after size measurements to
their pull requests IIRC
That would be a good thing to become more aware of the impact of additions.
Sebastien
On 7/8/26 16:40, Peter van der Perk wrote:
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
