@ ianlee74 - Note that it’s not necessarily safe to shut off your NETMF devices with a power switch either; if you’re writing files to an SD, for example, you could end up with corrupted files. You’re right, though; boot up and shutdown times are a concern.
I think that a valuable area of research for the small-devices community would be a stripped-down Linux distribution capable of very fast boot, and which is safe to hard-power-off (by virtue of having no OS-level writable filesystem post-boot). I don’t think it’s impossible…
If you write single sectors continuously to an SD card with no caching, is it ever the case that more than just the target sector being written gets corrupted? If the answer is no, then it is possible to structure your data structures and writes so that a failure in any one write won’t result in loss of anything other than the file delta currently in progress.
And even if that isn’t true (dunno - haven’t tried it), or you can’t afford to lose even that last write, it would seem that there are hardware solutions too that could delay complete power loss for just long enough until your app reaches a safe-shutdown state.
It’s certainly not impossible to build a NETMF system that can be powered off at will without data loss - just not without at least a little hw or sw effort, and it seems to me that in NETMF (or other MCU OS’s) it’s easier to achieve that kind of appliance-like behavior in milliseconds to seconds where Pi requires a half minute or more to achieve.
XBox (which runs a windows kernel) and every other modern gaming platform seems to have figured it out
[quote=“mcalsyn”]
If you write single sectors continuously to an SD card with no caching, is it ever the case that more than just the target sector being written gets corrupted? If the answer is no, then it is possible to structure your data structures and writes so that a failure in any one write won’t result in loss of anything other than the file delta currently in progress.[/quote]
I don’t know how SD cards handle partial writes. I was thinking more of filesystem-level corruption, though. FAT is not a journaling filesystem, and it doesn’t take kindly to power loss. Really my point however was that it’s never safe to assume that a hard-power-off won’t break anything.
“never safe to assume that a hard-power-off won’t break anything” - absolutely agree. You must code for that case, on every OS.
using off-the-shelf FAT and expecting power-failsafe - not a winning strategy
If you want power-off failsafe, you need to write code specifically tuned to that goal. Even if you have a journaling filesystem, you still need to ensure that your app-level data structures are guaranteed to be internally consistent between co-dependent writes.
I’m pretty sure that with just software measures, you can create a power-failsafe NETMF appliance that does SD writes, though I have to admit to not having done it myself. I do have background in server-farm systems that do cacheless write-through and have to be instant-off safe.
I think I get your point, but I guess what I am trying to say is that the situation with NETMF is that the data-consistency problem is not substantially worse than other OSs, and yet (as others noted) the appliance-like start/stop performance is generally better.
But I wasn’t referring to running an app on NETMF that writes any data. Let’s assume it’s just a “Hello World” blinking program. With NETMF I can turn the power on/off as many times as I want and not worry that it won’t come up the next time. With an OS on a RPi, I can almost be guaranteed that more than a handful of these outages and I’ll have a corrupted SD card. Of course, there is a way to create read-only OS partitions or the better solution would be to add a button then have a service that watches for a button press and does a proper shutdown. However, this is all stuff that just makes it harder to work in that environment.
I’ve been looking at using one of these for power off which allows you to do a shutdown in a controlled manner when the user clicks on the power button but it does not remove the issue where the user simply unplugs the power from the unit. That requires a different approach, possibly a battery. If your device is critical in nature, you will use a small power source such as a rechargable battery or supercap that keeps power up for long enough to stop all file access and shutdown gracefully.
This is a push button controller for power ON and OFF. Also allows a press and hold off for times when your device has frozen. Similar to what you can do on a mobile phone.
I just finished a custom G120/G400 board with power down detection and backup power. A supercap of 0.47F holds enough energy to gracefully flush and close at least two open files with 32KB internal buffers. Things i discovered is that when the netmf file system is busy writing to SD card it can take up to 500 mSec before a power down interrupt is detected. Also important to keep in mind to setup such a system is that the power down interrupt handler has access to all open files and optionaly to all running threads to suspend them.
Nice one Rob. How do you detect the power loss? I was considering the same setup with a super cap on the main power out of the switching supply and a resistive divider on the input to this that would go to an interrupt pin and detect this going low. My initial thoughts on this are how to ensure this is a clean edge but don’t think that would actually matter.
The other issue is that a .47F cap or larger will look like a nice momentary short circuit on the output of the switching supply as it powers up. They normally don’t recommend large value capacitance on the output of these devices to ensure that they power up as per the specs. How did you get around this?
I use an analog comparator which is embedded in a SiLabs 8bit micro controller. The comparator generates an internal interrupt. The interrupt handler has a low pass filter in software to make sure a pulse is more than 20 mSec. Secondly very important the interrupt handler is going to send a number of pulses to the G120/G400… I have seen, that depending on what the G120 is doing an interrupt was not always detected when sending only one puls.
To keep the charge current limited i use a 22 Ohm resistor. So, a full charge takes about 10 seconds. During this 10 seconds of coarse the system is not safe for a shutdown. Important in the selection of the supercap is the internal resistance. Some have ESR up to 60 ohm.
Good find Steve but what a price. I love Linear parts but always find them very expensive in low volumes. That one alone is almost US$8 and a cheap 8 bit micro I can get for under a dollar. In saying that, I do like the features of this IC and it won’t require any addition programming steps.
I’ve just gone through the datasheet for that IC and I think I will use this for future builds where I need shutdown protection. For 3.3V in and out it is a simple enough setup.
To select a dedicated chip or not of coarse depends on the application. A simple power setup as in the image in combination with a 0.80 Euro MCU works well in my application. I selected this approach because i wanted/needed to solve some other tasks. The user reset button is also connected to this MCU and also interrupts the G120 to warn for a comming reset. Also to be able to (try to) flush/close files. Another functionality is when the G120 is connected to the PC via the USB and the reset button is pressed the MCU forces the LDR0&LDR1 lines low. This to be able to update tinybooter without opening the device housing… the MCU i used has a “unique” ID which is used to set the MAC address of the network interface. and a few other tasks…
Another important issue to keep in mind is to be able to switch off the power to an SD card if used. If, because of rest energy in the supercap, the power at the SD card doesn’t go below 1.5V between power down / re-power up cycle it wont mount.
