On 4/14/15 9:06 AM, RussellMc wrote: > How do the available Flash-memory=20 > technologies/interfaces/protocols/standards/ implementations compare=20 > and is there a clear winner for embedded use?=20 If you can skip removable media and happen to use embedded Linux, bare=20 NAND flash with UBI/UBIFS is pretty good. UBI slows booting down by=20 seconds to tens of seconds, but it's quite safe as far as I can tell.=20 I'd suspect most SSDs from big vendors are fairly safe at this point, too. Removable media... well, if you have to work with customer-supplied=20 media then you're in trouble. You can work around this if you can add a=20 big cap / small supercap probably isolated just for the media and stop=20 new writes to the card immediately upon detecting brownout. Maybe you=20 could just put a FET on a command signal or clock and disable the=20 interface... it looks fairly convoluted to try to very quickly stop=20 writes at the Linux kernel level. This is more or less what some 'safe'=20 SD cards do internally. There's no telling if/when a consumer-grade card might decide to do=20 housekeeping... so possibly the only safe way to go is to find a=20 cap-based media card vendor and supply them to your users if it makes=20 sense. There weren't any cap-based power-failure safe SD cards in the=20 microSD form factor when I looked a year or two ago, but there were safe=20 full-sized SD cards available. This does require you to trust the SD=20 vendor to some extent, which makes me pretty uncomfortable. Even if you=20 test the cards... later batches could change. I'd like to try CF cards, as I suspect history has left them safer to=20 use... but I can't justify the redesign at this point quite yet. I can't be more specific as I haven't tested much beyond looking in=20 depth at my own issues. On 4/14/15 9:06 AM, RussellMc wrote: >> ... just one more way SD cards suck for embedded. It's a terrible standa= rd. >> > Does this apply to other flash cards - eg CF - which maps very nicely to > PATA. Well, historically no. CF cards were awesome in comparison... there was=20 no smart layer at all. I'm assuming you're looking at it from the CF cards in cameras angle...=20 and from that point of view I'd be pessimistic about their safety. It=20 may still be possible for it to be made safe, though... If the device=20 vendor works at it. Certainly the danger can be substantially reduced. The historical safety was because CF cards started earlier when the=20 media was NOR flash based. You had the erase limitations, but not the=20 massive bad block tracking headache that NAND flash gives you. Searching=20 around a little shows they have smart layers with wear leveling and use=20 NAND now (of course). (I'm not anti-NAND... it's a pain for bare metal stuff, but there are=20 plenty of solutions if you don't have an opaque transparent layer that=20 prevents you from addressing the issues... I use UBI/UBIFS and I'm=20 fairly happy with it) With CF I DO think there's a difference, though. (Although I am saying=20 this with ZERO recent experience) I suspect that you'd be much more likely to find CF cards that actually=20 detect the write pattern of very rare erases and very common writes into=20 pre-erased data (the 0xFF record format I mentioned before). If they did=20 this, then the cards in one step become massively safer to work with...=20 at least for the embedded use cases where that kind of write pattern can=20 be used. I believe the CF cards would be more likely to support that pattern=20 because it used to be a hugely common pattern for CF usage. After all,=20 some variant of that pattern was about the only way to write frequent=20 updates to NOR flash safely. SD cards were just about always used with=20 PC-class filesystem drivers that didn't easily map to that pattern. The=20 intention is also more explicit in the CF interface spec itself. I found an old SanDisk CF data sheet for an early NAND-based CF card=20 that implies it could be used safely... but it's ambiguous. It says=20 performance could be increased if sectors were pre-erased before writing=20 (which sounds positive), but it explicitly says the "WRITE WITHOUT=20 ERASE" command is ignored and treated as a standard "WRITE" command, and=20 the explicit "WEAR LEVEL" command is handled with a NOP as wear leveling=20 is done automagically. So, maybe there's a specific pattern you could=20 use with that card and that vendor, but it may not be the same pattern=20 with someone else. I considered writing a custom fully use specific FAT-32-ish filesystem=20 that would really do the 0xFF raw disk trick but organize stuff in such=20 a way that it would present all the correct filesystem metadata to=20 another operating system if the media was pulled and put in an external=20 computer. Updating metadata daily would probably work to reduce how much=20 extra pre-erased data you presented to the filesystem interface. You=20 could make it much safer that way but it would still be difficult to=20 make it 100% reliable. I can kind of imagine the rough pattern of how you might take a=20 transparent wear-leveling card that DOES detect when not to erase and=20 build a 100% reliable system on top of it. It'd be hard to make it=20 vendor independent, but it's probably possible. TLDR? :) Darron On 4/14/15 9:06 AM, RussellMc wrote: >> >> ... just one more way SD cards suck for embedded. It's a terrible standa= rd. >> > Does this apply to other flash cards - eg CF - which maps very nicely to > PATA. > > This seems to be a case where a "dumb" controller where the user must get > involved in the low level housekeeping is > > potentially superior to 'high level' interfaces. > > How do the available Flash-memory > technologies/interfaces/protocols/standards/ implementations compare and = is > there a clear winner for embedded use? > > (Answers should be detailed and not more than 100 words, Use of Sanskrit > optional). > > > Russell --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .