readme.md (1526B)
1 # Non-volatile Memory - Data Repositories 2 3 This area is intentionally structured in the following way: 4 5 ``` 6 ╰- quantum 7 ╰- nvm 8 ├- readme.md 9 ├- rules.mk 10 | 11 ├- nvm_eeconfig.h 12 ├- nvm_<<system>>.h 13 | 14 ├- eeprom 15 | ├- nvm_eeconfig.c 16 | ├- nvm_<<system>>.c 17 | ╰- ... 18 | 19 ├- <<another provider>> 20 | ├- nvm_eeconfig.c 21 | ├- nvm_<<system>>.c 22 | ╰- ... 23 ╰- ... 24 ``` 25 26 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. 27 28 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`. 29 30 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.