I am having a problem using the GHI.Processor.Configuration class to save settings to a Spider II mainboard. It appears after calling WriteEntry, then calling GetEntrySize or ReadEntry never returns the data. A simplified repro follows:
// The setting value is a string about 30 characters in length and it does contain \n characters in it.
byte[] data = Encoding.UTF8.GetBytes("Setting\nValue\n");
// WriteEntry returns "true".
bool result = Configuration.WriteEntry("SettingName", data);
// Calling GetEntrySize immediately after writing the entry always results in zero.
bool size = Configuration.GetEntrySize("SettingName");
// Calling ReadEntry results in null.
byte[] readData = Configuration.ReadEntry("SettingName");
I believe I am running the latest stable version of all SDKs. The firmware of the board follows.
Let me know if I can provide any other information. Any help is greatly appreciated.
@ John - I simply copy the code from the snippet above and paste it in the [em]ProgramStarted()[/em] method and I experience the issue. The setting is not saved.
I should mention, there was a typo in the code, the third line should have read int size (instead of bool size).
@ John - Shortly after publishing the last post, I decided to update the firmware in case it can somehow get corrupted. I updated the firmware again just to make sure it was written correctly. After updating the firmware, running the same sample worked fine. It appears the problem has gone away.
Ultimately, I am not sure what the issue was but I guess I am curious on best practices for saving settings. If I update a particular setting periodically using the WriteEntry function, could this cause problems. For example, if I use WriteEntry(“SettingName”, value) and later on I want to change the value, can I simply use WriteEntry(“SettingName”, newValue) or is there a best practice for erasing the setting first. The value will change in length so I am not sure if this is an issue.
@ NicholasR - You can call WriteEntry with the same name and different value multiple times without needing to call erase. It handles different lengths. The config in NETMF works by appending new entries to the list. It does not erase old entries. So when you write a new entry with the same name and same sized value, you are still using up more space. The existing space is not reclaimed. WriteEntry should return false when there is not enough space left. It is possible there is a bug in that functionality. If it happens again, read back the entire config region and send it to us. We can take a look at it.
@ Darren SFI - NETMF has some internal compaction mechanisms that are not exposed that run automatically. Once the region is completely full though there is nothing more to be done.