Skip to content

213 add settings partition to store key value pair#240

Open
mlecriva wants to merge 11 commits intomasterfrom
213-add-settings-partition-to-store-key-value-pair
Open

213 add settings partition to store key value pair#240
mlecriva wants to merge 11 commits intomasterfrom
213-add-settings-partition-to-store-key-value-pair

Conversation

@mlecriva
Copy link
Copy Markdown
Contributor

Summary

Add persistent key-value parameter storage using FlashDB, enabling motion control parameters to survive reboots without manual reconfiguration.

Flash storage backend

  • Integrate FlashDB KVDB as a singleton (FlashKVStorage) with mutex-based thread safety and typed store<T>/load<T> templates
  • Configure MTD backends for both cogip-board (STM32 internal flash, last 8 pages / 16 KB) and cogip-native (RAM-emulated)
  • Define a settings FAL partition on both boards
  • Initialize the flash KV backend in pf-common so all applications get persistence automatically

Parameter policy system

  • Add WithFlashStorage<KeyHash> policy that persists values to flash on commit and restores them on init, using FNV-1a hashed keys
  • Introduce on_commit / on_init policy trait detection with fold expressions in PolicyTraits.hpp
  • Add on_pb_read / on_pb_copy protobuf conversion hooks with two concrete policies: SpeedConversion (units/s ↔ units/period) and AccelerationConversion (units/s² ↔ units/period²)
  • Add virtual load() to ParameterBase for runtime reload without knowing the concrete type

Motion control platform

  • Centralize all Parameter<> declarations, key hashes, and policy composition in motion_control_parameters.hpp — robot config headers now only provide constexpr defaults
  • Attach WithFlashStorage to all non-read-only parameters (PID gains, pose thresholds)
  • Register quadpid and tracker chain PID gains in the CAN protobuf registry (fixes previous incorrect mapping)
  • Add speed/acceleration limit and pose threshold parameters with transparent unit conversion at the protobuf boundary
  • Load persisted values at platform init before motors and controllers start
  • Remove unused PidEnum and related types

Example

  • Extend parameter_demo to exercise flash store/load/delete with the WithFlashStorage policy

Add FlashDB Key-Value database support to cogip-board and cogip-native:
- Enable flashdb_kvdb and flashdb_mtd modules in both boards
- Configure MTD backend (mtd_flashpage for STM32, mtd_emulated for
native)
- Define FAL partition "settings" with 16KB storage capacity
- Create dedicated mtd_conf.h header for MTD configuration
- Add periph_flashpage feature for cogip-board

This enables persistent key-value storage for robot configuration data
using the last 8 pages (16KB) of internal flash on STM32G474RE, and
RAM-emulated storage for native board testing.

Signed-off-by: Mathis Lécrivain <lecrivain.mathis@gmail.com>
@mlecriva mlecriva requested a review from gdoffe March 24, 2026 15:49
@mlecriva mlecriva self-assigned this Mar 24, 2026
@mlecriva mlecriva linked an issue Mar 24, 2026 that may be closed by this pull request
mlecriva added 10 commits March 24, 2026 20:17
…value storage

- Singleton FlashKVStorage wraps FlashDB KVDB for blob-level
  get/set/del operations keyed by 32-bit parameter hashes
- Typed store<T>/load<T> templates with static_assert on
  trivially copyable types to avoid manual casts and sizeof
- Mutex-based thread safety via FlashDB lock/unlock callbacks
- Build-time #error assertions enforce FAL_MTD, FAL_PART0_LABEL,
  and FAL_PART0_LENGTH are defined
- All operations return int (0 success, negative on error)
  following RIOT-OS convention
- Add WithFlashStorage<KeyHash> policy that persists parameter values
  to flash via FlashKVStorage singleton using FNV-1a hashed keys
- Introduce on_commit / on_init policy trait detection and fold
  expressions in PolicyTraits.hpp so the Parameter template can
  transparently call storage hooks after validation
- Add virtual load() to ParameterBase interface to allow runtime
  reload of persisted values without knowing the concrete type
- Parameter::set() now fires combined_on_commit after successful
  validation, and load() delegates to combined_on_init for
  first-load-wins semantics across policies
…hStorage policy

- Add flash_kv_storage and printf_float module dependencies
- Apply WithFlashStorage policy to max_angular_velocity parameter
  to showcase persistent storage across reboots
- Initialize FlashKVStorage and reload saved values at startup
- Add dedicated demo section exercising flash store/load/delete
  and out-of-bounds rejection with persistence
- All applications sharing pf-common now automatically initialize
  the flash key-value backend, enabling parameter persistence
  via the WithFlashStorage policy
- Init failure is propagated as an error code to the caller
…key hashes

- robot*_conf.hpp now only provide constexpr float defaults,
  no longer declare Parameter<> objects directly
- motion_control_parameters.hpp owns all Parameter<> declarations,
  key hashes, and is the single point for defining policies
- Ensures all motion control parameters use the same policies
  regardless of which robot config is selected at build time
- Integral limits use constexpr ternary guards to handle
  division-by-zero when ki defaults to 0
- Remove redundant app_conf.hpp includes from platform files
  since motion_control.hpp now includes it transitively
…r loading

- WithFlashStorage policy added to all non-ReadOnly parameters
  to persist tuned values across reboots
- Registry now includes both quadpid and tracker chain PID gains,
  fixing previous mapping where quadpid keys pointed to tracker
- pf_load_parameters() iterates the registry at init to restore
  persisted values before motors and controllers start
- 200ms delay between flash reads for stability
…tion

Motion control internally works in per-period units (mm/period,
deg/period²) but users need to configure parameters in physical
units (mm/s, deg/s²) via the protobuf remote interface.

Rather than converting throughout the motion control stack or
creating a separate parameter wrapper, this adds two new policy
hooks at the protobuf serialization boundary:

- on_pb_read: converts user units to internal units on write
- on_pb_copy: converts internal units to user units on read

This keeps set()/get() in system units for zero-overhead internal
use, while the remote interface transparently presents physical
units.

Two conversion policies are provided:
- SpeedConversion<PeriodMs>: /s <-> /period
- AccelerationConversion<PeriodMs>: /s² <-> /period²

Both enforce float-only usage via static_assert to prevent
silent precision loss on integer parameter types.
… types

- Remove pid_id_t typedef, PidEnum enum class, and PID_COUNT
  compile-time counter from motion_control.hpp
- These declarations have no remaining C++ consumers; PID
  identification is handled via protobuf definitions
…s with unit conversion

Users need to tune speed limits, acceleration/deceleration and
pose thresholds at runtime via the protobuf remote interface in
human-readable units (mm/s, deg/s, mm/s², deg/s²), while the
motion control internals must keep operating in per-period units.

- Add new Parameter objects: pose thresholds (mm/deg),
  speed limits and acceleration limits
- Apply SpeedConversion and AccelerationConversion policies so
  protobuf read/write transparently converts /s <-> /period
- Move X_SEC_TO_X_PERIOD macros, motion_control_thread_period_ms
  and all platform_* constexpr into motion_control_parameters.hpp
  to break the circular dependency that prevented declaring
  conversion-aware Parameters in the parameter header
- Register all new parameters in the canpb registry
- On STM32G4, pwm_init() iterates all 4 entries in pwm_config[].chan[]
  and stops only when pin == GPIO_UNDEF (0xffffffff)
- Only 2 channels were defined; the remaining 2 had pin=0 (C static
  init), causing gpio_init() to write to PA0 (GPIOA->MODER/PUPDR)
- This set sticky PGSERR (bit 7) + PGAERR (bit 5) in FLASH->SR (0xA0),
  making all subsequent flash writes silently fail
- Complements the defensive SR clearing in flash_common.c (8b3e3f48d9)
@mlecriva mlecriva force-pushed the 213-add-settings-partition-to-store-key-value-pair branch from 45f8225 to b5b9291 Compare March 24, 2026 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add settings partition to store key value pair

1 participant