MMIO++

Verification story

The repository tests the public API in layers. Host builds validate shape and misuse rejection. Target builds validate the same API against real MMIO addresses under emulation.

Host-side checks

  • Positive host tests compile the intended API shapes.
  • Negative compile-fail tests lock down cross-register misuse and mask/value confusion.
  • The CI workflow runs the same direct local command: cmake --workflow --preset host-test.

Target-side checks

  • Cortex-M QEMU tests execute runtime register behavior at target addresses.
  • Cortex-R5 runtime tests run through the same direct preset flow as the Cortex-M path.
  • The CI workflow uses the same direct preset commands for both target paths.

Direct commands

cmake --workflow --preset host-test
cmake --workflow --preset qemu-m3-test
cmake --workflow --preset qemu-r5-test

The GitHub Actions workflow is intentionally thin. It calls the same preset entry points used on a local Windows setup instead of reimplementing the build graph in YAML.

Why this matters for MMIO code

Register libraries are easy to make look correct in a desktop-only shim. This repo explicitly keeps the host path focused on API shape while relying on target execution for runtime MMIO behavior.

That split keeps the framework honest: compile-time rules remain strict, and real-address execution is exercised under an actual target emulator instead of a hidden host-side memory substitute.