Persistence

[TerryFogg]

For discussion

Previously in .Net Microframework there was an implementation of ExtendedWeakReferences which was a way of persisting some classes to flash.
Looking at the old code it looks complicated and has functionality that I would not use if I only wanted to persist class data across power down. The code for the extended weak references was in Heap_Persistence.cpp, and it references a WriteNonXIPData() routine for storing to flash. This code is not included in nanoFramework although the definition WriteNonXIPData is still included and unreferenced in nanoCLR_Runtime_HeapBlock.h.

The idea of a small amount of user configurable persistent data accessible from C# I believe is still a good idea.

Currently we have the config section in the linker script and specific code in C/C++ to reference it via configuration manager code, but it is out of the reach for most.

I have recently looked at the protobuf by @KlausVcb.
This looks to be an ideal and efficient way to serialize a class to binary.
I haven't used it, but it looks like you serialize the class/data to a stream.
I believe all we need to do is create a new stream type that manages reading and writing to the configuration section.

If we added a nanoff option to copy a previous serialized bin file from the desktop to the device, then we could easily setup many devices with individual attributes, deserialized at startup and consumed as a class.

There may be the possibility of removing the curent comfiguration manager setup and using this approach to all by using a base class which includes a WiFi setup class.
If we know the position of the data we can read it from c++ at boot time if necessary, or initialize from C# WiFi startup code.

Just a thought.

There are issues in managing the configuration section, but hopefully we can let the c++ code managed the implementation.
I know that the STM32H735 has a minium flash block erase size of 128Kb so that comes with its own issues, but for the development board STM32H735G-DK the configuration block can be located in external flash which doesn't require such a large erase size.

[josesimoes]

I would like to bring this too.
Implementing with the internal flash can be tricky as you've already mention because of the page size and the fact that the read current store -store to RAM - update content - erase flash - store to flash can (and will) go wrong occasionally and content will be lost. Not to mention that the flash endurance on that page can be hit pretty quick (in particular for developers not being aware of this).
Considering this, the option of storing to an external storage chip (flash/eeprom/...) looks like the best (only viable?) option to me.

On the serialization, why not using the existing binary serialization? Bring in protobuf will require adding that to the image. Plus there is only C# version of it.

I like the idea of exposing that through nanoff. Production use case as you've described above is a perfect example.

I'm not very keen on exposing the current data stored in config manager to managed code. For the simple reason that there could be sensitive information stored there and making it accessible doesn't add credibility to the platform. You'll tell me that this can be read anyway. Granted. Just that with the current schema it's harder and requires some expertise from the hacker.

For reference, there is feature suggestion for quite some time asking for this #886.