Timeline for EEPROM or SD card storage for a general logger application?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 2, 2014 at 17:24 | comment | added | supercat | If a bit that would mean "use the new location" gets half-written, a controller might on one occasion see it as having been written, and thus mark the old location for recycling. If on a future occasion it sees that bit as not having been written, however, code would try to read the data from the old location which is now being used for something else. Oops. | |
| Oct 2, 2014 at 17:21 | comment | added | supercat | Another issue is power supply reliability. If power is lost while writing to an EEPROM, data in the part of the chip being written may be arbitrarily corrupted, but other data on the chip will be fine. By contrast, power loss while writing an SD card may corrupt data which was, from a "user" perspective, not being written. SD cards use "wear leveling" algorithms which periodically move data around the chip. A good card should be designed so that at all points during a move, each piece of data will always be recoverable from either its old or new location, but that can be surprisingly hard. | |
| Dec 31, 2012 at 16:31 | comment | added | Gustavo Litovsky | @ChrisStratton: Let me go point by point: 1) SD Cards do cost more 2) They don't necessarily take more to support. You still have to organize the data in the EEPROM, as well as create code to be able to extract the data using the system itself. I argue this is the same, sometimes less sometimes more, the effort needed to support SD Cards (for which code already exists). | |
| Dec 31, 2012 at 16:15 | comment | added | Chris Stratton | @GustavoLitovsky cost per byte is only relevant if you need more bytes than are in the base unit cost. SD cards cost more at a minimum (unless you make the customer source them, but then you need an opening in the housing), and take more to support. But when you need more than a handful of megabytes, or need removability, they do indeed start to look attractive. | |
| Dec 30, 2012 at 20:09 | comment | added | Gustavo Litovsky | @jippie: You're correct, and the OP didn't specify the microcontroller, but FATFS is freely available and has already been ported. It should not be that difficult to get it to run. In fact, if you look at how to organize the data without the file system, it becomes a nightmare. | |
| Dec 30, 2012 at 20:08 | comment | added | Gustavo Litovsky | @Swanand: Cost per byte is much lower on the sd card. it's probably $1 per GB or less, whereas EEPROM is much much greater (several orders of magnitude i'd say) | |
| Dec 30, 2012 at 19:50 | vote | accept | DomingoSL | ||
| S Dec 30, 2012 at 19:28 | history | suggested | Peter Mortensen | CC BY-SA 3.0 |
Copy edited.
|
| Dec 30, 2012 at 18:39 | review | Suggested edits | |||
| S Dec 30, 2012 at 19:28 | |||||
| Dec 28, 2012 at 9:56 | comment | added | jippie | @accessibility => for that to work, you need to use a proper filesystem on the SD, which requires quite a bit of software on the controller to implement. | |
| Dec 28, 2012 at 5:11 | comment | added | Swanand | I would add, Cost! Cost of EEPROM is lesser than SD Card... That would be only disadvantage of SD Card, if I ignore implementation time/efforts. | |
| Dec 28, 2012 at 0:50 | comment | added | Gustavo Litovsky | They do, that's right, but it usually averages out if you write big chunks since it's also very fast. Perhaps he can buffer a certain amount and write all at once. That will definitively help with power consumption. | |
| Dec 28, 2012 at 0:41 | comment | added | Toby Lawrence | SD cards can have high peak write current. The OP didn't mention it, but run-time of the device might be a concern here. | |
| Dec 28, 2012 at 0:34 | history | edited | Gustavo Litovsky | CC BY-SA 3.0 |
Added link to FatFs
|
| Dec 28, 2012 at 0:29 | history | answered | Gustavo Litovsky | CC BY-SA 3.0 |