# 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.