New feature

[wdfk-prog]

refactor(core): Abstract parameter manager atomic operations

Why to submit this PR

Currently, the autogen_parameter_manager in par.c directly depends on <stdatomic.h> and the C11 atomic interfaces, including atomic_load_explicit, atomic_store_explicit, atomic_fetch_and_explicit, and atomic_fetch_or_explicit.

Although this implementation can function properly, it also has several issues:

1. The parameter management module is directly coupled to the C11 atomic interfaces, which is not conducive to porting to toolchains or platforms that do not fully support stdatomic.h.
2. The atomic types and operations are scattered in the business code, reducing maintainability.
3. The atomic read and write operations for floating - point types use GCC/Clang built - in primitives to bypass the limitations, and the relevant logic is mixed in the business files, which is not conducive to unified management.
4. There is a lack of a clear backend switching mechanism, making it difficult to conveniently access the platform's custom atomic implementation.

Therefore, this PR is submitted to abstract and encapsulate the atomic operations of the parameter management module, enabling it to support two implementation methods: the C11 backend and the port backend, and reducing the direct dependence of the business code on the underlying atomic implementation details.

What is your solution

This PR mainly makes the following adjustments:

1. Create a new par_atomic.h under Third_Party/autogen_parameter_manager/parameters/src/ as the unified abstract header file for atomic operations in the parameter management module.
2. Remove the direct dependence on <stdatomic.h> in par.c and replace it with including par_atomic.h.
3. Modify the type of the parameter value storage array from directly using _Atomic to the abstracted type aliases, including:
   • par_atomic_u8_t
   • par_atomic_i8_t
   • par_atomic_u16_t
   • par_atomic_i16_t
   • par_atomic_u32_t
   • par_atomic_i32_t
   • par_atomic_f32_t
4. Replace the private macros related to parameter access with abstract interfaces:
   • PAR_ATOMIC_LOAD
   • PAR_ATOMIC_STORE
   • PAR_ATOMIC_FETCH_AND
   • PAR_ATOMIC_FETCH_OR
5. Add an atomic backend selection mechanism in par_atomic.h:
   • PAR_ATOMIC_BACKEND_C11
   • PAR_ATOMIC_BACKEND_PORT
   • By default, PAR_ATOMIC_BACKEND_C11 is used.
6. For the C11 backend, uniformly encapsulate various atomic types and operations in par_atomic.h:
   • Load/store operations for integer types
   • Load/store operations for the floating - point type f32
   • Fetch - and/fetch - or operations for unsigned integer types
7. For atomic read and write operations of floating - point types, retain the use of __atomic_load / __atomic_store, but migrate this part of the implementation from the business code to the unified abstraction layer to reduce the internal complexity of par.c.
8. Reserve the support capability for the port backend:
   • When PAR_ATOMIC_BACKEND_PORT is selected, include par_atomic_port.h
   • Facilitate subsequent customized atomic implementation provided by specific platforms

Through these adjustments, the business logic of the parameter management module is decoupled from the underlying atomic mechanism, the code structure becomes clearer, and better scalability and maintainability are provided for the adaptation of different compilers and platforms.

Provide the config and bsp

• BSP:

  • Please fill in the verified BSP path, for example, bsp/stm32/stm32l496 - st - nucleo.

• .config:

  • Please fill in the configuration items used to verify this module.
  • If the parameter management component is involved, please supplement the relevant component enabling configuration.

• action:

  • Please fill in the CI/Action link triggered by the PR branch in your own repository.

  feat(parameter): Add parameter value change detection function

  A parameter value change detection function, par_is_value_changed, protected by the conditional compilation macro PAR_CFG_NVM_EN, has been added. This function is used to determine whether the parameter value has changed. Meanwhile, this function has been integrated into the par_check_table_validy function, and corresponding preprocessing directives for inclusion control have been added.

parameters/src/par.c:292:13: warning: 'par_is_value_changed' defined but not used [-Wunused-function]
  292 | static bool par_is_value_changed(const par_num_t par_num, const void * p_val)
      |             ^~~~~~~~~~~~~~~~~~~~

perf(core): Optimize parameter ID lookup with hash map

Why to submit this PR
When the current parameter management module searches for parameters by using the id, it usually needs to traverse the entire parameter configuration table and convert the external parameter ID into the internal par_num.
This linear search method will result in higher search overhead when the number of parameters increases, and it will also affect the access efficiency in the following scenarios:

• CLI parameter access
• Upper computer tool reading and writing parameters
• Communication protocol accessing parameters by ID
• Parameter import and export
• Diagnostic and log system
  Furthermore, the current implementation fails to clearly convey the design intention of the parameter ID, the distinction between par_num and id, and lacks a systematic explanation for the ID lookup mechanism, which makes it difficult for future maintenance and external integration.
  Therefore, this PR is submitted to add an ID lookup mechanism based on a hash table to the parameter module, and to supplement the relevant design documentation for explanation.
  What is your solution?
  This PR mainly made the following adjustments:
  In README.md, add a parameter identification design description to clearly distinguish:
• par_num: Internal parameter index, used for efficient internal access within the firmware;
• id: External parameter identifier, used for external access via CLI, upper-level machine tools, communication protocols, etc.

2. Add a description of the ID lookup design based on hash table in README.md, including:

• Why to use hash table;
• The advantages compared to linear search;
• The trade-offs compared to the binary search scheme;
• The collision resolution strategy and the ID allocation suggestion;

3. Add the definition related to ID hash to par.c: - PAR_ID_HASH_GOLDEN_RATIO_32

• PAR_ID_HASH_MIN_BUCKETS
• PAR_ID_HASH_BITS
• PAR_ID_HASH_SIZE

4. New runtime ID hash table data structure: - par_id_map_entry_t

• g_par_id_map[]
• gb_par_id_map_ready

5. A new function par_hash_id() has been added, which is used to map parameter IDs to fixed bucket indexes;
6. A new function par_build_and_validate_id_map() has been added. During the initialization stage, it performs the following tasks:

• Traverses the parameter table;
• Builds the mapping of ID -> par_num;
• Checks for duplicate IDs;
• Checks for hash conflicts;
• If any issues are found, it returns an initialization error and outputs debugging information.

7. Adjust par_check_table_validy():

• Remove the previous method of checking duplicate IDs through a double loop;
• Change it to directly build and validate the hash mapping table during initialization;

8. Add hash table state management in par_init() and par_deinit():

• Set gb_par_id_map_ready = true after successful initialization
• Clear this state during deinitialization

9. Optimization of par_get_num_by_id():

• Previously, it searched the entire parameter table to find the matching ID;
• Now, it directly looks up the corresponding par_num using a hash bucket;
• If the hash table is ready and the bucket match is successful, the result is returned directly.
  Through the above adjustments, the runtime overhead of the parameter module for ID-based lookup has been significantly reduced. This is particularly suitable for scenarios where there are a large number of parameters and they are frequently accessed through external IDs. At the same time, the new implementation maintains the characteristics of simple runtime logic and strong determinacy.
  Please provide the verified bsp and config (provide the config and bsp)
• BSP:
  Please enter the verified BSP path, for example, bsp/stm32/stm32l496-st-nucleo
• .config:
  Please fill in the relevant configuration items used for verifying the parameter management module.
• action:
  Please fill in the link of the CI/Action chain triggered by your own warehouse PR branch.

refactor(core): Convert parameter table to X-Macro definition

Why to submit this PR
Currently, the parameter definitions of autogen_parameter_manager are scattered across multiple files and templates, resulting in duplicate maintenance issues among parameter enumerations, parameter tables, and template examples.
This approach has the following drawbacks:

1. There is a duplicate definition between parameter enumeration and parameter table initialization, resulting in high maintenance costs.
2. When the parameter items change, it is prone to multiple inconsistencies in content.
3. For some integer type parameters, the range and default value checks can only rely on runtime assertions, lacking earlier means to expose problems.
4. Some interfaces return const void *, and the type information is not clear enough.
5. There are also some details such as inconsistent naming and spelling in the code.
   Therefore, by submitting this PR, the parameter table is restructured into a single-source X-Macro format, and additional compile-time integer range checks and type-checking interfaces are added, thereby enhancing the maintainability, consistency, and readability of the module.
   What is your solution?
   This PR mainly made the following adjustments:
   Add parameters/src/par_def.h as the core header file for parameter definitions:

• Automatically expand parameter enumerations by including par_table.def;
• Provide the definition of par_num_t;
• Declare the interface for accessing the parameter table;

2. Add parameters/src/par_def.c as the file for parameter table definition implementation:

• Use X-Macro to expand the parameter table based on par_table.def;
• Generate g_par_table[] uniformly;
• Implement par_cfg_get_table(), par_cfg_get(), and par_cfg_get_table_size().

3. New template file parameters/template/par_table.deftmp:

• As a template for a single parameter data source;
• Used to uniformly describe parameter enumerations, IDs, names, ranges, default values, units, access permissions, persistence properties and descriptions;

4. Delete the old template parameter table files:

• Delete template/par_def.ctmp
• Delete template/par_def.htmp
  Converge the original decentralized definition method to the new single-table-driven method;

5. Add a compile-time validation mechanism for integer parameters in par_def.c:

• Perform min < max, def >= min, and def <= max checks for parameters of types U8/U16/U32/I8/I16/I32;
• Keep runtime checks for F32 type to avoid issues where some embedded/old GCC toolchains have unstable handling of static floating-point assertions.

6. In par.c, retain the runtime range check for F32, while removing the runtime range assertion for integer types to avoid redundant checks;
7. Correct the spelling of function names:

• par_check_table_validy() is corrected to par_check_table_validity()

8. Replace par_cfg_t with a named structure: - typedef struct par_cfg_s { ... }
   It is convenient for forward declaration to be used in conjunction with typed interfaces;
9. In par_cfg.h, change the parameter table access interface from const void * to a strongly typed return value: - const par_cfg_t * par_cfg_get_table(void);

• const par_cfg_t * par_cfg_get(const par_num_t par_num);

10. In par.c, simplify the corresponding call synchronously:

• par_get_config() no longer requires explicit type conversion;

11. Adjust the PAR_STATIC_ASSERT macro definition by adding a closing semicolon when expanded, so that the syntax at the calling location becomes more consistent.
    Through the above adjustments, the parameter definition has been changed from multiple repetitive maintenance to a single factual source of par_table.def.
    Parameter enumeration, parameter table initialization, and compile-time verification of integer parameters can all be automatically generated from the same data.
    This can significantly reduce maintenance costs and improve the timing of discovering configuration errors as well as the overall consistency of the code.
    Please provide the verified bsp and config (provide the config and bsp)

• BSP:
  Please enter the verified BSP path, for example, bsp/stm32/stm32l496-st-nucleo
• .config:
• Please fill in the relevant configuration items used for verifying the parameter management module.
• If it involves template generation, parameter table compilation period check, or port configuration, please provide the corresponding configurations.
• action:
  Please fill in the link of the CI/Action chain triggered by your own warehouse PR branch.

feat(core): Make parameter metadata and ID APIs configurable

Why to submit this PR
The current parameter management module by default always includes metadata such as range, name, unit, desc, id, access, and persist, along with corresponding interfaces.
In scenarios where resources are limited or only the minimum functionality set is required, this can result in unnecessary code size, static data usage, and runtime verification overhead.
Therefore, this PR was submitted to add customizable configurations to the parameter management module, enabling different projects to selectively enable or disable relevant metadata and features as needed.
What is your solution?
This PR adds a set of configurable macros to the parameter module, and based on this, it conditionally compiles and trims the struct fields, auxiliary types, validation logic, runtime hash table, and external APIs.
The main changes are as follows:

1. Add optional configuration items in par_cfg.h: - PAR_CFG_ENABLE_RANGE

• PAR_CFG_ENABLE_NAME
• PAR_CFG_ENABLE_UNIT
• PAR_CFG_ENABLE_DESC
• PAR_CFG_ENABLE_ID
• PAR_CFG_ENABLE_ACCESS
• PAR_CFG_ENABLE_PERSIST
• PAR_CFG_ENABLE_DESC_COMMA_CHECK

2. Add configuration dependency check:

• When PAR_CFG_NVM_EN = 1, it requires PAR_CFG_ENABLE_ID = 1
• When PAR_CFG_NVM_EN = 1, it requires PAR_CFG_ENABLE_PERSIST = 1

3. Perform conditional compilation for the following content in par.h: - par_range_t
   Optional fields in par_cfg_t - par_set_by_id / par_get_by_id

• par_get_name / par_get_range / par_get_unit / par_get_desc
• par_get_access / par_is_persistant
• par_get_num_by_id / par_get_id_by_num
• par_save_by_id

4. In par.c, perform configuration-based trimming of the relevant implementations:

• The ID hash table and initialization logic are compiled only when PAR_CFG_ENABLE_ID is enabled.
• The validation logic for names, descriptions, ranges, etc. is executed only when the corresponding functionality is enabled.
• The *_fast write interfaces directly write data when PAR_CFG_ENABLE_RANGE is disabled, and no range checks are performed.

5. In par_def.c, initialize the fields of the parameter table and perform compile-time checks according to the configuration:

• Only retain the static range check for integers when RANGE is enabled
• Change the parameter table initialization to be expanded based on macros, avoiding initialization of fields that are not enabled
  This modification can provide better modularity and portability flexibility for the parameter module while maintaining the default behavior unchanged.
  Please provide the verified bsp and config (provide the config and bsp)
• BSP:
• [Please fill in the actual verification BSP path, for example, bsp/stm32/stm32l496-st-nucleo]
• .config:
• The default configuration has been verified and can be compiled normally.
• It is recommended to add the following combinations for verification: - PAR_CFG_ENABLE_RANGE=0
• PAR_CFG_ENABLE_ID=0
• PAR_CFG_ENABLE_NAME=0
• PAR_CFG_ENABLE_UNIT=0
• PAR_CFG_ENABLE_DESC=0
• PAR_CFG_ENABLE_ACCESS=0
• PAR_CFG_ENABLE_PERSIST=0
• If there is an actual test, please replace it with the actual .config option you are using.
• action:
• [Please fill in the CI/Action link corresponding to the PR branch of your own repository]

feat(core): Add overridable parameter description validation hook

Why to submit this PR
The current validation logic for the parameter description field is hardcoded directly within the module, and only the comma character is prohibited.
Although this implementation can meet the basic constraints of the CSV/CLI toolchain, it lacks flexibility. The application layer cannot expand or replace the validity rules for the description field according to its own needs.
Furthermore, the current configuration item PAR_CFG_ENABLE_DESC_COMMA_CHECK has an overly specific name, which no longer accurately conveys the more general capability of "description validity check".
What is your solution?
This PR has changed the parameter description verification mechanism from the fixed "prohibit commas" rule to an extensible description validity verification hook, and has simultaneously updated the relevant documentation explanations.
The main changes are as follows:

1. Added weak symbol interface par_port_is_desc_valid()

• Provides a default weak implementation;
• The default behavior remains unchanged, still rejecting descriptions containing ,;
• The application layer can override this symbol to implement stricter or different description validation strategies.

2. Change the initialization verification logic of the table items to call par_port_is_desc_valid()

• Previously, it directly used strchr(desc, ',');
• Now, it uniformly determines the validity of the description through the verification interface;
• The error message has been adjusted from "description contains comma" to a more general "description is invalid".

3. Rename configuration macro - PAR_CFG_ENABLE_DESC_COMMA_CHECK

• Adjust to - PAR_CFG_ENABLE_DESC_CHECK

Raise the configuration semantics from "whether to check commas" to "whether to enable description validity check".
4. Update README document

• Explain that the runtime verification is now accomplished through par_port_is_desc_valid();

• Clarify that the default weak implementation only prohibits ,;

• Explain that the application can override this interface to customize the description verification strategy;

• Synchronously correct the document title hierarchy and configuration item descriptions.
  This modification maintains the default compatibility behavior while enhancing the modularity's portability and scalability.
  Please provide the verified bsp and config (provide the config and bsp)

• BSP:
  No specific BSP was involved. The current changes are located in the common module code and documentation of Third_Party/autogen_parameter_manager/parameters.

• .config:

• PAR_CFG_ENABLE_DESC

• PAR_CFG_ENABLE_DESC_CHECK

• action:
  Please fill in the CI/Action link corresponding to your personal branch.

refactor(core): Replace dynamic parameter storage with static layout

Why submit this PR

Currently, the parameter management module dynamically allocates runtime storage space for parameters via malloc during the initialization phase. Meanwhile, it undertakes responsibilities such as parameter grouping statistics, offset calculation, and storage binding within par.c.
This implementation has the following issues:

1. The logic of parameter storage layout and the logic of parameter reading and writing are deeply coupled, which is not conducive to subsequent maintenance and expansion.
2. Dynamic memory allocation increases the risk of memory management in embedded scenarios, which is not conducive to improving predictability and portability.
3. The existing offset table and grouping information lack unified abstraction, making it inconvenient to access the static layout generated by scripts in the future.
   Therefore, this PR is submitted to refactor the parameter storage layout, introduce an independent layout abstraction, and use static storage to replace runtime dynamic allocation.

What is your solution

The main changes in this PR are as follows:

1. Add par_layout.c / par_layout.h to abstract the parameter storage layout capabilities:
   • Provide an interface to access the parameter offset table.
   • Provide an interface to count parameter groups of 8/16/32 bits.
   • Support two layout sources: PAR_CFG_LAYOUT_COMPILE_SCAN and PAR_CFG_LAYOUT_SCRIPT.
2. Remove the original runtime memory allocation logic in par.c:
   • Delete par_allocate_ram_space().
   • Replace it with par_bind_storage_layout().
   • Use static arrays to hold the storage space for 8/16/32-bit parameters respectively to avoid using malloc.
3. Replace the originally locally maintained gu32_par_offset with par_layout_get_offset_table():
   • Retain the original way of accessing by parameter number index.
   • Reduce the scope of changes to the existing read - write macros and fast path.
4. Add the description of the atomic type shared storage contract and compile - time verification:
   • Verify that the size and alignment of u8/i8, u16/i16, u32/i32/f32 are consistent.
   • Ensure the premise of type alias access in the static shared storage mode.
5. Add compile - time parameter type counting logic in par_def.h:
   • Provide compile - time constant support for static storage grouping and layout initialization.
6. Add the following in par_cfg.h:
   • PAR_ALIGNOF abstraction.
   • PAR_CFG_LAYOUT_SOURCE configuration item.
   • PAR_CFG_LAYOUT_STATIC_INCLUDE configuration item.
   • Relevant legality checks.
     Overall, this modification decouples the "layout calculation" and "value access" of the parameter module, and changes the runtime dynamic allocation to static grouped storage, improving the determinacy and maintainability in embedded usage scenarios.

Please provide the verified BSP and config

• BSP:
  • No specific BSP is bound. The current changes are located in the Third_Party/autogen_parameter_manager/parameters general parameter module layer.
  • It is recommended to supplement at least one actual verified BSP, for example:
    • bsp/stm32/stm32l496 - st - nucleo
    • Or the path of the target board you actually used this time.
• .config:
  • This change does not introduce business function switches that must be modified.
  • It is recommended to focus on verifying the following relevant configuration combinations:
    • PAR_CFG_LAYOUT_SOURCE = PAR_CFG_LAYOUT_COMPILE_SCAN
    • PAR_CFG_ENABLE_ID
    • PAR_CFG_ENABLE_PERSIST
    • Atomic backend - related configurations (such as platform - customized atomic wrapper).
• action:
  • Please supplement the link indicating that the CI / Action compilation of your own repository branch has passed.

docs(core): Reorganize parameter module documentation and layout model

Why to submit this PR
There are two types of problems in the current parameter module:

1. The logic related to the storage layout of runtime parameters is concentrated in par.c. The responsibilities for parameter grouping statistics, offset generation, and storage binding are highly coupled, which is not conducive to maintenance and expansion.
2. The module documentation has been long concentrated in a single README.md, with excessive content. This is not only unfavorable for the initial access but also inconvenient for developers to search for the architecture, interfaces, and integration methods by topic.
   Furthermore, the original implementation dynamically allocates the parameter live storage at runtime, which introduces uncertainty in memory usage in embedded scenarios and is not conducive to improving system predictability.
   Therefore, this PR is submitted to conduct a structured organization of the parameter module:

• Introduce an independent parameter layout abstraction at the code level;
• Change the storage layer to static grouped storage;
• Reconstruct the README as an entry page and split out the getting-started / architecture / api-reference and other thematic documents at the documentation level.
  What is your solution?
  This PR mainly accomplished the following tasks:

1. Introduce the abstraction of parameter storage layout
   New addition: - src/par_layout.c

• src/par_layout.h

It is used to uniformly manage the storage layout of parameters, including:

• Grouping and counting the number of 8/16/32-bit parameters by type;
• Providing a mapping from parameters to offsets within the group;
• Supporting two layout sources: - PAR_CFG_LAYOUT_COMPILE_SCAN
• PAR_CFG_LAYOUT_SCRIPT

This separates the layout responsibilities that were originally scattered in par.c into a separate module, thereby reducing the coupling degree.
2. Replace runtime dynamic allocation with static grouping storage
In par.c:

• Remove par_allocate_ram_space()
• Replace it with par_bind_storage_layout()
• Use static typed storage: - gs_par_u8_storage
• gs_par_u16_storage
• gs_par_u32_storage

And access the parameter values through the offset table returned by the layout layer.
The benefits of doing this are:

• Removing the dependency on malloc;
• Making the RAM usage of the parameter's live storage determined at the compilation stage;
• Being more suitable for resource-constrained and deterministic embedded environments.

3. Introduce shared static storage contracts and compile-time verification
   To support the sharing of the same static storage area by different atomic types, this PR has added:

• Constraints for atomic type shared storage;
• Compile-time assertions for the size/alignment of u8/i8, u16/i16, u32/i32, f32;
• The PAR_ALIGNOF abstraction, which is compatible with C11 _Alignof and provides fallback implementation.
  These checks are used to ensure that the type compatibility prerequisite holds true in the static shared storage mode.

4. Enhance the ability to perform layout statistics during the compilation process
   In par_def.h, the compile-time count logic based on par_table.def has been added, which is used to generate: - PAR_LAYOUT_COMPILE_COUNT8

• PAR_LAYOUT_COMPILE_COUNT16
• PAR_LAYOUT_COMPILE_COUNT32

Provide compile-time constant support for layout layers and static storage groups.
5. Add layout-related configuration items
Add the following in par_cfg.h: - PAR_CFG_LAYOUT_SOURCE

• PAR_CFG_LAYOUT_STATIC_INCLUDE
• PAR_CFG_LAYOUT_COMPILE_SCAN
• PAR_CFG_LAYOUT_SCRIPT

It also added corresponding configuration validity checks, enabling the layout source to be switched to runtime scanning or script generation as per project requirements.
6. Reconstruct the README and split the module documentation
Reorganize the originally very long README.md into an entry-type document, while retaining:

• Module positioning
• Quick start
• Document navigation
• Package structure
• Integration instructions
• Links to related projects
  At the same time, a new independent document has been added: - docs/getting-started.md
• docs/architecture.md
• docs/api-reference.md

This makes it convenient to read by topic:

• For getting started, refer to "getting-started"
• For the principles, look at "architecture"
• For the interfaces, consult "api-reference"

7. Supplementary Verification Materials
   New addition: - docs/DeviceParameter_VerificationReport.xlsx

This is used to supplement the verification records related to this parameter module, facilitating subsequent review and archiving of integration verification.
Please provide the verified bsp and config (provide the config and bsp)

• BSP:

• The current changes are mainly located in the general module layer of Third_Party/autogen_parameter_manager/parameters.

• It is recommended to supplement the BSP used in this actual verification, for example: - bsp/stm32/stm32l496-st-nucleo

• Or your actual list of target boards

• .config:
  It is recommended to add the configuration items covered by this verification, with the key points including: - PAR_CFG_LAYOUT_SOURCE=PAR_CFG_LAYOUT_COMPILE_SCAN

• PAR_CFG_ENABLE_ID

• PAR_CFG_ENABLE_PERSIST

• PAR_CFG_NVM_EN

• Atomic backend related configuration

• If the script layout mode has been verified, it is also recommended to list it together: - PAR_CFG_LAYOUT_SOURCE=PAR_CFG_LAYOUT_SCRIPT

• action:
  Please provide the link for the action/CI compilation success of the corresponding branch of your personal repository.

[wdfk-prog]

feat(core): Add compile-time initialization for parameter defaults

Why to submit this PR
The current default values are set uniformly by calling par_set_all_to_default() at runtime. Here, the initialization method of default values is changed to handle them by grouping by storage type, enabling the default values of integer parameters to be statically initialized at compile time, while retaining the ability of F32 parameters to write default values after the layout is completed.
What is your solution?
This modification changes gs_par_u8_storage, gs_par_u16_storage and gs_par_u32_storage from merely declaring uninitialized shared storage arrays to generating default value initialization contents at compile time based on par_table.def.
The specific handling method is as follows:

• For U8/I8 parameters, the default values will be written to the static initialization table of the u8 storage group;
• For U16/I16 parameters, the default values will be written to the static initialization table of the u16 storage group;
• For U32/I32 parameters, since the shared u32 storage needs to be written according to the bit-pattern, a new function par_patch_f32_defaults_from_table() is added. This function performs a one-time patch write after the parameter layout and offset are available;
• In par_init(), par_set_all_to_default() is no longer called. Instead, only the F32 default value patch process is executed.
  This enables the default values of the integer type to be directly initialized during the static storage stage, reducing the reliance on uniformly re-writing default values at runtime, while maintaining the storage compatibility of the F32 type.
  Please provide the verified bsp and config (provide the config and bsp)
• BSP:
• [Please fill in the actual verification BSP path]
• .config:
• [Please fill in the configuration items used for this verification]
• action:
• [Please fill in the CI/Action link corresponding to the branch of your own repository]

[wdfk-prog]

feat(core): Add configurable F32 parameter support

Why to submit this PR

Currently, the F32 type capability in the parameter management module is built - in by default, lacking an independent configuration switch. As a result, it is impossible to trim the support for the F32 type according to product resource constraints or actual requirements.

To enhance the configurability and scalability of the module, this PR adds a configurable interface for the F32 type, allowing users to decide whether to enable F32 type support through configuration items while keeping the existing behavior under the default configuration unchanged.

What is your solution

This PR adds a configuration item PAR_CFG_ENABLE_TYPE_F32 to control whether the parameter management module enables F32 type support:

1. Add PAR_CFG_ENABLE_TYPE_F32 in par_cfg.h with a default value of 1 to keep the default behavior of the existing project unchanged.
2. When PAR_CFG_ENABLE_TYPE_F32 == 1:
   • Keep the storage, interfaces, and default value initialization logic related to the F32 parameter type enabled normally.
   • The PAR_SET / PAR_GET macros support F32 type distribution.
3. When PAR_CFG_ENABLE_TYPE_F32 == 0:
   • Trim the storage, access macros, read - write interfaces, and initialization logic related to F32.
   • The PAR_SET / PAR_GET macros no longer expose the F32 distribution path.
   • In par_layout.c, no corresponding 32 - bit layout is allocated for the F32 type.
4. To avoid the incorrect use of PAR_ITEM_F32 after disabling F32, add a compile - time check in par_def.c:
   • When F32 support is disabled but the parameter table still contains PAR_ITEM_F32, a static assertion is triggered to clearly indicate the inconsistency between the configuration and the parameter definition.
5. Keep par_def.h decoupled from the configuration and do not directly trim the enumeration definitions according to the configuration to avoid issues with the header file inclusion order and maintain the stability of the enumeration.

The goal of this modification is to add the configurable capability for the F32 type to the parameter module rather than change the default behavior. When the configuration is not modified, the system behavior remains the same as before.

Please provide the config and bsp

• BSP: Not provided
• .config:
  • PAR_CFG_ENABLE_TYPE_F32 = 1
  • PAR_CFG_ENABLE_TYPE_F32 = 0
• action: Not provided

[wdfk-prog]

feat(core): Make validation and change callbacks configurable

This PR adds two independently configurable runtime capability settings for autogen_parameter_manager, enabling the parameter module to enable runtime validation and on-change callback as needed under different resource constraints and functional requirements, while maintaining the existing behavior as per the default configuration.
Why to submit this PR
The current parameter module integrates runtime validation and parameter change callback as default runtime hooks within the ordinary setter process.
However, in actual usage, different projects have varying requirements for these two capabilities:

• In some scenarios, only parameter change notifications are required, without the need for runtime verification;
• In some cases, only runtime verification is needed, without the need for change callbacks;
• There are also scenarios where it is desired to disable these two types of capabilities in order to reduce code size and runtime overhead.
  Therefore, this PR has adjusted these two types of functions from fixed behaviors to independently modifiable optional features, thereby enhancing the flexibility, configurability and maintainability of the module.
  What is your solution?
  This PR mainly includes the following modifications:

1. Add two independent configuration switches - PAR_CFG_ENABLE_RUNTIME_VALIDATION

• PAR_CFG_ENABLE_CHANGE_CALLBACK

By configuring the macros, you can control whether to enable the runtime validation callback and parameter change callback. The default values are both enabled to maintain the existing default behavior.
2. Cull callback table based on configuration

• g_par_cb_table is generated only when at least one runtime hook is enabled;
• The validation and on_change members are controlled by the corresponding configuration macros respectively.

3. Trim the internal logic of the ordinary setter according to the configuration

• In par_set_u8/i8/u16/i16/u32/i32/f32():
• Perform the validation callback check only when PAR_CFG_ENABLE_RUNTIME_VALIDATION is enabled;
• Save the old value and trigger the on-change callback only when PAR_CFG_ENABLE_CHANGE_CALLBACK is enabled.

4. Configure and trim the registration interface

• par_register_on_change_cb() is provided only when PAR_CFG_ENABLE_CHANGE_CALLBACK is enabled;
• par_register_validation() is provided only when PAR_CFG_ENABLE_RUNTIME_VALIDATION is enabled.

5. Organize the conditional compilation code structure

• Adjust the boundaries of some #if / #endif statements;
• Move par_is_value_changed() back to the relevant code area of PAR_CFG_NVM_EN, enhancing code readability and maintainability.
  Please provide the verified bsp and config (provide the config and bsp)
• BSP: "To be supplemented. Please fill in the actual BSP path used for verification." - .config:
• PAR_CFG_ENABLE_RUNTIME_VALIDATION=1
• PAR_CFG_ENABLE_CHANGE_CALLBACK=1
• "The following combinations have been verified (please make the necessary additions or deletions as per actual situation):" - PAR_CFG_ENABLE_RUNTIME_VALIDATION=1, PAR_CFG_ENABLE_CHANGE_CALLBACK=1
• PAR_CFG_ENABLE_RUNTIME_VALIDATION=1, PAR_CFG_ENABLE_CHANGE_CALLBACK=0
• PAR_CFG_ENABLE_RUNTIME_VALIDATION=0, PAR_CFG_ENABLE_CHANGE_CALLBACK=1
• PAR_CFG_ENABLE_RUNTIME_VALIDATION=0, PAR_CFG_ENABLE_CHANGE_CALLBACK=0
• action: Please fill in the CI/Action link corresponding to your own repository's PR branch. (This information is yet to be provided.)

[wdfk-prog]

refactor(API): Replace generic parameter macros with typed wrappers

Why submit this pull request?
This PR mainly restructures and organizes the implementation of Third_Party/autogen_parameter_manager/parameters, aiming to reduce the complexity of the single file par.c, minimize duplicate code, enhance readability and maintainability, and facilitate the subsequent expansion of related logic for parameter types and static layout generation.
Currently, par.c contains a large amount of repetitive code for typed setters/getters, fast setters, bitwise fast setters, and static storage initialization macros. The reading and maintenance costs are high. In this submission, these private implementations will be split into internal include fragments without changing the external interface.
What is your solution?
The solution of this PR is as follows:

1. The macros related to static storage initialization of parameters and array definitions were extracted from par.c and placed in the private file par_storage_init.inc, and were included within par.c.
2. The repeated implementations of setter/getter/fast setter for various types of parameters were extracted to par_typed_impl.inc, generated through unified macro expansion to reduce duplicate code.
3. The repeated implementations of fast setters (such as bitand / bitor) for bitwise operations were extracted to par_bitwise_impl.inc, generating corresponding implementations for u8/u16/u32.
4. The hash definition area related to PAR_CFG_ENABLE_ID was organized to make the conditional compilation boundaries clearer.
5. The file header comments were added to the template file par_layout_static.htmp, and the format of some macro definitions was unified.
   The main focus of this modification is on code refactoring and structure organization, without introducing any new external function interfaces. The expected outcome is that the existing operational behavior will not be altered.
   Please provide the verified bsp and config (provide the config and bsp)

• BSP: To be supplemented
• .config: This time it is a source code reconfiguration, and no new Kconfig options have been introduced; if specific configurations were used during verification, please provide the actual enabled items
• action: To be supplemented

[wdfk-prog]

feat(core): Add raw reset-all API for parameter manager

Why to submit this PR
Currently, par_set_all_to_default() restores each parameter through the normal runtime setter path.
When there are a large number of parameters, this approach incurs additional processing overhead for each parameter, including verification, callbacks, and setter-side range handling, and is not suitable for achieving a more efficient implementation for the "restoring all parameters to default values" batch operation.
Therefore, this PR is submitted to add a more direct path for full recovery of default values in the parameter management module. While maintaining the existing interface semantics unchanged, it provides an optional more efficient implementation of reset-all.
What is your solution?
This PR adds a raw reset-all capability in autogen_parameter_manager while maintaining the original interface behavior:

1. A new compilation switch PAR_CFG_ENABLE_RESET_ALL_RAW has been added, which is used to control whether this capability is enabled.
2. Three sets of default value mirroring storage have been newly added: - gs_par_u8_default_mirror

• gs_par_u16_default_mirror
• gs_par_u32_default_mirror

3. In par_init():

• First, correct the default values for F32;
• Then, before the optional NVM loading, snapshot the current live default to the aforementioned mirror.

4. Add the public interface par_reset_all_to_default_raw():

• After locking, group by storage width and directly use memcpy() to restore the default values to the runtime parameter storage;
• This path no longer traverses each parameter through the normal setter.

5. Keep the original par_set_all_to_default(), and clearly indicate the differences between the two paths in the comments:

• par_set_all_to_default(): Maintain the original setter semantics;
• par_reset_all_to_default_raw(): Used for faster batch restoration, bypassing the setter-side logic.
  The main benefits of this solution are: in the "full recovery to default values" scenario, it reduces the processing overhead for each parameter and improves execution efficiency.
  At the same time, this PR also clearly explains through comments that the raw path will bypass the validation / change callback / setter-side range handling, avoiding the misuse of interface semantics.
  Please provide the verified bsp and config (provide the config and bsp)
• BSP:
• [Please replace with the actual BSP path you have verified]
• For example: bsp/stm32/stm32l496-st-nucleo
• .config:
• [Please replace with the actual configuration items you use for verification]
• It is recommended to include at least the configurations related to this PR, such as: - PAR_CFG_ENABLE_RESET_ALL_RAW
• As well as the relevant configuration items required for enabling the parameter management module in this project
• action:
• [Please replace this with the CI/Action build success link corresponding to the PR branch of your own repository]

[wdfk-prog]

refactor(core): Move parameter ID map checks to compile time

Why to submit this PR
The current parameter ID lookup table is constructed and verified at runtime, which has several issues:

1. Parameter ID duplication or hash bucket conflicts can only be detected during the runtime initialization stage, and the problem is exposed relatively late;
2. Maintaining the ID map and ready status during runtime introduces additional initialization logic and RAM usage;
3. par_set_all_to_default() does not reuse a more efficient reset path in scenarios where raw reset is supported.
   This PR has changed the parameter ID mapping to be statically generated at compile time, and has moved the checks for duplicate IDs / hash bucket conflicts as far ahead as possible to the compile stage, so as to detect configuration errors earlier and simplify the runtime logic.
   What is your solution?
   The main changes in this PR are as follows:
4. Added static ID lookup table:

• Created par_id_map_static.c/.h
• Generated g_par_id_map_static during compilation based on par_table.def
• par_get_num_by_id() now directly queries the static table instead of relying on the runtime-built g_par_id_map

2. Consolidate the ID hash-related configurations into par_cfg.h:

• Extract PAR_ID_HASH_GOLDEN_RATIO_32
• Extract PAR_ID_HASH_MIN_BUCKETS
• Extract PAR_ID_HASH_BITS / PAR_ID_HASH_SIZE
• Extract PAR_HASH_ID_CONST(id_)
• Retain the relevant static assertions to ensure the geometric parameters of the hash table are valid

3. Enhance compile-time verification:

• Add duplicate parameter ID check in par_def.c
• Add hash bucket conflict check for parameter IDs in par_def.c
• If there are duplicate IDs in par_table.def or different IDs fall into the same hash bucket, report an error directly during the compilation stage

4. Retain optional runtime diagnostic capabilities:

• Added PAR_CFG_ENABLE_RUNTIME_ID_DUP_CHECK
• Added PAR_CFG_ENABLE_RUNTIME_ID_HASH_COLLISION_CHECK
• When necessary, additional runtime diagnostics can be performed on the ID table generated at compile time during the initialization phase and more explicit logs can be output.

5. Simplify initialization/de-initialization logic:

• Remove runtime g_par_id_map and gb_par_id_map_ready
• Change par_get_num_by_id() to perform the query only when par_is_init() is true

6. Optimize default value restoration path:

• par_set_all_to_default() will preferentially reuse par_reset_all_to_default_raw() when PAR_CFG_ENABLE_RESET_ALL_RAW = 1
• In other scenarios, it will maintain the original behavior of performing par_set_to_default() for each item separately

7. Synchronous update of template examples:

• Update par_cfg_port.htmp to include optional runtime diagnostic configuration items
• Adjust some example IDs in par_table.deftmp to prevent duplication or hash conflicts that could lead to misuse
  Please provide the verified bsp and config (provide the config and bsp)
• BSP: [Please fill in the actual path of the board card/BSP that you have verified] - .config:
• [If no changes, please fill in: None]
• [If there are changes, please list them, for example: PAR_CFG_ENABLE_ID]
• [If there are changes, please list them, for example: PAR_CFG_ENABLE_RESET_ALL_RAW]
• [If there are changes, please list them, for example: PAR_CFG_ENABLE_RUNTIME_ID_DUP_CHECK]
• [If there are changes, please list them, for example: PAR_CFG_ENABLE_RUNTIME_ID_HASH_COLLISION_CHECK]
• action: [Please fill in the CI/Action link of the corresponding PR branch for your repository]

[wdfk-prog]

fix(parameters): Correct typed getter/setter error handling

Pull/merge request description: (PR description)

Why to submit this PR
The typed getter/setter in the current parameter management module has a problem of inconsistent error semantics.
Originally, the typed getter would sometimes mix the error code with the return value semantics in abnormal scenarios, making it difficult for the caller to accurately distinguish between "the successful parameter value read" and "the interface execution failure"; at the same time, the boundary between the normal typed setter/getter and the fast setter is not clear enough.
This will give rise to two direct problems:

1. The caller is unable to promptly detect initialization failures, illegal parameter numbers, type mismatches, etc. under the "release" path.
2. The error handling styles at the interface layer and implementation layer are not unified, resulting in higher costs for subsequent maintenance and expansion.
   What is your solution?
   This PR has refined and corrected the semantic of the typed getter/setter interface in the parameter management module. The main contents include:
3. Standardize the normal typed getter to the interface style of par_status_t + output pointer, clearly requiring the caller to determine success through the return status and obtain the value through the output parameter.
4. Keep PAR_ASSERT(...) in the normal typed getter/setter, while adding necessary runtime checks on the release path, and return clear error codes in case of exceptions.
5. Uniformly return error codes for the following abnormal scenarios:

• Module not initialized: ePAR_ERROR_INIT
• Parameter index out of range: ePAR_ERROR_PAR_NUM
• Parameter type mismatch: ePAR_ERROR_TYPE
• Output pointer is null: ePAR_ERROR_PARAM

4. Keep the fast typed setter designed as assert-only, without adding additional runtime overhead for release mode, and continue to be used as a trusted path.
5. Remove the PAR_GET_* macros, unify the calling method, and avoid the old macro style from further amplifying the interface semantic ambiguity.
6. Synchronously modify par_get() and the internal paths that rely on typed getters, so that the error handling is consistent with the new interface semantics.
   Overall, the goal of this PR is:
   "To ensure that the normal API also has clear and transmissible error return semantics in the release version, while maintaining the lightweight nature of the fast path and the existing design philosophy." **

[wdfk-prog]

fix(API): Correct runtime validation and F32 change detection

Summary

This PR tightens the parameter module public API behavior and aligns implementation with the intended contract.

Main changes:

• Keep public *_fast() API names unchanged
• Restore the raw reset-all fast path when PAR_CFG_ENABLE_RESET_ALL_RAW=1
• Propagate the correct return status from par_set_all_to_default()
• Simplify validation helpers into runtime/metadata variants
• Remove redundant outer NULL checks and rely on centralized validation
• Change F32 "value changed" detection to bitwise comparison
• Remove legacy persistant compatibility API and keep only persistent
• Update comments and docs to reflect the current behavior

How to test

Recommended verification:

1. Build the library in the normal RT-Thread project configuration
2. Verify public par_set_*_fast() APIs are unchanged
3. Verify par_set_all_to_default():
   • uses raw path when PAR_CFG_ENABLE_RESET_ALL_RAW=1
   • returns the actual status code from the raw/default path
4. Verify runtime APIs still reject invalid access through centralized validation
5. Verify F32 changed-detection behavior:
   • equal bit pattern => not changed
   • different bit pattern => changed
   • NaN handling follows bitwise semantics
6. Verify persistent API compiles and old persistant API is no longer exposed

Related issues

• N/A

Review / Merge checklist

• PR title and summary are descriptive
• Docs/comments updated to match behavior
• Tests included or verified in target RT-Thread build
• Backport label added if needed

[wdfk-prog]

refactor(core): Clarify hook contract and make bitwise fast setters f…

Summary

This PR tightens the public contract around parameter hooks and simplifies bitwise fast setter semantics.

What changed

• Clarified pf_par_on_change_cb_t and pf_par_validation_t usage constraints in public headers and docs
• Documented that callbacks / validation are intended to stay synchronous, short, and non-blocking
• Explicitly documented that re-entering the parameter module from callbacks / validation is advanced usage and must be reviewed by the application
• Changed bitwise fast setters to follow unchecked fast-path semantics
• Restricted bitwise fast setters to flags / bitmask style usage for U8 / U16 / U32
• Removed range-based limiting behavior from bitwise fast setters
• Aligned docs, header comments, and implementation semantics

Files changed

• parameters/src/par.h
• parameters/src/par_bitwise_impl.inc
• parameters/docs/api-reference.md
• parameters/docs/architecture.md
• parameters/docs/getting-started.md
• parameters/README.md
• parameters/CHANGE_LOG.md

How to test

1. Build with:
   • PAR_CFG_ENABLE_RANGE = 1
   • PAR_CFG_ENABLE_RANGE = 0
2. Verify par_bitand_set_u8/u16/u32_fast() and par_bitor_set_u8/u16/u32_fast():
   • still perform bitwise updates correctly
   • return ePAR_OK
   • no longer depend on par_get_range()
   • no longer produce limited / clamp style behavior
3. Verify bitwise fast setters do not invoke validation or on-change callbacks
4. Review docs and header comments to confirm the contract is consistent across:
   • public API header
   • README
   • architecture doc
   • API reference
   • getting started guide

Notes

• This PR does not change normal setter locking behavior
• This PR does not address callback recursion chains or lock-hold-time reduction
• This PR intentionally narrows bitwise fast setters to a trusted fast-path API for flags / bitmask parameters

Related Linear tickets, Github issues, and Community forum posts

Review / Merge checklist

• PR title and summary are descriptive
• Docs updated
• Tests included
• release/backport label added if needed

[wdfk-prog]

refactor(core): Unify checked setter flow and fast default restore

Summary

This PR aligns parameter write semantics across the public setter APIs, default restore path, and NVM restore path.

What changed

• Introduce par_resolve_metadata() / par_resolve_runtime() to separate metadata lookup from runtime-init checks
• Add par_validate_expected_type() to validate resolved parameter type against the expected typed API
• Centralize all public checked write logic into par_set_checked_core(), including:
  • runtime resolution
  • expected type validation
  • access enforcement
  • optional runtime validation callback
  • mutex handling
  • fast typed setter dispatch
  • optional on-change callback dispatch
• Make par_set() reuse the same checked write core instead of maintaining its own per-type dispatch logic
• Make typed public setters par_set_xxx() reuse the same checked write core
• Add explicit ePAR_ERROR_ACCESS status and update error/warning bit masks accordingly
• Change par_set_to_default() to restore defaults through the internal fast typed setter path under mutex protection
  • this intentionally bypasses access enforcement, runtime validation callbacks, and on-change callbacks
  • this makes restore-to-default semantics consistent with the documented trusted internal restore path
• Update par_set_all_to_default() documentation to reflect fast default-restore semantics when raw bulk reset is disabled
• Change NVM load/restore to use an internal fast restore helper instead of the public checked setter path
• Replace fast-setter assertion paths that depended on public metadata getters with par_assert_fast_typed_preconditions()
  • keeps fast paths assert-only
  • avoids routing trusted internal paths through public metadata accessors
• Rename helper APIs/comments from validate_* to resolve_* where the behavior is metadata/runtime resolution rather than full public write validation

Behavioral impact

• par_set_to_default() is no longer rejected by RO access policy
• public write access control is now enforced consistently in one place
• public checked setters and generic par_set() now share the same validation/callback/access path
• NVM restore and default restore both follow explicit internal fast-path semantics

How to test

1. Public checked setter access enforcement

   • define an RO parameter
   • call par_set() and par_set_xxx() on it
   • verify both return ePAR_ERROR_ACCESS

2. Restore default on RO parameter

   • define an RO parameter with a non-default runtime value
   • call par_set_to_default()
   • verify restore succeeds and value becomes default

3. Typed setter consistency

   • call par_set() and the matching par_set_xxx() on the same RW parameter
   • verify both take the same access / validation / callback path

4. Runtime validation callback

   • register a validation callback that rejects one value
   • verify public checked setters reject it
   • verify par_set_to_default() and NVM restore do not use that callback path

5. On-change callback

   • register an on-change callback
   • verify it is triggered for public checked setters on value change
   • verify it is not triggered by par_set_to_default() fast restore path

6. NVM restore

   • persist a parameter value to NVM
   • re-init and restore from NVM
   • verify the stored value is restored correctly through the internal fast path

7. Status code compatibility

   • verify any code decoding par_status_t handles the new ePAR_ERROR_ACCESS bit and shifted warning bits correctly

Related Linear tickets, Github issues, and Community forum posts

Review / Merge checklist

• PR title and summary are descriptive.
• Docs updated or follow-up ticket created.
• Tests included.
• PR labeled with release/backport if this needs backporting.

[wdfk-prog]

docs(API): Convert comments to Doxygen format and align with clang-fo…

Summary

• Add a .clang-format file for the src tree and align the parameter module to a consistent formatting style.
• Normalize Doxygen comments across public headers, implementation files, and internal .inc fragments in the parameter subsystem.
• Clean up parameter-module lifecycle handling by adding par_if_deinit() declarations/implementations and tightening the NVM deinit ownership path.
• Keep internal storage/layout/NVM helper code easier to navigate by making comment structure and section boundaries consistent.

How to test

• Build the parameter module and verify there are no compile errors or new warnings.
• Exercise the init/deinit path for:
  • par_init()
  • par_deinit()
  • par_nvm_init()
  • par_nvm_deinit()
• Smoke-test persistent parameter save/load and reset-to-default flows.
• Verify mutex acquire/release paths still behave as expected on the target platform.

Related Linear tickets, Github issues, and Community forum posts

Review / Merge checklist

• PR title and summary are descriptive.
• Docs updated or follow-up ticket created.
• Tests included.
• PR labeled with release/backport if backport is needed.

[wdfk-prog]

refactor(core): Decouple par_nvm from concrete storage backend

Summary

Introduce a pluggable parameter-storage backend for NVM persistence.

What changed

• add abstract storage backend API in src/backend/par_store_backend.h
• add packaged GEL NVM adapter in src/backend/par_store_backend_gel_nvm.c
• switch par_nvm.c from direct nvm.* calls to mounted backend callbacks
• document backend selection, link-time requirements, and updated deinit semantics
• fix a few NVM-path issues while refactoring:
  • use the correct loop index in persistent-parameter rebuild path
  • mark rebuilt LUT entries as valid
  • align signature/hash/header accesses with backend-relative addressing

How to test

• build with PAR_CFG_NVM_EN = 1 and packaged GEL backend enabled
• verify init/load/save/sync/deinit flows succeed with the mounted backend
• verify build fails as expected when NVM is enabled but no backend implementation is linked
• verify persisted parameters still load correctly after restart
• verify docs match the new integration model

Related Linear tickets, Github issues, and Community forum posts

Review / Merge checklist

• PR title and summary are descriptive
• Docs updated or follow-up ticket created
• Tests included
• Release/backport label added if needed

[wdfk-prog]

refactor(core): Reorganize parameter manager source tree and sync docs

Summary

Reorganize the parameters module source tree into layered subdirectories and
sync the integration documentation with the new layout.

What changed

• Move definition-related sources into src/def/
• Move private implementation fragments into src/detail/
• Move layout sources into src/layout/
• Move persistence sources into src/persist/
• Move backend adapter sources into src/persist/backend/
• Move platform-facing hooks into src/port/
• Update internal include paths to match the new tree layout
• Rename the packaged GEL backend config switch from PAR_CFG_NVM_REGION usage
  to PAR_CFG_NVM_BACKEND_GEL_EN
• Update README and docs to describe the new integration structure and include
  path requirements
• Clarify several comments / docstrings for generated layout and static ID map

Why

This makes the module structure closer to its actual responsibilities:
definitions, layout, persistence, porting hooks, and private implementation
details are now separated explicitly, which should improve maintainability and
make integration boundaries clearer.

How to test

• Build an existing integration with the new source layout
• Verify application code still includes par.h from parameters/src
• Verify integrator-owned headers such as par_cfg_port.h remain reachable
  through the configured include path
• If NVM is enabled:
  • verify src/persist/par_nvm.c builds successfully
  • verify the packaged GEL backend is only built when
    PAR_CFG_NVM_BACKEND_GEL_EN = 1
• Smoke test parameter init / set / get / reset / persistence flows

Related Linear tickets, Github issues, and Community forum posts

Review / Merge checklist

• PR title and summary are descriptive
• Docs updated
• Tests included or existing integration build verified
• Release/backport label added if needed

[wdfk-prog]

fix(core)!: Rework parameter NVM header and CRC serialization

Summary

Rework parameter NVM persistence metadata handling:

• serialize the NVM header explicitly instead of relying on a packed in-memory layout
• store table_id inside the header and cover both obj_nb and table_id with header CRC
• replace the local CRC helpers with par_if_crc16_accumulate() and par_if_crc8_accumulate() hooks
• switch table-id hashing and persisted metadata serialization to platform-native byte order
• replace the local restore helper with par_set_fast()
• document the fixed 8-byte persisted object layout more clearly

How to test

1. Build the parameter manager with persistence enabled
2. Boot on a clean device / erased NVM and verify parameters are written and restored normally
3. Reboot and verify persisted values are loaded correctly
4. Corrupt header bytes and verify startup detects invalid metadata and rebuilds NVM
5. Corrupt one persisted object and verify CRC detection works as expected
6. Validate table-id mismatch handling when the persistent schema changes
7. Validate behavior on upgrade from an image that wrote the previous NVM format

Important compatibility note

This PR changes the serialized NVM metadata format and byte-order assumptions.
Existing persisted parameter images written by older firmware may not be readable without migration support.

Related issues

Review / Merge checklist

• PR title and summary are descriptive
• Backward compatibility of old NVM images has been explicitly reviewed
• Migration strategy or intentional reset behavior is documented
• Tests included for clean boot, reboot restore, corrupted header, corrupted object, and upgrade from old format
• Docs updated if needed

[wdfk-prog]

fix(core): Stabilize persistent slot mapping for parameter NVM

Summary

Introduce a compile-time persistent slot index for parameter definitions and use that slot mapping in the NVM persistence path.

Main changes:

• Add persist_idx to par_cfg_t
• Derive dense PAR_PERSIST_IDX_<enum_> values from par_table.def
• Build a compile-time mapping from persistent slot to live parameter number
• Refactor NVM load/write/reset flow to use slot-based addressing
• Improve persistence-related debug output and comments
• Relax the par_cfg_t size note to avoid ABI-specific assumptions

How to test:

1. Build with persistence enabled and verify compilation succeeds
2. Boot with empty NVM and confirm defaults are written correctly
3. Reboot with existing NVM and confirm persistent parameters are restored
4. Add a new persistent parameter and verify old data is preserved while the new slot is appended
5. Disable/enable a persistent parameter and verify table-ID compatibility behavior matches expectations
6. Exercise par_get_num_by_id() and par_get_id_by_num() basic lookup paths

Related Linear tickets, Github issues, and Community forum posts

Review / Merge checklist

• PR title and summary are descriptive
• Docs updated or follow-up task created
• Tests included
• Backport labeling evaluated if needed

[wdfk-prog]

feat[NVM]: add selectable persistent record layouts

PR Message

(PR description)

[

(why to submit this PR)

The current parameter persistence path uses one built-in record format, and the backend selection and record-layout selection are not exposed as clear packaged configuration choices.
This makes it hard to:

• choose between fixed-slot and compact-payload persistence layouts based on the target scenario
• extend or maintain layout-specific serialization logic without growing par_nvm.c
• keep documentation, configuration, and table-id compatibility rules aligned when the persisted record layout changes

你的解决方案是什么 (what is your solution)

This PR introduces the following changes:

• add packaged parameter-storage backend selection in Kconfig, while reserving a generic flash backend entry as a placeholder
• add persisted record layout selection in Kconfig, supporting:
  • fixed 4-byte payload slot with size descriptor
  • fixed 4-byte payload slot without size descriptor
  • compact natural-width payload with size descriptor
• update SConscript to compile the corresponding layout implementation according to the selected record layout
• split layout-specific address calculation, record-width calculation, serialization, deserialization, and CRC validation out of par_nvm.c into dedicated layout source files
• add record-layout and flash-backend configuration bridges in par_cfg.h and par_cfg_port.h
• include the selected persisted record layout in the table-id digest so layout switches are treated as managed compatibility changes
• update README, architecture, api-reference, and getting-started documentation to describe layout selection, compatibility boundaries, flash-backend constraints, and the compile-time ordered slot-image design

]