Design of embedded file system based on Flash wear leveling

Introduction
The massive memory of embedded systems is mostly expanded by Flash memory. Since Flash memory has a limited life span of limited write times, frequent operations on the Flash memory will shorten the life span of Flash memory. How to design a reasonable file system for embedded applications, realize the wear balance of Flash memory, and realize effective data management is of certain significance to improve its life span.
This paper designs an embedded file system based on AVR microcontroller expansion Flash memory and Ethernet controller to achieve wear balance of data storage and memory use, and provide a research method for extending the life span of Flash memory.
1 Hardware platform design
This embedded file system uses Atmel's AVR microcontroller ATmega 128 and Flash memory AT45D13081. The Flash chip has 8 Mb storage space, which is divided into 4096 data pages, and each page can store 264 bytes. Data communication between ATmega 128 and AT45DB081 is realized through the serial peripheral interface SPI. The hardware structure of the file system is shown in Figure 1. Among them, RTL8019AS is a full-duplex plug-and-play Ethernet controller.

2 Overall Design of Embedded File System
The management of the file system is realized by organizing the information it manages into files. A file is a sequence of related information elements with a name. From the user's perspective, the file system mainly realizes storage by name; from the perspective of system management, it mainly realizes the spatial organization and allocation of file storage, the storage of file information, and the protection and retrieval of files. The file system should use well-organized data structures and algorithms to effectively manage file information, so that users can store information more conveniently. The file system generally does not care about the characteristics of the underlying hardware and only provides simple and standard interfaces.
2.1 File System Storage Structure
According to the characteristics of the Flash chip, in order to realize the fastest reading of file data, this file system adopts a single-level directory structure and uses the link page method to manage the Flash storage space. The file system storage structure diagram is shown in Figure 2. In the Flash memory, the file system is divided into three parts: the file system information table (FAT), the file control block (FCB) and the data area (DA).

The file system information table (FAT) is used to store the information and attributes of the file system. The data structure includes the validity flag of the FAT, the total number of files, the sector number of the first file control block and its address in the memory, and the address of the current FAT in the memory.
The file control block (FCB) is stored in the Flash and represents the static information of the file. The data structure includes the file name (within 11 bytes), the sector number where the first cluster of the file is located, the file length, the file attributes, the file creation time, the Flash address of the next FCB, and the valid flag of the file control block. The file control blocks are linked in the form of a linked list.
The file handle (File_Handle) is stored in the memory and represents the dynamic information of the file. When the user opens or creates a file, a file handle is applied in the memory. The data structure includes the file handle identification number, the file handle status, the file name, the file first cluster number, the sector number where the first cluster is located, the current cluster number, the file pointer, the file length, and the FCB address of the file.
The operating system combines adjacent sectors together to form a cluster, and then manages the cluster. Obviously, the cluster is a logical concept used by the operating system, not a physical characteristic of the disk. In order to better manage disk space and read data from the hard disk more efficiently, the operating system stipulates that only one file can be placed in a cluster, so the space occupied by a file can only be an integer multiple of the cluster. The file system designed in this paper stipulates that the size of a cluster is a page of the memory.

2.2 File System Architecture
As shown in Figure 3, the file system external interface function provides a unified abstract interface and data structure for the application layer. The application implements file operations and device management functions through the file system external interface function, hiding the implementation details of the file system's underlying driver and device driver. The device driver at the lower layer provides an access operation interface for file data on the device.

3 Embedded file system implementation and device driver
The purpose of file system design is to achieve effective data management and average use of storage space. The design of file system includes the design of file system external interface functions and underlying driver.
3.1 File system external interface functions
Calling the file system's external interface functions is the only way for applications to use the file system. The standardization, ease of use, and functionality of the interface are related to the openness of the file system and the user's acceptance of the file system. The external interface functions provided by the file system are listed in Table 1. Applications can manage and operate files by calling these interface functions.

3.2 File system bottom driver
The file bottom driver serves the external interface functions of the file system, including reading and writing the file system information table, reading and writing the file control block, reading and writing the file handle, and related operations of various clusters. The bottom driver functions of the file system are listed in Table 2.

In the above-mentioned file system underlying driver function, the clean cluster application function (unsigned long app_clus(void)) directly affects the use allocation of the memory storage area. The process of this function reflects the average distribution of the number of times the memory storage area is used.
Function description: Apply for a clean cluster.
Entry parameter: None.
Exit parameter: <0x100000, the page address of the clean cluster is applied for; NO_CLEAN_SECTOR, there is no clean storage space.
The process of this function is shown in Figure 4. The program applies for a clean cluster from the first page to the last page of the storage area. If successful, the cluster address is returned; if failed, the dirty cluster is cleaned, and then another clean cluster is applied from the cleaned storage area. If successful, the cluster address is returned, and if failed, error handling is performed and the program ends.

3.3 Flash device driver
The operation of the file system is ultimately a read and write operation of the memory. During file operation, the device driver provides the file system with control over the memory, generally including read, write and reset operations. This article is based on the Flash chip AT45DB081 memory and provides the driver functions listed in Table 3 for the file system.

After completing the above hardware and software design, a client test software is written based on the PC. The file is operated through a custom protocol, a file is downloaded to the file system, and then read and compared to verify the correctness of the file system.

Conclusion
The solution in this article mainly focuses on the wear leveling control of the memory, which extends the service life of the Flash memory. Other functions such as error proofing and error correction of files are not designed in detail. A single-level directory is used and multi-level directories are not supported. The entire solution has been implemented and verified on a system composed of a single-chip microcomputer ATmega128 and Flash AT45DB081, and good results have been achieved. This file system has a high application value in log-type data acquisition and recording applications based on Flash memory.