Project

Status and Current Work

• Status as of May 2025 (lib/v2.0):

  • most library modules have been ported to support both the RP2040 and RP2350;
  • a set of example programs has been ported to run on both MCUs;
  • the transmogrification and upload tool has now been rewritten from the ground up.

• Current work (lib/v2.1-dev):

  • Autonomous error recovery.

Note: the current stage of the work for the RP2350 focuses on running software in the Secure domain in privileged mode, with the extensions for also using the Non-secure realm possibly coming later. This also depends on the corresponding forthcoming features by the Astrobe compiler for the RP2350. As far as the capabilities of the two MCUs overlap, running in Secure privileged mode on the RP2350 corresponds to running on the RP2040.

Background and Context

N. Wirth wrote:

The belief that complex systems require armies of designers and programmers is wrong. A system that is not understood in its entirety, or at least to a significant degree of detail by a single individual, should probably not be built.¹

Oberon RTK is not a competitor for the official SDK for the Pico and Pico 2. It’s way simpler. By design. A single person is able to understand Oberon RTK in its entirety.²

Oberon RTK loosely attempts to follow ideas and basic concepts first implemented in the Apollo Guidance Computer³ – a control system that enabled a spacecraft to navigate through featureless empty space to a celestial body some 400,000 km away, land on it, take off, and return. With close to no computing power available, compared to today’s MCUs, they must have gotten the essentials right. At its core: a simple multi-threading kernel using cooperative scheduling.

Furthermore, the concepts of Oberon RTK are influenced by architecting and implementing industrial control systems, also – you guessed it – using a multi-threading kernel with cooperative scheduling.

Short History

In December 2023, the RP2040 attracted my attention due to its dual-core architecture. It’s also a simple, but well-structured micro-controller. For some time, I had wanted to dabble with a multi-core architecture, from the ground up, ie. for control programs running on the bare metal.⁴

Astrobe did not support the RP2040 at this time, but Astrobe for Cortex-M0 could be used to generate the code. I just needed to write a tool to create the UF2 files needed to the RP2040, and was off to the races. Thus Oberon RTK with lib/v1.0 was born in January 2024, solely focused on the RP2040.

Of course I could not pass up on the RP2040’s more powerful sibling, the RP2350, which became available by mid 2024. Astrobe for Cortex-M4 could be used for code generation, since the RP2350 was not supported directly yet. Hence, lib/v2.0 was initiated, accompanied by an extended UF2 tool for the peculiarities of the RP2350. Supporting two MCUs necessitated a restructuring of the framework, which explains the structural differences between lib/v1.0 and lib/v2.0. Unfortunate, but necessary.

Contact

You can contact me via e-mail: gray@grayraven.org. No, I don’t have either an X/Twitter nor a Facebook account. I value my peace of mind.