G400D does not have Battery Ram to store user parameters. I used to implement an EWR solution with EMX but had a lot problems in terms of reliability. Is it better now?
What is the max size of EWR for the G400D platform?
the Flash Sector Map returns:
[quote]
Sector Start Size Usage
0 0x00000000 0x00008400 Bootstrap
1 0x00008400 0x00018c00 Bootstrap
2 0x00021000 0x00262800 Code
3 0x00283800 0x00010800 Application
4 0x00294000 0x00168f00 Deployment
5 0x003fcf00 0x00010800 Storage (A)
6 0x0040d700 0x00010800 Storage (B)
7 0x0041df00 0x00002100 Configuration
8 0x00000000 0xd6700000 File System
9 0x00000000 0x77a00000 File System[/quote]
Does this means that EWR can’t be greater than 10.8 kilo-bytes?
To GHI team do you think it will be possible to bypass EWR and adress directly storage A and B flash section (maybe using RLP)?
the mfdeploy tool returns:
Pinging… .
TinyCLR
Memory Map Command
Type Start Size
RAM 0x20000000 0x08000000
FLASH 0x30000000 0x00420000
Memory Map Complete
I do not understand theses results
@ leforban - Storage A and B are both 66KB in size, but they are used by EWR. While they are normal flash regions you could in theory write to from RLP, there is no guarantee what NETMF does with the sectors internally so any data you put there would not be reliable.
The memory map command just tells you the RAM and FLASH region addresses and sizes. It isn’t useful for what you’re asking.
EWR is not really meant to be a reliable data store. Weak references are references to an object that could be garbage collected under memory pressure as you are able to quickly recreate the object if needed. Extended weak references on the other hand just extend that concept by persisting the data to flash.
We are looking into ways to give the user access to some flash space for storage, but we do not have anything specific just yet. So for now, until and if we implement such a system, your best bet is to use an SD card or other external storage device.
when you say EWR is 66k you are meaning 66k-bit right? I tought there’s a convention lower case b for bit and upper case B for byte :whistle: anyway…
You say that EWR is not a reliable data store but just after you are saying it persists data to flash… I am expecting that if data persists then it’s reliable but last tries on EMX and 4.1SDK was showing that this was not the case.
I am already using SD but speed might be an issue. In my project, the system may have up to a thousand of float to save… I will try to serialize a float array (size about a thousand) and see if it is an issue or not.
Most of those values are not changing so maybe an external SPI flash memory might be the solution
@ leforban - I meant kilobyte.
While it is true that EWR currently persists to flash, that is an implementation detail that you shouldn’t rely on. My take on the goal of EWR comes from the fact that is derives from the WeakReference class and it can return null as part of its design. Those seem to imply that you should not rely on the data being present 100% of the time. Looking in the comments of the EWR sample, Microsoft even says in a comment “The CLR should try to persist data across a reboot.”, meaning it might not persist.
But it is not our API, so I cannot say for certain how it is to be used.
Ok so let’s move to SD or flash. Just to be not an idiot: in Fez config, size for storage A and B are reported to be 10800. I thought it was 10800 bytes so 66 kbits and not kbytes… Am I miss something?
@ leforban - It’s 108000 in hex which is 67,584 bytes in decimal.
grrr each time I fail in computing memory space… :wall: