Add Berry embedded scripting support as an optional NuttX system app

[speccy88]

Is your feature request related to a problem? Please describe.

Hi NuttX maintainers,

I wanted to ask whether there would be maintainer interest in a pull request adding Berry as an optional NuttX apps/system built-in command.

Berry is a small embedded scripting language written in ANSI C99. It includes a one-pass compiler, register-based VM, garbage collection, file support, and useful standard modules, while keeping a microcontroller-friendly footprint.

I have a working prototype integrated as a normal NSH command:

berry hello.be
berry /scripts/blink.be

The integration is intentionally small:

• New app lives under apps/system/berry
• Kconfig exposes CONFIG_SYSTEM_BERRY
• Make.defs adds it to CONFIGURED_APPS
• Makefile compiles upstream Berry src/*.c
• It also builds the default module table, default stdio/file port, and default/berry.c as the command entry point
• The default Berry stdio/file port maps cleanly onto NuttX libc APIs, so very little NuttX-specific glue was needed

Current prototype config:

CONFIG_SYSTEM_BERRY=y
CONFIG_SYSTEM_BERRY_PROGNAME="berry"
CONFIG_SYSTEM_BERRY_PRIORITY=100
CONFIG_SYSTEM_BERRY_STACKSIZE=12288

Measured on an ESP32-C3 NuttX image, the current prototype contributes roughly:

• 147,506 bytes text in Berry members in libapps.a
• 0 data
• 1,004 bytes BSS
• 148,510 bytes total before final link placement
• About 106,590 bytes of Berry-like symbols visible in the final ELF
• 12 KB configured task stack, chosen conservatively
• Static RAM cost is tiny: about 1 KB BSS, plus whatever heap the script actually uses

The motivation is to give NuttX a compact “write a small script on-device and run it now” capability without requiring a Python-class runtime. Python is excellent, but on smaller NuttX boards it is a much larger commitment. Berry seems to hit a useful embedded middle ground between NSH scripts and large dynamic runtimes: a real language with compiler, VM, GC, modules, file I/O, and shell integration, but with a much smaller footprint and a simple porting surface.

Potential use cases:

• Board bring-up scripts
• Hardware demos
• Test loops
• Small automation tasks
• User-editable behavior on constrained devices
• Simple scripts stored on /data, /scripts, SD card, etc.

Before preparing this as a cleaned-up PR, I wanted to ask:

1. Would this be something NuttX maintainers are interested in accepting as an optional apps/system/berry feature?
2. Would you prefer this to live under apps/system, or somewhere else in nuttx-apps?
3. Are there specific expectations for importing/updating third-party embedded runtimes that I should follow before submitting the PR?

If there is interest, I can prepare the PR with the Kconfig/Makefile integration, documentation, and a simple usage example.

Describe the solution you'd like

All of this as been discussed above.

Describe alternatives you've considered

No response

Verification

• I have verified before submitting the report.

[xiaoxiang781216]

@speccy88 it's a great feature, could you move the porting to apps/interpreters?

[speccy88]

@speccy88 it's a great feature, could you move the porting to apps/interpreters?

apache/nuttx-apps#3564

Can you tell me if this is how you want it? Or suggest any changes. Let me know what you think if you try it.

Thanks.