| 1 |
On 30/03/2010 19:11, wireless wrote: |
| 2 |
> Ed W wrote: |
| 3 |
> |
| 4 |
> |
| 5 |
>> In addition to what everyone else has already noted you really need to |
| 6 |
>> state your tradeoff between lifetime of the flash cards and minimising |
| 7 |
>> the risk of loosing data. |
| 8 |
>> |
| 9 |
> |
| 10 |
> Wow, this sounds like a PC programmer's statement and not |
| 11 |
> how an embedded designer would solve the problem. Granted |
| 12 |
> the poster has not provided and adequate 'specification' so |
| 13 |
> my point of view may or may not be precisely applicable. |
| 14 |
> |
| 15 |
|
| 16 |
|
| 17 |
...snip... |
| 18 |
|
| 19 |
I don't disagree that you can design the system to loose power or crash |
| 20 |
less frequently, but I don't see how this undermines or disagrees with |
| 21 |
my statement? |
| 22 |
|
| 23 |
Essentially you can buffer more data and hence risk more in the case of |
| 24 |
a crash/power loss, or you can write more frequently which will decrease |
| 25 |
the life of a write limited medium. I don't see how you have changed |
| 26 |
that basic trade? |
| 27 |
|
| 28 |
The engineering solution is to set things to balance write frequency |
| 29 |
such that the media lasts "long enough", then as you say tackle the |
| 30 |
other side and make the device crash/loose power less frequently. |
| 31 |
|
| 32 |
Based on the nature of the post I assumed that the OP wanted advice on |
| 33 |
tackling the software side... |
| 34 |
|
| 35 |
Regards |
| 36 |
|
| 37 |
Ed W |
Archives