K14 — Software timer and the timer daemon task

K14 implements a freestanding, non-copyable C++ SoftwareTimer wrapper over statically allocated FreeRTOS timers. OneShotTimer and PeriodicTimer encode the reload policy in the type. The constructor creates the timer, while start, reset, change_period and stop remain explicit commands sent to the timer daemon.

The target experiment starts both timers before the scheduler:

command acceptance snapshot: callbacks = 0
periodic initial period 2:    ticks 2, 4
one-shot reset at tick 1:     callback at tick 6, then inactive
periodic change at tick 4:    next callback at tick 7
periodic stop:                inactive, no fourth callback

The callback checks that its current task is xTimerGetTimerDaemonTaskHandle() and that the task name begins with Tmr S. It also records a stack pointer different from the verifier task. Timer control blocks, verifier TCB and stacks live in .bss; creating both timers leaves the heap unchanged.

Build

make check

This runs a host policy test, ABI/storage checks and the deterministic Hazard3 simulation.

Debug

riscv64-unknown-elf-gdb build/task01_sw_timer/prog.elf
b software_timer_debug_checkpoint
p g_start_commands_accepted
p g_callbacks_when_start_returned
p g_reset_tick
p g_change_tick
p g_one_shot_tick
p g_periodic_ticks
p g_daemon_handle_match
p g_daemon_name_match
p g_timer_pass

Lifetime boundary

The timer ID stores a pointer to the typed callback context. Therefore the StaticTimer_t storage, wrapper and context must remain alive while a command or callback can still be pending. A successful API return proves queue acceptance, not callback completion. Timer callbacks execute in the shared daemon task and must not block.