Design and implementation of file system for CF card storage in ARM7 system

As the performance of microcontrollers continues to improve, embedded applications are becoming more and more widespread. However, large commercial embedded real-time systems on the market are expensive and are all targeted at specific hardware platforms. For small and medium-sized system development, it is not cost-effective to purchase commercial real-time systems.

At present, we are working on the development of embedded system software for automotive satellite navigation system. Traditional embedded applications do not include file systems, and the file system we want to implement needs to realize the reading and writing of map data files in the vehicle navigation system. Therefore, it must support both file systems compatible with MS-DOS and other types of file systems. On the other hand, from digital cameras to MP3 players, from handheld computers to digital cameras, CF (CompactFlash) cards are increasingly widely used in digital devices due to their small size, strong compatibility, and relatively low price. However, if you want to transfer data between CF cards and PCs, you usually have to use a special card reader, which brings a lot of trouble to PC users. The full name of CompactFlash card is "standard flash memory card", or "CF card" for short. CF cards have a wide range of applications, and the most common use is for photo storage in digital cameras. Since the CF card uses an analog hard disk controller design, it can be easily connected to the computer through the IDE interface, which can play a role as mobile storage to a certain extent.

General embedded systems do not provide an interface for reading and writing CF cards, so a driver needs to be specially designed in the file system.

1 Basic principles

In the CF card shown in Figure 1, the controller interface of the host system allows data to be read and written from the Flash media. There are three access modes for CF cards: Memory mode, I/O mode, and True IDE mode. We chose the True IDE mode. It should be noted that when the host power is always on, plugging and unplugging the CF card will reconfigure it from the original True IDE mode to PC Card ATA mode. Therefore, to make the CF card always work in True IDE, the OE input signal needs to be grounded when the power is turned on. This mode also supports 8-bit access, but we chose 16-bit access. The maximum number of sectors accessed at one time can be determined by the 47th parameter word in the command code Ech.

The structure of a CF card is the same as that of a hard disk, as shown in Figure 2. The boot sector contains the code for starting the system and important information about the file system, followed by a table that records all disk space, then the root directory, and then everything else. The boot sector contains a partition table at the end. This table contains entries to mark the start and end of each partition. There can be up to four partitions, each of which can contain a different file system. Immediately following the boot sector is the FAT (file allocation table), which is used to record information about all disk space in the device (this table has the same function as the I-Node table and free table in UNIX).

When designing the software, both versatility and scalability were considered, with the goal of enabling the file system to operate on different storage media such as CF cards, IDE hard disks, RAM disks, electronic disks, SD cards, etc. without having to modify them separately; read data from these storage media, and transfer the data to different storage devices. [page]

In order to achieve these goals, we separated the hardware operation programs according to the different processing methods of different CPUs, and turned the low-level programs related to the device into upper-level operations that are independent of the device. In this way, when the system adds new functions, it is not necessary to change each subroutine, but only to add or change data items in the data structure of some interface files; considering the transparency of the upper-level operations to users, we adopt an object-oriented approach. The Driver structure (including Read and Write data items) of the access operation in the upper-level structure is virtual, and it is only at the bottom that it is concretized as the read and write sector commands of the CF card (operation code: 20h, 30h).

The main flow of the software program is shown in Figure 3.

2 System Design and Implementation

According to the above principles, the software design can be completed. Its basic framework is shown in Figure 4 and is divided into six main parts.

The key to the design of the CF card driver is that the command codes used by the access operation functions of the CF card are somewhat different. In addition, we use a driver object to represent the CF card device driver. The driver object is partially opaque to the user, and the data items include pointers to read and write functions, which are output by the file system program (including two parts of functions, user-visible API function calls and user-invisible driver access functions). The data structure of this object is declared as follows:

Typedef Struct CF_XFILE_DRIVER{

BYTE Driver_name; /*Media identification; CF card, IDE hard disk, Flash card, RAMDISK, etc. If you delete the driver, you need to re-record the DRIVER number*/

……/*IRP processing function*/

}CF_XFILE_DRIVER;

If there are multiple CF cards, another specific data structure Next_Driver is needed to connect them horizontally. Then, a linked list is used to manage these data structures, similar to WDM (Windows Driver Model).

3 Test Analysis

After debugging and running, the file system has good performance. Compared with the file systems of Nucleus, ΜC/OS-II, and UNIX operating systems that we have ported before, the file system introduced in this article is more portable; in addition to the CF card introduced in this article, it can be applied to other storage media such as RAMdisk, IDE hard disk, Flash, etc. (IDE hard disk and Flash have also been successfully debugged) after a simple modification of the underlying driver. In addition, the file system introduced in this article has lower configuration requirements for the hardware platform, and the running speed of file operations has not been slowed down.