I've been following this thread with great interest.
There are many PC104 devices on the market that use a flash, or similar, card in place of a hard drive.· Since these things are basically computers, does this 'short-lifetime write cycle' mean that these things would die relatively quick?!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·
Steve http://members.rogers.com/steve.brady "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
If they 'bang' the hard drive the way Windows does when running lots of large applications (with swap space, etcetera) then yes, I would assume they would die fairly quickly.
However, usually these things are running program which read out of the FlashCard once, then run in the dynamic Ram of the board. Sometimes, they write log files back into the Flash. As embedded systems, they should work quite well. But they would not be good replacements for a desktop which reads and writes lots of files all the time -- unless you're willing to replace the flash card fairly often.
As others have said, 'bad sectors' on the flash-card will get mapped out, meaning your 'flash disk space' will drop until you are out of useful space. But as I said, on an embedded basis this is not usually the scenario you run into.
·· The write cycles are per cell...So you would need to write the entire card over 100,000+ times to deplete it's life span.· Writing to an individual cell or block repeatedly would be the same thing.· Hence, you should use this type of memory as a RAM substitute.
Yes, I know.· I was referring to the use of an additional EEPROM to buffer the 512 bytes, as was either suggested or mentioned as being used already in a design for sale.
If each block is buffered into the EEPROM before writing to the MMC, and given that a 128MB MMC has 262,144 blocks, then the life expectancy of the EEPROM is exceeded by the time the MMC is filled just once.
·· In reply to your post, Mike, I was going to mention that buffers are usually SRAM...Not having a max write lifetime.· Perhaps I missed the post referring to it as EEPROM.· Since I have been a member of these forums, and the Yahoo Group before it, I have seen many cases where people had been using the EEPROM as NVRAM for real-time applications, and were getting errors.· It's no surprise that if you're writing data once or more per second, it will be a short life for your EEPROM.
I've been working (very slowly) on building a data logger to SD/MMC cards, too (run by a Scenix controller, not the stamp) and I'm curious about this bad block remapping. Maybe some of you can answer this.
Suppose i've been doing lots of logging and unknown to me, the card internally has been detecting and silently remapping spare sectors into the user-available memory. I assume that there are some sectors in the background that may be used at first, but what happens when there aren't enough useable sectors to replace the number that is initially provided to the user?
Will my memory accesses just all seem to succeed until all of a sudden, I'll get write errors on specific sectors?
Or will the card rewrite its CSD register to indicate the smaller available number of sectors, and continue to provide me with a smaller but linear address space of good sectors?
And FYI, the cards I've been experimenting with don't contain a full 16M or 64M of data space, even though that's what they're marked. My 64M MMC card, for example, instead of 131,072 blocks like you might expect, has only 125,440. This number is stored in the CSD register of the card and I've verified it by getting a read error when trying to access sectors greater than that exact number but successes from address 0 up to it.
Typically bad block management is not specified by a card specification (you can check out the SD/MMC specs to see if they do) so a vendor is free to provide thier own method. The cheapest and most used method is to reserve a portion of the card for marking bad sectors and also reserve backup sectors to be mapped in place of the failed sectors, so this could account for your lost capacity. So your perceived capacity will remain the same until all backup blocks have already been mapped as replacements. Can you explain what the CSD register is, I don't feel like trudging through the specs at the moment.
Trudging is the right word! I agree with Kroki - the manual is not the easiest thing to read. There are still some things I don't understand, even after many readings of the thing.
But the CSD register isn't too bad. You issue a particular command to the card, and it responds with 16 bytes of data. You decode them to get about 30 fields of things like bytes per block, total user-accessible blocks, max erase block size, whether a write can cross block boundaries, etc.
All I've really done with it so far is get the card sector count.
Comments
There are many PC104 devices on the market that use a flash, or similar, card in place of a hard drive.· Since these things are basically computers, does this 'short-lifetime write cycle' mean that these things would die relatively quick?!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
http://members.rogers.com/steve.brady
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
However, usually these things are running program which read out of the FlashCard once, then run in the dynamic Ram of the board. Sometimes, they write log files back into the Flash. As embedded systems, they should work quite well. But they would not be good replacements for a desktop which reads and writes lots of files all the time -- unless you're willing to replace the flash card fairly often.
As others have said, 'bad sectors' on the flash-card will get mapped out, meaning your 'flash disk space' will drop until you are out of useful space. But as I said, on an embedded basis this is not usually the scenario you run into.
If each block is buffered into the EEPROM before writing to the MMC, and given that a 128MB MMC has 262,144 blocks, then the life expectancy of the EEPROM is exceeded by the time the MMC is filled just once.
Mike
·· In reply to your post, Mike, I was going to mention that buffers are usually SRAM...Not having a max write lifetime.· Perhaps I missed the post referring to it as EEPROM.· Since I have been a member of these forums, and the Yahoo Group before it, I have seen many cases where people had been using the EEPROM as NVRAM for real-time applications, and were getting errors.· It's no surprise that if you're writing data once or more per second, it will be a short life for your EEPROM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--==<{Chris}>==--
Suppose i've been doing lots of logging and unknown to me, the card internally has been detecting and silently remapping spare sectors into the user-available memory. I assume that there are some sectors in the background that may be used at first, but what happens when there aren't enough useable sectors to replace the number that is initially provided to the user?
Will my memory accesses just all seem to succeed until all of a sudden, I'll get write errors on specific sectors?
Or will the card rewrite its CSD register to indicate the smaller available number of sectors, and continue to provide me with a smaller but linear address space of good sectors?
And FYI, the cards I've been experimenting with don't contain a full 16M or 64M of data space, even though that's what they're marked. My 64M MMC card, for example, instead of 131,072 blocks like you might expect, has only 125,440. This number is stored in the CSD register of the card and I've verified it by getting a read error when trying to access sectors greater than that exact number but successes from address 0 up to it.
David
But the CSD register isn't too bad. You issue a particular command to the card, and it responds with 16 bytes of data. You decode them to get about 30 fields of things like bytes per block, total user-accessible blocks, max erase block size, whether a write can cross block boundaries, etc.
All I've really done with it so far is get the card sector count.