Hi Tom,
One thing that I'd like to know is, how does it store the allocation table?
That must be in flash too, or maybe EEPROM where cells are not paged, but
they still have a write-cycle lifetime.
They cheat! :> What you think of as the "FAT" is actually stored in
RAM (!) It is recreated at power-up by the controller (or "processor"
if you are using bare flash). This involves *scanning* the contents of
the FLASH device and piecing together *distributed* bits of information
that, in concert, let an *algorithm* determine what is where (and which
"copy" is most current, etc.)
When you think about storage devices with non-uniform access
characteristics (in this case, much longer write times than
read times, durability, etc.), you can't approach the problem
with conventional thinking (well, you *could* but you'd end up
with really lousy implementations! :> ).
Think of how you would implement a *counter* in an EPROM, bipolar
ROM, etc.
For simplicity, assume an erased device starts out as "0".
So, a byte starts as 0000 0000b. You increment it to 0000 0001b.
Now, you go to increment it a *second* time (to 0000 0010b) only
to discover that you can't "write a 0" -- that would require ERASING
the LSb.
OTOH, if you count differently:
0 0000 0000
1 0000 0001
2 0000 0011
3 0000 0111
4 0000 1111
5 0001 1111
6 0011 1111
7 0111 1111
8 1111 1111
You don't have to "erase" as often as you would, otherwise:
0 0000 0000
1 0000 0001
2 0000 0010 ERASE
3 0000 0011
4 0000 0100 ERASE
5 0000 0101
6 0000 0110 ERASE
7 0000 0111
8 0000 1000 ERASE
The fact that the ERASED flash cells (assuming 0's, here) can
be written with 1's -- and, that 1's can *also* be written with
1's (!) means you can skip the erase if you can exploit that
aspect.
The goal is to minimize the number of erases.
The same idea is leveraged when storing the mapping structures
inside the FLASH. E.g., instead of OVERWRITING an existing
entry in the FAT with a "new" value, just *clobber* it!
(using the convention above, that would be like writing all
1's over an existing datum). The software then steps *over*
that entry when scanning the structure.
Eventually, when all of the entries in a "page" (I'm playing
fast and loose with terminology, here) are "clobbered", the
page can be ERASED and treated as a *clean* page to be reused
by "whatever".
[This is a real back-of-the-napkin explanation. There is a
lot more BFM involved. But, it's all painfully obvious -- once
you've *seen* it! :> Bugs creep in because you are juggling
several criteria at the same time -- trying to relocate data
to other pages, tracking which blocks are in which pages,
keeping track of how many erase cycles a page has experienced,
harvesting pages ready for erasure, etc. And, at the same
time, you are trying to make educated guesses at how best
to provide "performance" ("Do I erase this page *now* and
cause the current operation to wait? Or, do I defer that to
some later time in the hope that I can sneak it in "for free",
etc.]
