设计我最赞的博客

现在，你已经熟悉了FAT文件系统，George从不同角度带您了解了这个东西。通过向你展示一个通用FAT文件系统，他向你挑战，移除了不需要的功能并自定义你需要的应用。

FAT File System Review (Part 2)
C Code for the File System

Now that you’re familiar with the FAT file system, George approaches the subject from a different angle. By presenting you with a general-purpose FAT file system, he challenges you to remove the features you don’t need and customize your application.

In “DIY Signal Generation,” Neal Martini writes: “I have been using C to program my past few projects. It was a little painful coming up to speed, but now I am a real convert.” (Circuit Cellar 219, 2008) He went on to explain how C helped.

Isn’t it great that everyone is reading my articles about the C programming language and converting? Actually, I don’t believe my work has had much effect just yet. If you look at the articles in Circuit Cellar closely, you will see a movement toward structured design. This can be demonstrated in two ways: one, with the use of structured languages (e.g., C) and, two, in the flowcharts. Years ago, assembly language was king, and convoluted flowcharts that looked like plates of spaghetti were the norm. Today, designs are much more refined (structured). So quit hiding your head in the sand. Bite the bullet, take that the plunge, move toward the light, and step over to using C in your embedded systems. (I like to see how many clichés I can get past my editors.)

Last time, I started a discussion about using a removable memory card (either CompactFlash or Serial Digital) in your next system and a file system on those devices. These cards offer a large capacity at a low price. At some point in your system analysis, you might decide that a file system is the best way to manage all the data on the card. If that’s the case, then here is another solution to add to your bag of tools.

I discussed the low-level routines used to access and control these memory devices. And I also presented one solution to the FAT file system design I found in the Circuit Cellar archives. (Refer to the following two articles: “PIC a CompactFlash Card,” [M. Samuels, Circuit Cellar Online 127, 2001] and “Portable FAT Library for MCU Applications,” [I. Sham, W. Hue, and P. Rizun, Circuit Cellar 176, 2005]). You’ll find the original C code and the analysis output that has been generated using Source Publisher (www.scitools.com). The original code has documentation dated June 2004. Also I would like to point you to an Intel reference design “Intel IXP42X Product Line of Network Processors and IXC1100 Control Plane Processor: Using CompactFlash.” Don’t let the title scare you. It’s a good article about interfacing to a CompactFlash card and the code to support the interface. It’s written from a hardware point of view more than a software (file system) point of view.

I also discussed the support that the C language has for file operations. I did not go into much depth about C file I/O support. That could be another multipart article series. If you’ve never written such routines, I recommend that you download a free (as in free beer) copy of Turbo C++ (or any other C environment). You need to work with these procedures. Keep in mind that Borland did a good job of protecting the designer from himself (or herself). For example, if you open a file and then exit the program, Turbo C++ takes care of the details and closes the file so that your disk does not become corrupted. But, if the power fails on your PC while a file is open, look out. You need to design for these issues. Actually, this is a good test to see if your program can recover the file(s) that were open when the lights went out. I recommend CTL-ALT-DEL as a gentler method to crash the Turbo C++ program than switching off the power.

Jeff Bachiochi recently presented a two-part article series about connecting an SD card to a PIC processor (“Access SD Memory Cards,” Parts 1/2, Circuit Cellar 221/222, 2009). Most of the articles I’ve come across don’t give you much information, detail, or control over the FAT file system. This is not a criticism, it is just an observation. As practical embedded system designers (geeks), we’re not going to implement only what’s needed to get the job done. We’re likely to probe, kick, stretch, test, and add features that improve and enhance the design, even if only implemented for use during in-house testing. We also like to get “under the hood” and understand the inner-workings.

With that in mind, I’d like to present a more generalpurpose FAT file system. You can remove the features you won’t use and tune the operation to suit your application and specific hardware. I purchased a low-power Altera NIOS evaluation system for another project. On that board is an interface to an SD card along with the embedded file system library (EFSL). This library is available for download from SourceForge, as are other interesting hardware and software projects. If you haven’t looked at the site yet, be careful. It’s full of great projects and you could spend mega-hours wandering through them.

GET STARTED
The EFSL is written in C and is only a library. It doesn’t do anything out of the box but will tie in nicely with your embedded C code. It has hardware targets for Linux, the Atmel ATmega128, and the Texas Instruments DSP families. In a future article, I’ll get this up and running on another embedded system and make that available to you. The download package includes a manual that explains the design and how to apply the library to your specific application. This library handles FAT12, FAT16, and FAT32, with with long file names and time and date support.


The EFSL has the structure shown in Figure 1. The designers describe this as a linear object model. And you perhaps thought objects were used only in object-oriented languages such as C++ or Visual Basic. That is not so. You can use objects in regular old C. This is a good way to help you transition into those object-oriented designs and languages. Continue reading for a description of the EFSL.

FILE & FILESYSTEM OBJECTS
The File and Filesystem objects in the EFSL design deal with handling file system-specific details. The module file.c contains functions dealing with files such as fopen(), fread(), and fwrite(). The module fs.c contains general file system functions supported by the functions of dir.c and fat.c. Note that file.c uses these functions heavily.

The Partition object is responsible for translating partition relative addressing into disc-based LBA addressing. The functions in the Partition object are partition-specific. These include searching FAT-type partitions and read/write functions to partitions. They are found in the module partition.c.

The Disc object holds the partition table and has a direct link to a cache manager. The disc.c file contains the functions regarding the entire disc, such as loading the Master Boot Record (MBR) and performing read/write tests.

The IOMan(ager) object receives all requests for sectors. This enables it to make smart decisions regarding caching. You will find these routines in ioman.c. One key define in this file is IOMAN_NUMBUFFER. It determines how many sectors IOMan can cache. I find that the IOManager holds several clever solutions that apply to most embedded designs. It supports delayed write. So as you fill up buffers with data, you can either force a write or let the IOManager decide when a write is necessary. IOManager also can allocate memory itself or use memory that you have previously allocated. This is key to being flexible enough to make it applicable to a broad variety of systems.

The hwInterface (hardware interface) object has three responsibilities: initialize the hardware, read the sectors, and write the sectors. In the first part of this article series, I presented code outlines for interfacing to a CompactFlash card and included those routines.

As you study this design, I think you will find it straightforward yet sophisticated enough to handle your embedded system requirements. I was looking for FAT32 support because I predicted that smaller capacity memory cards will soon disappear from production or their prices will rise
above the larger capacity designs.

The text in the EFSL manual reads: “This library is released under the Lesser General Public License (LGPL). This means that you may use the library and its source code for any purpose you want. You may link with it and use it commercially. But ANY change to the code must be released under the same license.” (http://efsl.be)

If I look up more details on the LGPL, it seems that if you keep the EFSL as a separate library and do not merge it with your code, then your code does not become part of the LGPL license and you can keep it confidential. However, if you mix the EFSL with your source code, the LGPL governs the entire package. I am not a lawyer. You should get proper legal advice if you proceed down this path. Still, I’m convinced the LGPL can be made to work in our competitive embedded world.

I recently used the Intel application note to create a FAT file system on a project. It worked well. There were a few areas that were a bit unpolished and my design was perhaps not the greatest. Specifically, I needed to open each file from a directory, one at a time, and read the data in that file. I stumbled my way through this. The code is presently used by the factory for system configuration purposes, and my solution was acceptable. In all fairness, this area of operation was not part of the Intel application note so this is not a criticism of that approach in any way.

Put in a more general way, the functions missing are functions like listing a directory—using standard C functions like fopen(), fread(), and fwrite()—and managing buffers. Also, you may be looking for commands like mkdir(), rmdir(), and lsdir() to make, delete, and list a directory. And consider how do you format memory cards? Well, it looks like the EFSL either provides these functions directly or gives you the hooks need to implement them rather easily.

USING EFSL
How do you use the EFSL? I would create a directory to hold the library, make that directory part of your project, and then perform a compile and link. Remember: If you mix the EPFSL code with your code, then the entire work becomes covered by the LGPL.

To figure out what is in the EFSL, I put the library through a documentation program. I use Source Publisher from Scientific Toolworks. A compressed file (sp_EFSL.zip) is posted on the Circuit Cellar FTP site. The file unzips into a directory named “sp_EFSL.” The directory includes the output from the Source Publisher program. The index.html file is the starting file. I ran Source Publisher on the EFSL library and enabled every feature. Perhaps I should be brought up on charges for excessive documentation, but I’m sure I can talk my way out of that one.

From the index, you can view the Navigation Menu, read the Understand Reports for the project (another utility offered from STI), view the Globals Used Report, view the Globals Report, view the code, and view the metrics. All of these reports contain hyperlinked references. So, if you are not sure of the definition of a constant, variable, or routine, one clock will get you to that definition. If you haven’t used one of these programs yet, this should impress you. If you are used to this richness of information, then just read on. Code review and SourcePublisher deserve a complete article. Perhaps you will write that one.

Starting with the config.h file, you can see the various definitions used in the project. The first is HW_ENDPOINT_NIOS. This sets the code up for compiling all that is needed to run on the NIOS evaluation board. You could add HW_ENDPOINT_CCI for this code to run on the Circuit Cellar evaluation board if there was one. (That’s also another article.) Next, you’ll see BYTE_ALIGNMENT commented out. This is for the Bigendian and Little-endian issues. Next are cache definitions. I’m glad to see this early on in the definitions. I bet memory allocation is on everyone’s list of things to look out for. A bit further on you’ll find DATE_TIME_SUPPORT defined. Do you need to keep the file date and time up-to-date in our system? Well, here’s the flag to do just that. I bet you’ll have to hook into routines that provide a time structure from your hardware to this code. Notice that all these definitions come with well-written comments. A really nice piece of work. As you look through this code, why don’t you offer to add more comments to clean up any unclear portions? It’s an open-source community project.

In debug.h, you’ll find definitions for adding debug functions to the code. Again, you can tailor this to your system requirements. In the other “.h” files, you’ll find definitions that will look familiar if you’ve been reading my articles on C or you’re already using C language. It’s sort of like an old pair of shoes. It’s comfortable and gives you the confidence to incorporate this work into your project.

I don’t mean to bore you with all these details, because you just want a prepackaged answer to your FAT file system issue. But you’ll probably find that you need to tailor some portion of any design to fit your needs. And isn’t it great to have such a complete solution?

LOOKING AHEAD
As I mentioned earlier, I plan to use this library in a project I’m working on. At that time, I’ll report on just how fast some of these routines operate and the size of the generated code.

If there are any areas of the C language (short of homework assignments) you would like me to cover in more detail, just send me e-mail and I’ll try to address your comments in an upcoming article. Remember: Circuit Cellar writers like me are doing this for you.


George Martin (gmm50@att.net) began his career in the aerospace industry in 1969. After five years at a real job, he set out on his own and co-founded a design and manufacturing firm (www.embedded-designer.com). His designs typically include servo-motion control, graphical input and output, data acquisition, and remote control systems. George is a charter member of the Ciarcia Design Works Team. He’s currently working on a mobile communications system that announces highway info. He is also a nationally ranked revolver shooter.

PROJECT FILES
To download code, go to ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2009/226.

RESOURCES
G. Martin, “FAT File System (Part 1): Open Files and Perform Operations,” Circuit Cellar 224, 2009.
———, “Structured Design (Part 1): An Introduction to Structured Techniques” Circuit Cellar 128, 2001.
Intel Corp., Application Note: Intel IXP42X Product Line of Network Processors and IXC1100 Control Plane Processor: Using CompactFlash,” 2004.
SourceForge, “Embedded Filesystems Library,” http://efsl.be/. Wikipedia, “Structured Systems Analysis and Design Method,”
http://en.wikipedia.org/wiki/Structured_Systems_Analysis_and_Design_Method.

SOURCE
Source Publisher
Scientific Toolworks, Inc. | www.scitools.com/products/sourcepublisher