Rationale
Flash
technology is constantly changing and comes in many variants. To get
the most from any particular flash arrangement file systems need to be
crafted. TINY is crafted to work with flash which has small erasable
sectors with the specific design goals of being failsafe, having small
ROM footprint and minimal RAM footprint - making it possible to use
with very small microcontrollers. Traditionally most flash devices have had very large
erasable sectors (typically 32K or greater) which always leads to
fragmentation issues when creating a file system. By designing TINY so
that it is "configured into" a particular flash it allows the developer
to set file system to meet their file requirements with minimal
resource usage. Additonally, when used with uCDrive technology, your
microcontroller becomes a fully configurable and manageable pen drive
with minimal overhead. Microcontrollers, such as the MSP430Fxxx series, have
included flash which is both erasable in small sectors and is
application programmable. When used with TINY new possibilities arise
such as being able to store all your configuration files as standard
.ini or .txt files; or being able to just drop a new wav file to the
microcontroller without having to worry about flash layout and
fragmentation issues. Additionally there are many standalone flash devices
(and particularly serial flash devices) which have relatively small
erasable sector sizes and therefore can benfit from a file system
crafted to their arrangement. Standard NOR flash devices also had the drawback of very
long erase times - often greater than 1 second - whereas these smaller
erasable sector devices have much reduced erase times - typically a few
milliseconds. This factor also gives new design possibilities to
microcontroller based products requiring some kind of flexible storage.
Traditionally microcontroller developers have not used
file systems because of the overheads involved - now it is possible for
developers to get the benefits of position independent storage together
with exellent footprint and performance characteristics which opens up
new possibilities for the configuration and management of
microcontroller based products
Power-Fail
SAFE is a 100% powerfail safe system.
Why is it needed?
Embedded
devices do not have the luxury of sophisticated disk recovery programs
as PC comaptible devices do. If your embedded devices file system gets
corrupted because an erase or write operation is unexpectedly
terminated what will happen to the system - lost sectors? - lost the
whole device? - how do you repair it? Robust is not enough in many
cases - the system should be designed to restore your file system from
whatever point it failed. This is TINY file system!! How is it done?
The
basic method of operation is quite simple - a complete new file system
must be available for use before any information is erased. In this
way, if the worst happens the system can be rebuilt either in its
pre-write form (as if the write had never started) or with the new
modifications included. This is not possible to guarantee with a DOS
compatible file system (hence the prevalence of disk recovery software)
and with many other file systems. While the concept is relatively simple an efficient
implementation with flash devices which require sectors to be erased
before writing is definitely complex. Write and erase times can be
relatively long on flash devices and it is extremely important to
ensure the number of these operations is minimised. We believe our
write/erase performance per sector written is second to none for a 100%
power-fail system and indeed with systems that are not power-fail safe.
How is it Verified?
The main method of
verification is through PC simulation of the file system where
thousands of test cases can be run relatively easily - running the
standard source code with simulated NOR and/or NAND flash devices. The
code is then stopped at random or at selected points and it is checked
that the system reliably restarts and that no data is lost. Further testing has been done with real NOR and NAND
flash arrays by repeatedly breakpointing the code at any point - then
restarting the system and verifying that the operation is correct and
no data has been lost to the system. HCC have also had several of our customers try to break
the system but to HCC's pleasure (and we hope their customers'
pleasure) they have failed. |