How many EEPROM read/writes? Really?
Oldbitcollector (Jeff)
Posts: 8,091
I'm considering an update to PropDOS that supports command-line loading,
but I'm debating on writing the file to the SD or EEPROM.
I know that both media types have a limit to how many times that
they can be re-written, but IIUC it was 10,000-100,000 times.
How many times can I truly write to the EEPROM before I run
into the limitation? Any real data exist on this?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
but I'm debating on writing the file to the SD or EEPROM.
I know that both media types have a limit to how many times that
they can be re-written, but IIUC it was 10,000-100,000 times.
How many times can I truly write to the EEPROM before I run
into the limitation? Any real data exist on this?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
Comments
www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en025550
Because it's all statistical you'll never get an absolute answer. Better people than me may be able to take the data and turn it into a figure which is a minimum you are almost certainly going to get before failure and a figure where it will almost certainly have failed by.
"1,000,000 erase/write cycles guaranteed"
So the same EEPROM should work for some years for the sporadic commandline writes.
But why you don't use the RAM for the commandline? I have an OS which uses the MainRAM at $7FF0..$7FFF for passing a commandline. This is enough for a 13 byte filename and 3 option characters. The startet Application reads first the commandline at $7FF0 and copy it to a byte array, then the RAM at $7FF0 can be reused for a screenbuffer or something else.
Perhaps we can define a standard for such commandline passing, so that all Propeller OSes works the same way and are compatible in starting Applications.
Andy
Andy, couldn't agree more about the creation of a standard for this..
But I'm curious.. The current "SPIN" command executed by PropDOS & Femto does a REBOOT.
Will that memory location stay intact?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
I prefer to use the SD card because its replacable, and the PROPs eeprom isn't (as easily)
also, the way were using SD cards means that if we do kill a few bits in time, the rest of the card will probably still be accessable. so you could concievably recover your data and put it on a new card. with the low cost of SD's at the moment, they are almost disposable. The only real other way to do it that I can think of is some seperate ram system.
If the Prop system your using uses an external real time clock with extra ram, you can store your data in that, because a real time clock, in theory, is always powered.
maybe we should start a propeller standards thread? we could define some 'standard' pin uses, image/video/audio file formats, file extensions, OS system protocols. I'd love to help out with a project like this. any volunteers to head up the standards project?
*lick* one, *lick* two, *CRUNCH*, three
it takes three licks to kill an EEPROM
I'd suggest we start something on the Propeller Wiki as we can all contribute.
The fact that the Propeller being so open from any standard is both wonderful & painful.
The "openness" has lead to all kinds of discovery that might have been missed, but
at the same time, if we could come to a mutual agreements about a few issues, it would
make it *much* easier to code for the masses. As long as we don't close ourselves off
to new discoveries.
OBC
Edit:
Is this your setup? Sound interesting, tell more...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
Yes, the Femto-Binary-Starter reads the whole binary in the MainRAM starting at address 0, and clears then the Variable area. All the Memory behind this stays intact, as long as it is not overwritten by the stack. So if you write the commandline just before starting the new binary, and then the startet Application reads the commandline at the begin, before using a big part of the stack, this kind of commandline passing should always work, also if the new Application uses nearly 32kByte.
For a standard we need to define the maximal size of the commandline, and the location. And also a "magic number" for testing if a commandline from a compatible OS is passed.
For my OS, I also have defined 2 other areas: One for a System-Configuration, and one for the parent Application.
- The configuration defines many Parameter, like TV,VGA Display and Pins, SD card Pins, Input Devices and Pins and so on. This enables Application which works on different platforms and Pin configurations.
- The parent, or calling Application defines to what Application the new startet Application should return, when finished. So if you start it from PropDOS it returns to PropDOS, if I start it from my OS it returns to my OS. If an Application is not able to return to the Parent Application (because no SD driver is involved), then a reboot executes the binary in the EEPROM.
My definitions so far:
$7FD0..$7FDF = Parent Application (filename as zero terminated string + 3 bytes reserve)
$7FE0..$7FEF = Configuration (first Byte = $55 as Indicator for a valid configuration, and a passed commandline)
$7FF0..$7FFF = Command Line (first a zero terminated String with max 12 characters, then 3 singel characters for options)
The ideas was to use as little memory as possible, thats why the commandline is only 16 bytes. I never want to pass more then 1 filename in the commandline so far, but for a standard we need perhaps a longer commandline?
Andy
Post Edited (Ariba) : 6/21/2008 1:14:42 AM GMT
I have a default system configuration also as a file on the SD card. If no configuration is passed in RAM, this file is used.
Passing all over the SD card is also an option, I think modern SD cards are intelligent and uses always different sectors inside the Flash also if you write the same File again and again. So the writes to the same physical sector in the Flash are minimized.
The advantage of passing commandlines by MainRAM is, that the started Application don't need to include an SD filesystem!
Andy
Post Edited (Ariba) : 6/21/2008 1:28:16 AM GMT
In particular it was a datasheet on the low, low, low end USB thumb drives. Both myself and a friend of work tried a few of the 1GB drives from ?icro?enter (not mentioning names), and so far have had two fail. Not even a ton of use on them. Luckily I only treat them as a way to move files and not to store only copies them. After pulling a dead one apart I looked up the data on the flash chip it used. That particular one was rated in the thousands of writes. Also, the shelf like wasn't all that spectacular either.
Granted they will give you a free one if it dies but I feel sorry for the people who don't realize that they can easily lose their data on them and they must keep other copies to be safe.
Definitely check the datasheet for the actual chip used and use that as a guide.
EEPROMs are intended to be used without a fancy controller, so it's more important to have a large number of writes available since things can't be relocated to another part of the EEPROM.
I think the OS does that, not the card.
Every time files move, they need to write on sectors that don't move, to find the files.
That writes the same sectors even more than if files write over themselves,
and if those sectors go bad, you can lose all the files, not just one.
I plan to. Just waiting for my crystal to arrive. I have a PCF8583 real time clock. its I2C and has 240 extra bytes of auto-incrementing ram, more than enough for a command line.
everyone else:
I am gonna start a new post about standards so everyone can all throw in their ideas, and we can come to some ideas about what standards to document
Post Edited (vampyre) : 6/21/2008 4:07:43 AM GMT
time/date stamps to FSRW, as there is already a section set
aside for it with a hard-coded timestamp.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
but, i've started a PROP standards thread i'd lke all of you to have a look at if your interested in the subject
http://forums.parallax.com/showthread.php?p=732725
OBC:
Would be great to have everyone use a RTC. They aren't expensive, and the extra lil bit of ram would be helpful, even if a bit slow.
Having a calendar and a time base is suprisingly useful, i dind't realize how much i loved the clock in my PC till i started playing with a clockless system. perhaps you could add it to your cookbook? I think I speak for more than myself when i say its the poor mans prop bible.
Probably not. The workround is to not do a RESET but stop all Cogs, load RAM, clear RAM ( vars and stack ) as necessary, leaving needed RAM intact, then restart the Cog 0 Spin Interpreter. Same end result but under program control.
It shouldn't be too hard to implement the above. It can be placed at the top of RAM on a genuine boot-up or reset, protected thereafter by the mechanism itself. If this code were at $7F00, REBOOT simply becomes "word[noparse][[/noparse]$000C] := $7F00, CogInit(0,$F004,$0004)". It makes the very top of RAM unusable for the OS and overlays but I don't see that as a major problem. The code can be placed anywhere in actual fact if there are drivers (TV?) which want to use top of RAM etc.
You can hi-jack my threads anytime.. I see it as evolving discussion, and as long
it's about the Propeller, it's right on topic. (Other opinions may vary.. [noparse]:)[/noparse]
Where did you order that clock chip from? PART#?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
Nope, it's the card not the OS. A majority of CF cards, USB keysticks and other flash based devices have some kind of wear leveling at the firmware level. None of the common OS file ystems in use provide any kind of wear leveling. If you are using jffs2, logfs or similar then you can get a wear leveling type of effect, but it's still only very basic. The wear leveling used in the firmware of the memory modules can be quite comprehensive. Of course its in the manufacturers interest to get it right as it makes their memory more reliable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!