We’ve been using G120 for many years now, and encountered a problem upgrading to TinyCLR 1.0 from Netmf. There were no longer any built in support for configuration data or working with the internal flash and the chip.
I covered this on this post: https://forums.ghielectronics.com/t/netmf-to-tinyclros-writing-to-flash/22107
The workaround that I got offered actually worked nice.
So now SC20260: I am evaluating this chip for us to (hopefully) start using it instead of G120 in our products and everything seems to works fine. That is, except storing to internal flash.
Is there any new way to work with the internal flash? Is it possible to map up TinyFileSystem to work with a file stored directly on the internal flash? (Anything from a couple of bytes to a few kilobytes would be helpful). As of now we are just storing about 10 bits, setting different settings for the system depending on customer configurations.
If possible it would also be nice to be able to store usage logs that we can look at in case of a machine failure for us to follow up.
That scenario would of course mean constant writing to the flash. Would that be possible to do with the internal flash?
Since this is a prototype, maybe I better ask the engineers to solder an SD chip on the PCB instead?
So I finally got around to “look right into it” (now with the finished 2.1 and not a RC version) and found what seems to be a major issue with this feature.
I can’t write to the configuration space unless it is empty first. And I can only erase all blocks at once, not single blocks, and this takes time to do.
So if I want to change a specific byte in a specific block I first need to read all the blocks to a buffer, change the specific byte in the specific block in the buffer, and then write them all back again?
This code generates error if the configuration space is not empty:
var f = new byte[32];
var configStorage = new SecureStorageController(SecureStorage.Configuration);
configStorage.Write(0, f);
→ An unhandled exception of type ‘System.ArgumentException’ occurred in GHIElectronics.TinyCLR.Devices.SecureStorage.dll
but this works:
var f = new byte[32];
var configStorage = new SecureStorageController(SecureStorage.Configuration);
if (!configStorage.IsBlank(0)) configStorage.Erase();
configStorage.Write(0, f);
I need to save config data fast at specific times. If it will take a second to save the data because I have to erase the entire flash every time then it is unusable. In case of power outage I cant save the data in memory and save it to flash at a more convenient time either.
Yes because if you want to write where data is already exist, then yes, you have to erase all.
No because, if you write on empty block, no need erase.
You wanted to write block 0 all the time so yes, you need erase.
It depends on how large data is, you can detect which block empty and write to it. If no more block free then, of course, you have to erase, instead of erasing every time writting.
Hmm, ok.
This was not the case with the “Monoculture.TinyCLR.Drivers.G120EEPROM”-workaround for G120 and TinyCLR 1.0.
This seems like a step backwards.
I only need a few bytes, so I can write in a new block every time, no problem. It just feels like an ugly solution.
Hi Dat,
I’ve started using this solution for configuration storage on one of our products where 4K of memory isn’t a huge concern - how long can I expect the the battery to last if it’s just keeping the RTC memory alive? It’s mostly just for my knowledge so we can include a battery replacement interval for our customers.
