Been away for a while busy with customers not development
The people here at the office is ecstatic about ras pi and all the stuff we can do with it at low cost (development time ). Being a hardware guy myself, used to working on systems that need to be stable, and when it cost 10k$ to just change a device in the field I am a bit sceptic using the PI to much more than playing around.
I defiantly see the benefits (been testing a 5-6 units running Linux now) and flexibility and we can drastically cut hardware development costs using the PI.
What we have had problem in our testing is the SD cards, they tend to go corrupt if you have power failure or run too much on your system.
How does Win10 handle the SD card, is all core run from RAM when booted or does the OS also write to the SD Card?
My other questions what are your thought on using the PI for more then fun?
This issue has been my main concern / problem as well. Not only on the Pi but every other embedded Linux board I have tried.
I have posted this very same question in a few other forums with surprisingly little response back from it.
In my endeavor to try to see how the professionals in embedded Linux do it, the best I have been able to read about is when the device is booted it copies the contents from the SD card to ram, then runs from ram. I am no Linux guru, so exactly how to do that is beyond my knowledge in Linux.
Depending on the nature of your product, you should be able to build your Pi OS on a read-only filesystem. No idea if or how this will work with Win10 on the Pi. Here’s a thread where I explored this about a year ago…
The RPi1 was available as a SODIMM module for exactly that sort of application, and I’ve used that device a couple times. The SODIMM made it possible to create devices with much nicer form factors than allowed for by the default edu-focused board.
The RPi foundation rarely announces anything in advance, but there has been a lot of call for them to produce an RPi 2 compute module. No idea when, but it seems likely one will come along.
As for longevity concerns, I doubt you’ll get such guarantees from RPi Foundation as industry-related concerns are not really central to their mission. So, you “spends your money and you takes your chances”, but they do have a good track record and a massive customer base. The sheer volume of their sales would seem to predict a certain amount of longevity. The main risk is probably product-line churn. Again, the sheer mass of their customer base probably offers some insurance against capricious changes. That’s all speculation on my part, of course.
One of the things that surprised me was how rarely the Win10 IoT image seems to hit the SD card after startup. I could only induce it to do so when loading a file or changing a persistent config option (like the admin password). A stable running system doesn’t seem to hit the card at all. I don’t have any hard statistics other than the blinky light, and that hardly qualifies for calling it truly mem-based, but it does seem pretty well behaved in this respect. I’m still poking around for specific statements by MS on how SD card access has been optimized.
The Pi is likely to be available at least as long as GHI’s products.
No, that’s not what he said at all. There’s nothing special about SD cards, as you could use a spinning disk and still experience corruption if you power down the system at the wrong time. The problem isn’t with SD cards (or even hard drives or any other storage medium), it’s with filesystems and operating systems that can corrupt data when power is cut at the wrong time. Linux has this problem unless you take special measures to prevent it (i.e. run from a read-only filesystem), as does Windows 10, in all likelihood.
[quote]What we have had problem in our testing is the SD cards, they tend to go corrupt if you have power failure or run too much on your system.
How does Win10 handle the SD card, is all core run from RAM when booted or does the OS also write to the SD Card?[/quote]
So then the answer to the original poster is:
Yes, of course that will happen, as it would on any computing platform.
@ Mr. John Smith - Well, no, not really. I guess it depends on what you define as “computing platform”. Most embedded systems are designed specifically to survive these types of hard resets and power loss events. Desktop operating systems, on the other hand, are generally not designed to handle non-graceful shutdowns.
Unfortunately, it’s not really that simple, though. Embedded systems can be implemented in such a way that they are NOT safe to power-off, and many desktop operating systems can be implemented or configured in such a way that they are. “Safe to shut down at any moment” is a design feature that needs to be considered at every level, if it is desired.
In an industrial scenario, you have to assess the risk of something going wrong, and the impact if it does, when designing your engineered solution. If you have massive cost and damage if the controller goes offline, you go to great lengths in your solution design to protect against that. If you have minimal impact then you don’t care much about that. Seems to me this might be a situation where the original poster might be interested in hearing from others who have engineered a solution with a Pi as the heart of it - my personal view is that you may not find a critical mass of people here who have done that or even thought about it, and you may need to branch out to an area more specifically focussed on that kind of engineering work. Don’t get me wrong, there are some great contributors here who do similar things with GHI and custom hardware that could contribute as well, its just the unknowns that will likely trip you up (the unknown about what “industrial” really means to your scenario, as well as potentially lack of real world detail about Pi in these scenarios)
I have had problems with SD card corruption using in an industrial Win CE application. I was using the SD card to store the application and database files. (FWIW, I couldn’t get it to fail during development. Failures were all in the field.) The short term resolution in this particular application was to use the internal flash memory. My guess is that the writes complete much faster than they do to the SD card, thus limited the amount time where corruption could happen.
I do need to find a long term solution. There are only 2 solutions I can think of.
1 - Battery backed RAM to buffer writes to the SD card. If power is lost during a write the data is still available and flushed to the disk on next power up. For Linux, Win 10, Win CE it would require driver level support and Battery backed RAM which is increasingly rare on these systems.
2 - The most likely solution is an internal UPS (uninterrupted power supply) that holds power long enough for a graceful shutdown. I haven’t been able to find any such device for standard embedded hardware (Pi, Beagle Bone, etc.). It’s not even found in other off the shelf Linux/Win CE boards or single board computers. For industrial temperature range (-40C to 85C) battery technology becomes an issue. Super Caps are probably the best solution.
Doing a UPS circuit for a .NET MF board should be pretty easy. It is on my “to-do” list. I would like to use the SD card for SQLite but I am reluctant until I can guarantee a safe shutdown of the file system.
I guess it would be nice if we had an sd card that implemented Reed-Solomon error correction. I’d gladly pay 2x the normal cost of an SD card, if I knew it was even 30% more fault tolerant. Pity nobody around here can design and build such a system into an SD form factor :whistle:
See guys; I’m not always a crazy troll guy. I guess the proof of concept will be in reprogramming those eyefi cards, re badging them as fault tolerant and selling em on.
@ Mr. John Smith - SD cards already use error correction (ECC and/or BCH codes, at least). Furthermore, error correction won’t solve these kinds of problems, because they’re not caused by data being written incorrectly, they’re caused by data being written incompletely; that is to say, the card was left in an inconsistent state because only some of the data was written.
Some filesystems are designed to handle this gracefully, some aren’t. FAT as is commonly used on SD cards is definitely not.
Android phones run Linux. I have often wondered how our cell phones manage to not get bricked. You know with all the android phone users out there yanking batteries before doing a proper shutdown how the cell phone manages to reboot ok after the battery is replaced.
Well there are certainly strategies for maintaining always-valid disk state. I’ve done a number of data-center apps that used hardware write-through to the physical drives and we had to be very conscientious about the disk state always being valid or recoverable.
Data consistency guarantees aren’t baked into the SD card stack because you have to have some idea of the write semantics of the app. Android, iOS and Winphone can ensure boot safety by making sure there aren’t any states between write completions that leave a system unbootable, but it’s still possible (and easy even) to screw up in the app domain on Android, iOS and Winphone and leave your app in a bad state. There’s no way for any OS to guarantee against that because only the app author knows what constitutes data consistency.
We can employ the data consistency tactics in NETMF apps - it just takes more work when writing your app. Never overwrite essential files - write to a new file and then execute two renames and a delete followed by a flush. That way, no matter when the power is pulled, the persisted state is always valid or recoverable. In linked lists, write new blocks, then update pointers, then flush.
This is all a matter of doing stuff in the right order and having some amount of redundancy, and rollback/fallback plans. There’s nothing magical in Android base firmware - we just aren’t always employing enough of these strategies at the app level.