The switch to C++

The short version

RPCortex is being rewritten in C++, running natively on the hardware with no interpreter underneath. It is the same operating system — the same shell, the same commands, the same accounts, the same package system. The goal is that you open PuTTY and cannot tell the codebase changed, except that everything is faster and the memory ceiling you kept running into is gone.

Why

Most of the hard bugs in the last year were the same bug wearing different hats: not enough memory, in a way that was difficult to see and harder to fix.

The clearest example shipped in v1.0. HTTPS would stop working on a device that had been running a while, and the reason was not that memory had run out — a board would report 52 KB free and still fail. A TLS handshake needs one unbroken block of about 16.9 KB, and MicroPython's collector never moves anything, so once the heap is carved up there is no way to make a run that large again. The fix works, and it is a good fix, but it is a fix for a problem that only exists because of how the runtime manages memory.

The same shape turned up everywhere. Package installs that failed on large archives. Commands that could not be loaded when the heap was fragmented. A whole board — the original Pico and Pico W, with 264 KB of RAM — that had to be dropped from v1.0 because the multitasking build simply would not fit.

Underneath all of it, an interpreter was doing work that a microcontroller cannot really spare: parsing, allocating, tracing, collecting. Removing it removes the category.

What stays the same

This is a rewrite of the implementation, not a redesign of the product. Deliberately:

• The shell — the same prompt, the same commands, the same second spellings (ll, dir, more, del, free), the same pipes and && / || chaining and redirection.
• The look — the boot banner, the colours, the [@] and [!] status lines, the column layout of ls. These were reproduced against the v1 source rather than rebuilt from memory.
• The accounts system — salted hashes, admin roles, the protected root and guest accounts, the guided first-run setup.
• The filesystem — the same littlefs version and on-disk format a v1 device already uses.
• The package system — see below, because this was the part that had to be proven before anything else could start.

What gets better

• Speed. Native code, direct hardware access, no bytecode in between.
• Memory. No garbage collector, so no collector pauses and no fragmentation problem of the kind that broke HTTPS. Memory that is free is memory you can actually use.
• The Pico 1 and 1 W come back. Without an interpreter, 264 KB stops being the wall it was.
• Real OTA updates. The RP2350's boot ROM has A/B flash slots and rollback built in — a failed update returns to the working image by itself.
• USB. HID, BadUSB and U2F need native USB device support, which was never reachable before.
• Installing is simpler. Hold BOOTSEL, plug in, drag one file across. No firmware step, no file-pasting step.

Packages still work — this was the deciding question

The obvious objection to dropping an interpreter is that you lose the thing an interpreter gives you: the ability to load and run code that was not compiled into the firmware. An OS without a package system is a much smaller idea, and it was genuinely unclear whether this was possible.

It is. A package is a compiled object file, loaded from the filesystem at runtime, relocated in RAM, resolved against a firmware symbol table, and run — then unloaded cleanly, with its commands removed from the shell and its memory returned. It costs about 3.3 KB of flash and no static RAM. This was built and proven first, before any of the rest, because a "no" there would have ended the whole idea.

So packages still install, still register shell commands, still update independently of the OS. They are compiled ahead of time instead of shipped as source.

What happens to v1.0

It stays. v1.0 is the current stable release, it is what the installer gives you, and it is what update online moves you to. It will keep working on the devices it works on today.

What ends is new feature development on the MicroPython line. The v1 source is not going anywhere — it is archived and readable, and the packages in the repository continue to work with it.

Where it stands

Further along than "planned". Working today, tested on the host and building for both the RP2350 and the RP2040:

• The package loader, with clean load / run / unload.
• The shell — around 50 commands plus v1's aliases, with pipes, chaining, redirection and quoting.
• Line editing — cursor and word movement, history, Tab completion over commands and paths.
• Accounts, the registry, the filesystem, WiFi.
• The console: v1's output layer, checked byte for byte against the original escape sequences.

Still to come: the package repository, the rest of the command set (ping, ntp, wget, the editor), OTA updates, USB HID, and the Nova D1 port. The roadmap tracks it.

When

When it is genuinely better than v1.0, and not before. Shipping a rewrite that is merely equivalent would be asking people to take a risk for nothing.

If you want to follow along or argue with any of this, the Discord is the place.