213 add settings partition to store key value pair#240
Open
213 add settings partition to store key value pair#240
Conversation
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>
…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)
45f8225 to
b5b9291
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add persistent key-value parameter storage using FlashDB, enabling motion control parameters to survive reboots without manual reconfiguration.
Flash storage backend
FlashKVStorage) with mutex-based thread safety and typedstore<T>/load<T>templatessettingsFAL partition on both boardspf-commonso all applications get persistence automaticallyParameter policy system
WithFlashStorage<KeyHash>policy that persists values to flash on commit and restores them on init, using FNV-1a hashed keyson_commit/on_initpolicy trait detection with fold expressions inPolicyTraits.hppon_pb_read/on_pb_copyprotobuf conversion hooks with two concrete policies:SpeedConversion(units/s ↔ units/period) andAccelerationConversion(units/s² ↔ units/period²)load()toParameterBasefor runtime reload without knowing the concrete typeMotion control platform
Parameter<>declarations, key hashes, and policy composition inmotion_control_parameters.hpp— robot config headers now only provideconstexprdefaultsWithFlashStorageto all non-read-only parameters (PID gains, pose thresholds)PidEnumand related typesExample
parameter_demoto exercise flash store/load/delete with theWithFlashStoragepolicy