ahoneybun/qmk_firmware
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Non-volatile memory data repository pattern (#24356)

Browse source 
* First batch of eeconfig conversions.

* Offset and length for datablocks.

* `via`, `dynamic_keymap`.

* Fix filename.

* Commentary.

* wilba leds

* satisfaction75

* satisfaction75

* more keyboard whack-a-mole

* satisfaction75

* omnikeyish

* more whack-a-mole

* `generic_features.mk` to automatically pick up nvm repositories

* thievery

* deferred variable resolve

* whitespace

* convert api to structs/unions

* convert api to structs/unions

* convert api to structs/unions

* fixups

* code-side docs

* code size fix

* rollback

* nvm_xxxxx_erase

* Updated location of eeconfig magic numbers so non-EEPROM nvm drivers can use them too.

* Fixup build.

* Fixup compilation error with encoders.

* Build fixes.

* Add `via_ci` keymap to onekey to exercise VIA bindings (and thus dynamic keymap et.al.), fixup compilation errors based on preprocessor+sizeof.

* Build failure rectification.
This commit is contained in:
Nick Brassel 2025-03-21 23:38:34 +11:00 • committed by GitHub
parent c9d62ddc78
commit 2b00b846dc
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
87 changed files with 1464 additions and 839 deletions
Download patch file Download diff file Expand all files Collapse all files

30
quantum/nvm/readme.md Normal file
View file

@ -0,0 +1,30 @@
# Non-volatile Memory - Data Repositories
This area is intentionally structured in the following way:
```
╰- quantum
╰- nvm
├- readme.md
├- rules.mk
|
├- nvm_eeconfig.h
├- nvm_<<system>>.h
|
├- eeprom
| ├- nvm_eeconfig.c
| ├- nvm_<<system>>.c
| ╰- ...
|
├- <<another provider>>
| ├- nvm_eeconfig.c
| ├- nvm_<<system>>.c
| ╰- ...
╰- ...
```
At the base `nvm` level, for every QMK core system which requires persistence there must be a corresponding `nvm_<<system>>.h` header file. This provides the data repository API to the "owner" system, and allows the underlying data persistence mechanism to be abstracted away from upper code. Any conversion to/from a `.raw` field should occur inside the `nvm_<<system>>.c` layer, with the API using values, such as structs or unions exposed to the rest of QMK.
Each `nvm` "provider" is a corresponding child directory consisting of its name, such as `eeprom`, and corresponding `nvm_<<system>>.c` implementation files which provide the concrete implementation of the upper `nvm_<<system>>.h`.
New systems requiring persistence can add the corresponding `nvm_<<system>>.h` file, and in most circumstances must also implement equivalent `nvm_<<system>>.c` files for every `nvm` provider. If persistence is not possible for that system, a `nvm_<<system>>.c` file with simple stubs which ignore writes and provide sane defaults must be used instead.