mirror of
https://github.com/qmk/qmk_firmware.git
synced 2025-06-21 16:42:08 +00:00
2b00b846dc
* 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.
30 lines
1.5 KiB
Markdown
30 lines
1.5 KiB
Markdown
# 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. |