Suggestions on the way forward for accessing persistent settings storage?

[doingnz]

MFDeploy can read/write named blocks in the target device, and the Native code in the device can access these named regions easily with the existing methods. (ConfigHelper.cpp)

The missing link is managed code to also access these named regions.

We could create Interop class to call the native methods to read/write the blocks as byte[] data.
Suggested methods to Marshal the byte[] to C# structs?

My initial need is for settings that don't change often. i.e. single image of FW that can be configured to behave in different ways. I can therefore make something that works with only a byte[] in the managed code. However, a more general solution would be nice to get done from the outset.

Any suggestions? and working code ? :-)

[JohnySeven]

This has been already done in GCC build of .NET MF 4.3 from @NicolasG3, check this:

https://github.com/NicolasG3/NETMF4.3_Community/blob/master/Community/Libraries/Community.Hardware.Settings/Native/Community_Hardware_Settings_Community_Hardware_SystemSettings.cpp

or here

https://github.com/NicolasG3/NETMF4.3_Community/blob/master/Community/Libraries/Community.Hardware.Settings/Native/Community_Hardware_Settings.cpp

But it's good stuff that can be added into standard .NET MF libs.

[smaillet-ms]

The whole config concept is something to be re-evaluated in the next version. I think this should follow the same overall goal and patterns as all other parts. In particular defining the interface rather than dictating the implementation. This allows platforms to implement the persistent settings/configuration information in whatever mechanism is most appropriate for a given device. We could provide some default implementation (e.g. using nor flash as we do now, using a set of blocks in a NAND flash, or even using a file in a file system stored on a NAND or SD card, etc...) While much of the NETMF HAL API already follows the pattern of separating interface from implementation, the storage APIs and, in particular the config data blurs the distinction as the technology of the time was almost exclusively the use of external flash memory.

[doingnz]

@smaillet-ms I agree.

• Maybe an API that uses name/value pairs.
• Examples store byte[] and string as example values.
• Reading the values from storage should not require reader to know the exact length before calling the API.
• Would be nice to include combinations of read-only, read-write, internally and externally accessible,
• Optional security.

@JohnySeven - thanks for the pointer to the 4.3 project.

A note for those reading this in the future is that the 4.3 sample code inserts an additional config header in the byte[] data that is not required and confuses things in v4.4. The WriteConfigBlock/ReadConfigBlock methods can be one line calls to UpdateBlockWithName and ApplyConfig respectively.

INT8 MFConfigHelper::WriteConfigBlock( LPCSTR name, CLR_RT_TypedArray_UINT8 data, HRESULT &hr )
{
    return HAL_CONFIG_BLOCK::UpdateBlockWithName(name, data.GetBuffer(), data.GetSize(), TRUE);
}

INT8 MFConfigHelper::ReadConfigBlock( LPCSTR name, CLR_RT_TypedArray_UINT8 data, HRESULT &hr )
{
    BOOL success = HAL_CONFIG_BLOCK::ApplyConfig(name, data.GetBuffer(), data.GetSize());

    return success;
}