Oberon RTK

Astrobe

CFB Software’s cross-compiling Oberon IDE.

Updated: 2024-11-17

Overview

Running code on two cores requires the segmentation of the memory space. At minimum, each core requires its own stack memory. With the RP2350, further segmentation will be required to run both Secure and Non-Secure code, but that’s a topic for another day. For now, we need configurations for the RP2040, and for the RP2350 in Secure, privileged mode to get off the ground.

As of November 2024, the Astrobe IDEs don’t have support for dual-core programs. Oberon RTK employs a module Config to complement the Astrobe settings regarding memory partitioning.1

The basic concepts are, for both MCUs:

  • allocate a part of SRAM to each core
    • stack
    • heap
    • vector table
  • share code among the cores in the flash memory
  • allocate the module variables at the top of the memory space allocated to core 0

Heap and vector tables could basically be in a space shared by the cores, but this would require certain mutual synchronisation measures.

Memory Configuration

The following modules lists the memory settings for the respective Astrobe IDE in the file header, and provide a memory map:

The Astrobe memory settings are also part of the config .ini files, see below.

Search Path Configuration

Oberon RTK uses Astrobe’s modules MUA, LinkOptions, ResData, Error, and FPU (plus file boot2.bin for Astrobe for RP2040), so make sure they are on your library search path for the compiler and linker.

See section Directory Structure, below.

Oberon RTK v2

For Oberon RTK v2, please refer to the following Astrobe configuration files in the oberon-rtk repository:

Note: since we have no module naming overlap between modules for the “no kernel” and “kernel-v1” situation, programs not using the kernel can be built using the “kernel-v1” variant of the config files. The “-base” variants will therefore be removed in a future update.

Oberon RTK v1

For Oberon RTK v1, please refer to the following Astrobe configuration files:

Directory Structure

The above config .ini files are based on the installation and work directory structure described below. I never put any own code into the Astrobe library installation directories, which I keep pristine and only ever change with new releases of Astrobe.2

(...)/astrobe-mx/m0: Astrobe for Cortex-M0
      + Configs
      + Examples
      + Lib
(...)/astrobe-mx/m3: Astrobe for Cortex-M3
      + Configs
      + Examples
      + Lib
(...)/astrobe-mx/m4: Astrobe for Cortex-M4
      + Configs
      + Examples
      + Lib
(...)/astrobe-mx/rp2040: Astrobe for RP2040
      + Configs
      + Examples
      + Lib
(...)/oberon-rtk
      + config
      + examples
      + lib
      + libv2
      + tools
The Astrobe installation location shortcuts %AstrobeM0%, %AstrobeM3%, %AstrobeM4%, and %AstrobeRP2040% point to (...) in the above outline.

Documented Limitations

  • Astrobe forums: Bug Reports
  • Astrobe release notes, section Known Problems (or similar, if any)

Known Limitations

  • No dual-core support.
  • If you use several Astrobe IDEs, and have modules that are shared between targets and maybe open in different IDEs, be aware that the Astrobe editor does not detect any changes made in a different tool. It’s easy to overwrite and lose changes if not careful. Same in case you use a different editor, eg. for a side-by-side display of modules (I often use VisualStudio Code for this purpose, even though it’s an Electron abomination). I certainly have lost work this way, which, yes, is a layer eight problem, or less euphemistically, my stupidity. Just be aware.

  1. Conceptually, it’s not “clean” to have data defining memory partitioning and code loading locations inside the program code, as with module Config. But it’s the best that can be done for the moment. ↩︎

  2. I also keep the Astrobe libraries in a (local) git repository, so any changes are easily “browsable” after upgrading to a new Astrobe release. ↩︎

Oberon RTK – Oberon Real-Time Kernel
by gray ©  2020 – 2024