Step 08 of 13

Choosing a runtime profile

Three runtimes ship here, from a lean Jorvik kernel to the complete Ada tasking model. Picking one is a build-time switch, and most projects want the middle option.

The three

Profile	Tasking model	What you get
`light-tasking`	Jorvik (Ravenscar+)	Periodic tasks, protected objects, SMP. No exception propagation, no heap. The lean default.
`embedded`	Jorvik + ZCX	Adds full exception propagation with names, controlled-type finalization, and a heap. The usual choice — the HAL's RAII handles need it.
`full`	Complete GNARL	Lifts the Jorvik restrictions: rendezvous, selective `accept`, dynamic and nested tasks, dynamic priorities, `abort`, dynamic `Ada.Interrupts`.

light-tasking and embedded both set pragma Profile (Jorvik); full is the unrestricted runtime.

Selecting one

Per build, from the dispatcher — auto (the default) uses whatever the example itself declares:

./x run esp32s3_heartbeat --profile embedded -p /dev/ttyACM0
./x build esp32s3_heartbeat -P full

Or permanently, for one project, by setting ESP32S3_RTS_PROFILE in its build.sh. A freshly scaffolded project already contains that line, set to embedded:

export ESP32S3_RTS_PROFILE=embedded

./x list shows every example alongside the profile it was written for.

Which to pick

Start with embedded unless you have a reason not to. Named exceptions and finalization are worth their cost while you are learning the board, and the HAL's RAII driver handles assume them.

Drop to light-tasking when you want the smallest image and can live inside Jorvik: periodic tasks and protected objects with no heap and no exception propagation. Move up to full only when you specifically need rendezvous, dynamically created tasks, or abort.

Changing profile means regenerating a runtime, so the first build under a new profile is slow again. That is expected, not a fault.

All three are exercised against the ACATS 4.2 conformance suite on real hardware, with zero genuine failures on every profile. What remains non-passing is interactive tests, library units the bare runtime omits, correct NOT-APPLICABLE results, or documented limitations — the book's ACATS chapter has the breakdown.