Is it possible to impl embedded-storage for nvs?

[HaoboGu]

embedded-storage is a widely used storage trait in Rust embedded world. Is it possible to implement this trait for nvs? If that, nvs could be compatible with a lot of external drivers that requires embedded-storage

[Vollbrecht]

It's absolutely possible, if someone finds the time to tackle it we are open for PR's and are happy to help reviewing it.

[fabracht]

I would like to help with the issue. But it seems someone's already working on it?
https://lib.rs/crates/esp-storage

[HaoboGu]

I would like to help with the issue. But it seems someone's already working on it?
https://lib.rs/crates/esp-storage

this library is designed to be used with esp-hal, not esp-idf-hal imo. esp-idf-hal provides nvs for interacting with the flash storage, but it's more like a kv store.

[ivmarkov]

It might still be quite possible to implement the embedded-storage traits on top of ESP IDF:

• It probably needs to be implemented both for the "raw" partitions, as well as for the wear-leveling partitions API that ESP IDF implements on top of raw partitions, so that the user can pick and choose depending on whether the stuff "on top" of the embedded-storage traits has its own way to deal with wear leveling
• The "native" implementation would be synchronous (blocking) unfortunately. Async implementation I think can only be provided via a hidden task/thread, yet - it might still be important, as a lot of the 3rd party crates that depend on embedded-storage seem to do so via the (newer) async API. Yet, ESP IDF does not have a native non-blocking API for dealing with partitions, I think and hence the need for a hiddien task/thread.

The question is a bit "why bother", when:

• For flash, you have the KV NVS API already (with wear leveling)
• For both flash and external SD cards, you have Spiffs and FatFS natively, i.e. you can work with the Rust std::fs API on top of the internal flash storage...

[HaoboGu]

The question is a bit "why bother", when:

Yeah, I agree that esp-idf has done almost everything for users. The only case that I think implementing embedded-storage is valuable is for some platform-agnostic drivers which need storage, they tend to use embedded-storage. This feature is not that crucial, but having it could be great.

[ivmarkov]

The question is a bit "why bother", when:

Yeah, I agree that esp-idf has done almost everything for users. The only case that I think implementing embedded-storage is valuable is for some platform-agnostic drivers which needs storage, they tend to use embedded-storage. This feature is not that crucial, but having it could be great.

I agree. It is also not that hard to implement at least the blocking embedded-storage traits. Implementing the async ones would be more useful though, as the rest of the embedded world is firmly moving towards async, and to implement the async ones, we need to implement an async wrapper for the ESP IDF otherwise-blocking raw & wear-leveling partitions API. The easiest way to do that (in the absence of other options) is to just use a hidden task/thread, possibly based on the private Unblocker struct in esp-idf-svc.

I don't have time to do this ATM, but if you feel you need an embedded-storage API on top of ESP IDF, you can give it a try in a PR, and I'll try to comment/support the PR until successful completion.