EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 75 of 197

The initial goal of TFS was to provide my firmware with the ability to treat system flash as name space instead of address space. This eliminates the need for each new application to deal with the flash in some unfamiliar or clumsy way. environme nt with the abili ty to auto- matically boot one or more applica- tion fi les and allows other portions of that boot plalform to assume the exis- tence of an FFS. The boot platform Before getting into the meat of the fil e sy tem, I'd like to briefly describe the environment in which I designed TFS to run . This is not a I -equireme nt for TFS, but it is helpful for under- standing some of the discussion that follows. TFS is part of a generic boot monitor plalform for embedded sys- tems called MicroMon i tor. I The plat- form assumes the embedded system flash is broken up in to two major chunks: the flash used by the boot mon itol- executa ble and the fl ash used by TFS. It is assumed that the boot moni tor is deployed as part of the product. The actual application is a fil e in TFS that the boot monitor automatically tarts up. TFS is a maj or part of the moni tor. In fact, the moni- tor configu res itself based on the con- tent of a file in TFS (to retrieve IP address, console baud ra te, and so on). The boot moni tor con tains other facili ties th at depend heavily on TF , but they are beyond the scope of this discussion. The TFS design criteria The initial goal of TFS was to provide my firmware with the abili ty to treat sy tem fl ash as name space instead of address space. Thi s eliminates the need for each new application to deal with the flash in some unfamiliar or clumsy way. At the same time, I didn ' t want to eliminate the abili ty to acce s the flash as simple memory; hence, I needed an API to support the name- space model, but I wanted a hook into the raw flash to support the basic add ress/ data model. Other goals in the design were to make TFS some- what device- and RTOS-independent, and that it not require any system interrupts to run. The only restriction on the underlying flash is that its sec- tor size be larger than the TFS heade r size (cuJTently 76 bytes) . The result i an FFS implementation that supports the needs of a high-level application that wants a file system model as well as a real-time application that needs quick memory access. TFS is a linear fi le system that gives a typical embedded system proj ect all of the fil e-system-like capabil ities it will ever need . TFS does not support any sophisticated wear-leveli ng algorithm, it doesn't have a directory hierarchy, and it is not compatible with any other fil e system. I have yet to work on a pro- j ect that was accessing the flash fre- que ntlyenough to need wear leveli ng and as fa r as DOS compatibility, if the media is not removable, then there's no need fo r that anyway. The TFS implementation is independent of the RTOS used (doesn' t need one ) and it is easily hooked in to an application. The user interface At the user inte rface (typically an RS- 232 console, but optionally a UDP port), TFS is a command. Al l of the capabilities within TFS are made avail- able as sub-commands under the TFS command. For example, to list th e fil es currently in tile flash, the com- mand would be "lfs Is", not just "Is". The general syntax of tile TFS com- mand is: tfs [options] {sub-command} [argu- ments dependent on sub-command] TFS eommand op tions • - d {device pl-efix} Apply tlle command to the speci- fied TFS device (assumes more than one fl ash device is covered by TFS space) 74 DECEMBER 2000 Embedded Systems Programming • -f {flags} Flags (o r attributes) applied to the TFS fi le • - i {info} Information field included with tile fi le created • -m Enable "more"-style output throt- tling when displaying a fi le or list of fi les. This is an additive flag. Multiple -m options on tile com- mand line (for example, - mm) will increase the pagesize • -v Enable verbosity level (- v=lvl 1, -w=lvl 2, -\IW=lvl 3) TFS subcommands • add {name} {src_address} {size} Create the fi le 'name' to contain the data starting at location 'src_address' of size 'size' . Options -f and - i can be used to specify the flags and in formation fie ld associat- ed with the newly created file • cat {filename} Dump the content of the specified fil e to the user. Use of the -m option wi ll throttle the output in bursts of eight lines • check Check the sanity of the fi les stored in TFS by running val-ious tests (like a CRC32 on the data and headel-). If the -d option is speci- fied, only check fi les in the speci- fied device • clean[r] Clean up (defragment) the fi le sys- tem to free-up fl ash space. If ' r' is appended, the system will automat- ical ly restart after tile cleanup. If til e - d option is present, only clean up the device specifi ed • cp {name} {n ewfi lename I hex address} Copy the named fil e to tile new named fi le. If the destination begins with 'Ox', then it is assumed to be a hex addre pointing to RAM • freemem [varname] Return (or store in 'varname') tile amount of fl ash memory that i sti ll

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13