Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 87 of 197

decompressio n) fo r the monitor 's malloc, but compression with zlib can resul t in a 70% reduction in space needed fo r file storage. Time of day The basic model of the moni tor is to run without the need of any interrupts from the host processor, so how is it that TFS can keep track of time of day? Actually, it doesn 't. It depends on the applicatio n code to provide it wi th two fun ctio ns th at will support thi s: getLtimeO and getAtimeO. The first o ne, (Long)getLtime(void), must return a long that is stored in the header of the TFS file when it is creat- ed. The second one, *)getAtimeĀ«Long *)tvaL, (char (char *)buf, (int)bufLen), can be us d to sim ply return an ASCII senting the current time (if tval is 0) or it can return an ASCII string repre- senting the value stored in tval. The value in tva I will typically be the value that was p revio usly return ed [rom getLtimeO. With this in terface, TFS really doesn 't have a clue about time- of-day, but it uses the capabili ties given to it by the application to make it look li ke it does. Note that this is a feature used by TFS to populate an entry in the head- er of the file being wl-itten at the time. If the two ab ve functions are not sup- plied to TFS, then the heade r e ntry is left blank, and the file sim ply has no recollection of its time of creation. Change log TFS supports the abili ty to keep track of all modifications made in the fil e system. This is done by logging an actio n (add, delete, or in-place-modi- fy) and a filename to a file in TFS. By default this is not enabled, but can be enabled/ d isabled at any time using th e tfs log command. The command will only run at the MAX user level and the fi le is created at the maximum u er level. Jf the tfsctrL(TFS_TIME- FUNeS) command has been called to establish time-of-day functions in TFS, th en the log will also reflect the time tring repre- at which th e change was made. Following is an example of the COI1- tent of the TFS change-log (.tfschlog) fil e: ON: startup ADD: cardtiLt.gif ADD: construction.gif ADD: Lucentlogo.gif ADD: .httpadmin ADD: .dhcpsadmin DEL: cardti L t.gif ADD: cardti L t.gif DEL: construction.gif ADD: construction.gif DEL: Lucentlogo.gif ADD: Lucentlogo. gi f Flash life expectancy It is impor tant to be aware of the fact th at the underlying technology (fl ash) has a limited numbe r of erase cycles. Current fl ash devices typically support 100,000 to one million erases per sec- tor. Applications will use TFS in differ- ent ways, so it is impossible to draw any conclusions he re with regard to how long th e flash will last in a system using TFS. This section will , however, address the way TFS uses the fl ash so that the user can determin flash life expectancy based on the application's in tended use of the fil e system. First of all , be aware th at TFS makes no attempt to do "wear-level- in g." If the fil e system you need is to be used heavily e no ugh to require wear levelin g, the n buy o ne! Wear lev- eling adds a great deal of complexity to the unde rlying impleme ntatio n and is beyond the scope of TFS. In every embedded system proj ect I've been on , the need fo r a clean inter- face to flash by name (instead of by address) has been there. On the other hand, the frequency of fil e modifica- tion has never made it necessary to even consider wear levelin g, especially with the trend by many flash manu- fac turers to support one milli on eras- es per sector. As mentioned above, the TFS API presents itself to the prognuTImer in much the same way a standard OS's fil e 86 DECEMBER 2000 Embedded Systems Programming system would be een. This may mis- lead application developers into think- ing that the fil e system can be thought of as a disk that provides the user with the freedom to write/ erase at any fre- quency. This is not the case! TFS's defragmentation mechanism does not use a floating spare sector. This means that the spare sector is the pOI -tion of fl ash that is likely to wear out first sim- ply because it is used as temporary tor- age fo r all other sectors when defrag- mentation is do ne. In an example design, 13 sectors of flash are used for TFS file stOl-age and one fo r the spare secto r. Assuming worst-case defrag- mentation (all 13 sectors are affected), then a defragmentation run once a day on a part having a life expectancy of 100,000 erase cycles will be good for over 20 years (100,000/ 13/ 365 = 21). This va lue of 20 years makes the assumption that a defragmentation will be done dail y, and that all sectors are affected by the defragmentation. The frequency of defragmentation and the number of sectors affected are very dependent on the application's use of the file system. For proj ects that TFS was originally designed fo r, this realisti- cally means that there is no need to be concerned wi th fl ash life expectancy. For other applicatio ns, fl ash usage must be considered. Let's discu s th e way the sectors are utilized and how diffe rent applications may wear out flash faste r than others. A fl ash secto r is only erased during defragmentation. When a file is delet- ed, it is simply marked as deleted (a bit in the heade r). A fil e is deleted by the command tfs rm or through the API fun cti ons tfsunL inkO, and tfs- cLoseO when the file was open ed for writing or appending. If a file tha t exists is opened for writing, the actual modification steps are deletion of the original file and re-write of the new file after the file that is currently the last fi le in phys ical fl ash space. Eventually this process reaches tile end of tile fl ash space used by TFS, 0 defragmentati on must be run . At defragmen tation, all of the space wast-

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13