Skip to content

v2.1.0 — RC Server lifecycle & register-map model

Choose a tag to compare

View all tags
@SoundMatt SoundMatt released this 28 Jul 15:58
· 133 commits to main since this release
v2.1.0
6b67a4a
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

v2.1.0 — RC Server lifecycle & register-map model (Phase 13 milestone 45)

Second milestone of the full OPEN Alliance TC18 Remote Control Protocol replacement (see ROADMAP.md), building directly on v2.0.0's wire codec.

What changed

  • New rcp/lifecycle.hpp:
    • The 3-state RC Server lifecycle machine — HW_UNCONFIGURED (0x00), HW_CONFIGURED (0x55), RCP_CONFIGURED (0xAA)
    • Forward-only, single-step advance() transitions (no skipping, no going backward except via explicit deconfigure())
    • The HW_CFG_INCONSISTENT/RCP_CFG_INCONSISTENT plausibility checks gating each transition
    • Independent generic/functional config-block locking, tied to lifecycle state
  • New rcp/regmap.hpp:
    • The generic (server-owned, pin-mapping/queue-size) vs. functional (endpoint-type-specific) config split — a hard prerequisite every endpoint milestone from v2.3.0 onward depends on
    • General bootstrap register fields: magic number, protocol version, vendor/device ID, endpoint count, stream/queue capacity, svr_implemented_options, and pointer/capacity fields for the five bootstrap tables
    • HW pin-mapping config, request-stream config (including the rx_wd_*/rx_safety_measure fields — present now, wired up for real at v2.6.0), the EP-ID/byte_bus_id mapping table (client-ordering risk flagged explicitly in comments, not server-enforced), and response/ack queue config
    • Persistent 8-bit sequencer-state storage (used starting v2.5.0)
    • Ep0 — the RC Server acting as a pseudo-endpoint: whole-register-map read (unrestricted) and write (root-client-only via claim_root_client/svr_root_client_index), plus per-endpoint write restriction for every other client
    • The four mandatory register-map error codes as rcp::regmap::RegMapErrc: UNAUTHORIZED_ACCESS, LOCKED_MEM_ACCESS, REQUEST_REJECTED, INVALID_PARAMETER
  • New REQ-LIFECYCLE-001..006 and REQ-REGMAP-001..014 requirements (.fusa-reqs.json), tested in tests/test_lifecycle.cpp and tests/test_regmap.cpp.
  • rcp/rcp.hpp's pre-replacement Zone/Command/Controller/Registry model is unchanged in behavior — its header comment now points at the new replacement headers — since roughly three dozen other headers still build against it and aren't rebound until their own later milestones (v2.9.0 onward per the Release Plan).

Scope note

Per ROADMAP.md, this milestone is the lifecycle/register-map foundation only: no discovery, endpoint types, conditional requests, or E2E safe-state behavior is included (those are v2.2.0+). Field widths, the register-map magic-number value, and the locking policy are this implementation's own design choices for realizing the described behavior; no discovery mechanism or endpoint type exists yet to exercise the register map end-to-end over the wire.

Verification

44/44 ctest suites pass (clang, Debug/Release, C++17/C++20); all 20 CI checks green (full build matrix across Linux/macOS/Windows × clang/gcc/msvc, clang-tidy, coverage, relay conform, and the full cpp-FuSa safety/security/traceability lifecycle including 100% requirement coverage).

Full diff: v2.0.0...v2.1.0

Assets 2
Loading