Save Custom Settings

LOL! Nice try! Shame it didn't work - That would have been an awesome hack!

Yeah, that was a smart idea. If you have a ND+ and never need to leave your local subnet, you could store 4 bytes in your default gateway, maybe?

If you have an ND+ you have built-in SD support, so it's probably less of an issue.

+1 for option 3... especially for the Mini

About storing data on the netduino w/o an SD card:

I just wrote a post about the DS1307 real-time clock which features 56 bytes of battery-backed RAM: http://fabienroyer.w...eal-time-clock/

It's not a lot, but perfect for config settings.

Cheers,
-Fabien.

Okay, option #3 sounds like a possible winner

We'll dig into it and make sure we're not exposing any nasty "gotchas". The space is very limited, and some of it is already taken (by the USB name, networking, etc.). My biggest worry is what would happen if the data were written only partially before a reset...and then the device might not be able to boot. Since the whole sector might have to be re-written all at once.

We'll dig into it. I'll post more when I have some good info...

Are there any news with regard to simple & small storage? I'm currently playing with ND+, so I could use the SD slot, but still, thinking about using ND mini for the final stuff.

Miha

Are there any news with regard to simple & small storage? I'm currently playing with ND+, so I could use the SD slot, but still, thinking about using ND mini for the final stuff.

Not yet. We're looking at the config sector, but we need to do some testing to make sure it's not easy to corrupt the important data that's there.

We've been doing some more research on this, and I have a quick question: How much room would you folks like for on-chip data storage? 400 bytes? 4 kilobytes? 8 kilobytes? It looks like we can implement this without using any of the currently-available codespace. But we might need to create some new block storage code. Chris

We've been doing some more research on this, and I have a quick question:
How much room would you folks like for on-chip data storage?
400 bytes?
4 kilobytes?
8 kilobytes?

For my current project 4k would be enough. But even 400 bytes would be better than nothing.

Rgds,
Miha.

Whatever's easiest for you guys to code. I think people could get by with just a small amount. It's those cases where you just need a couple of bytes for settings that are frustrating. Anything more than a few kb and it's probably worth adding SD or EEPROM storage.

Whatever's easiest for you guys to code. I think people could get by with just a small amount. It's those cases where you just need a couple of bytes for settings that are frustrating. Anything more than a few kb and it's probably worth adding SD or EEPROM storage.

I agree, even 1k would be enough for the projects I am currently working on as I am only storing some basic config data and maybe a serial number in the future. Anything more and we should be using other storage.

Of course if it is not a big deal to do 8k and it wont hurt your plans for the future then I say go for it. I am sure I can find a way to use it.

The biggest issue honestly is wear-and-tear on flash. Since we would store the data in the same place, it would need to be config data that didn't change very often. If you rewrote it multiple times every day, it would wear out in a few years. Rewrite it every minute and it would wear out that sector in a week or so. The ExtendedWeakReference feature in .NET MF takes care of that issue by caching the data in memory for a while before writing it out. But it's fairly complicated to use and has largely been deprecated. We could enable that as a backup option. Chris

The biggest issue honestly is wear-and-tear on flash.

I think that if you document this issue (basically it's a property of flash memory), we're good to go. In my case, the data is pretty much static. Otherwise, I would consider other options.

Regards,
Miha.

I think 1Kbyte is enough. Are there are any news?

There's a new feature (SimpleStorage) in .NET MF 4.2 that we're looking at leveraging for this. .NET MF 4.2 will be in beta soon, and then we can start testing the implementation. We've already reserved space for it with the current memory layout...so you won't give up any extra flash Chris

There's a new feature (SimpleStorage) in .NET MF 4.2 that we're looking at leveraging for this. .NET MF 4.2 will be in beta soon, and then we can start testing the implementation.

Hi Chris,

.NET MF 4.2 is available now. Does it include this capability? If so, how is it possible to use it? For my vote, with a hundred of bytes would be more than enough, for bigger data external EEPROM or SD would be justified.

Hi Dixon,

.NET MF 4.2 is available now. Does it include this capability? If so, how is it possible to use it? For my vote, with a hundred of bytes would be more than enough, for bigger data external EEPROM or SD would be justified.

We posted the first beta firmware for .NET MF 4.2 last week, and are now evaluating this integration.

There are two things we need to do:
1. Tweak any code which requires the empty EWR flash blocks--to not need the EWR code.
2. Change the EWR flash blocks to SimpleStorage flash block(s)
3. Create a C# driver (or file system driver) for the SimpleStorage flash block(s) -- for storage
4. Test the 4.1 TinyBooter with the EWR vs. SimpleStorage difference--to make sure there are no compatibility issues (i.e. we're seeing if we can make it so users with v4.1.x firmware won't necessarily have to upgrade their bootloader to v4.2.x).

Our first integration pieces are ADC and PWM (for the new object models) and misc. bugfixes--but this is the next item on the list after those. In the meantime, you can certainly store data on an SD card. [Also, the in-flash data storage will be for things like settings that don't change very often--not for constantly writing data.]

Chris

Our first integration pieces are ADC and PWM (for the new object models) and misc. bugfixes--but this is the next item on the list after those. In the meantime, you can certainly store data on an SD card. [Also, the in-flash data storage will be for things like settings that don't change very often--not for constantly writing data.]

Hi Chris,

I'm aware of the flash aging problem, I just need to write a static setting (around 10 bytes) that will be seldom modified with the config of the application, and that's why SD or EEPROM is an overkill. I don't mind if it's Simple Storage, EWR, or ADO.NET against and internal instance of SQL Server 2010 Micro Edition, I don't care if the performance is good or not, of if it requires 20K of RAM, as I have a lot of it I don't use.
I know there are many people that have more resource constrained applications and might not want to consume extra RAM or FLASH for this, that's why I think the best way to approach it would be as a module using .NET MF APIs so people can choose to include it in the project, or not and use external storage.

Whatever will be OK. Is there any way to access the FLASH memory rawly? If I can take ownership of a FLASH block and rewrite it by myself it will work. I can even use two and implement a corruption-protecting algorithm that writes alternatively on both so integrity can be checked at startup, and old version of the config will always exist.

Carlos.

Is there any way to access the FLASH memory rawly? If I can take ownership of a FLASH block and rewrite it by myself it will work. I can even use two and implement a corruption-protecting algorithm that writes alternatively on both so integrity can be checked at startup, and old version of the config will always exist.

You can do this via native code, if you'd like to dig into that. Check out the SecretLabs.NETMF.Diagnostics assembly and P/Invoked native code...it reads/writes data to the Configuration sector.

You can also use the SD card for now, while waiting for the SimpleStorage feature later this year.

Chris

    // set our IP address to a new value; this will be saved in the config sector and will survive reboots
    myNetworkInterface.EnableStaticIP("192.168.5.102", "255.255.255.0", "192.168.5.1");

If EnableStaticIP writes to flash, will each call to it write, or only if changed? Reason I ask is because I call EnableStaticIP in the NetworkAvailabilityChanged handler, and when a socket exception occurs.

Is this a bad idea? If so, what should be in the NetworkAvailabilityChanged handler?