esp32: add basic support for NVS Non-Volatile-Storage #6780
Conversation
|
Looks good to me. But maybe we (I) should get to the esp32-cmake stuff first so that we can move on completely from IDF3? |
|
I'm not sure this has any dependency on the cmake stuff, but yes, making progress on that would be awesome. |
You're right, it doesn't directly. I just saw that this NVS feature is not implemented for IDF3. So if merged as-is, that code path for IDF3 would pretty soon just be removed. It's just a question of which one to concentrate on first, cmake and IDF4 only, or these set of PRs with new esp32 features. I don't really mind (but I would actually like to try and cut a release before anything else...). |
This commit implements basic NVS support for the esp32. It follows the pattern of the esp32.Partition class and exposes an NVS object per NVS namespace. The initial support provided is only for signed 32-bit integers and binary blobs. It's easy (albeit a bit tedious) to add support for more types. See discussions in: #4436, #4707, #6780
|
Rebased on latest master and tested to work against IDF v4.1.1 (works also with v4.0.2 but error message names don't work, seems to be a bug in that version of the IDF). Merged in c10d431 Thank you! |
…ries-8.0.0-beta.0 update frozen libraries for 8.0.0-beta.0
This PR implements basic NVS support for the esp32. It follows the pattern of the esp32.Partition class and exposes an NVS object per NVS namespace. The initial support provided is only for signed 32-bit integers and binary blobs. The ints 'cause I need them to provide some config variables that can be read in main() before python code can execute (PR with a nifty feature coming soon...) and the blobs because they allow anything to be stored. It's easy (albeit a bit tedious) to add support for more types, but I'm not sure what really makes sense. In general, config for python apps should use files, not NVS IMHO...
Previous issues / PRs: #4436 and #4707