This article briefly introduces a log file system developed on the stm32f10x chip of the Cortex-M3 System (rather than a system, rather than a small library ). This library makes it easy and reliable to process data (history records) on the stm32f10x chip. Because my projects are basically monitoring systems, I need to record various logs and upload them to the central server at any time. With this database, you can easily use this interface to initialize, read, write, and delete data. In addition, with the application of this database, the stability has been verified, and the application to other projects is more confident. This library is divided into two parts: one part supports Internal flash and the other part supports external flash. Because of the cost of hardware design, we often need to consider the use of internal flash or external flash, when the storage data volume is small, and the selected chip has enough Internal flash space, data can be stored in the Internal flash. When the data volume is large, you can choose to store the data in the external flash. For applications, you only need to modify the macro definition to map different library functions.
Using this library in my project team, I feel that everyone has a consensus on the data storage part. The Code basically does not need to consider how to calculate the flash Address. If you ensure that the average write and erase operations ...... By applying this database, planning the space analysis, and setting it, you can start recording operations.
The following is a brief description of this database:
Internal flash uses nor flash, which is characterized by in-chip execution, so that applications can run directly in flash memory without having to read the code into the system's Ram. The main function of log file system is to use the Internal flash address as the storage space (directly use the Internal flash space, reduce hardware costs), In the Cortex-M3 system CPU chip, A log file system created by page. You can create a file system using one or more consecutive pages. A file system can store a fixed-length data. For data with an indefinite length, you can create a file system with the maximum length. The log file system provides a unified API interface to access internal flash data, and provides an average erasure Algorithm for flash space to improve the service life of flash. The log file system is stored as a record. For applications that require a record method, using this file system can bring great convenience. For example, a monitoring system needs to record historical alarm information, or a system needs to record operation logs.
The internal file system creates a record guide table by sector. You can use the sector guide table to quickly locate the record location. At the same time, you can quickly create File Information (number of records, position of the first record. Generally, each slice is 2 K. to make full use of the advantages of the file system, the record length should be much smaller than 2 K to ensure proper space utilization. You can create a sector data storage to support an indefinite record and store the data checksum. After data is written, the system immediately verifies the data to ensure that the data is successfully written. If the data fails, the system continues to write the data to the backend, to cope with various exceptions. The length of data written during data storage, and the length of data written will be returned during data reading. Verification is generated during data writing and will be verified during both writing and reading.
The file system can recover from power loss at any time. due to unexpected crashes or power loss during flash operations, the program can maximize the security of user data and restore the data. The log file system uses continuous space as the storage condition. Therefore, records in the log file system are ordered and cannot be deleted from the middle to ensure the integrity of log records.
The purpose of this manual is to introduce the API function information contained in the Internal flash log file system, the functions of each function, how each function is called and their association, and some struct and constant definitions. This document serves as a reference manual for beginners who use the file system when using flash.
Main advantages:
1. Log-based record structure for easy operation and maintenance
2. Average erasure algorithm to improve flash service life
3. Automatic Recovery from abnormal power loss
4. Data Verification
5. Easy to use without support from the Operating System
The log file system is easy to use. You can use the log file system in three steps.
(1) define a file description handle object
Defining the file description handle object is a step that must be completed before use. This description defines the start address of the slice used by the File System (note: the maximum data length recorded in this log file is provided after the preceding information is provided, A log file has been defined.
The file description handle object is generally a global variable, which can be used within the file range. At the same time, the handle must be saved and valid throughout the program running.
(2) initialize the file handle
The defined file description handle only specifies the space location, log record size, and ID of the file to be used. To officially start using this log file, you need to initialize it, this includes scanning each sector of the specified flash Address to ensure that it is consistent with the description of the file description handle. When a sector is inconsistent, it will be re-initialized. At the same time, initialization scans the partition table information of the slice to obtain the number of records in the slice.
(3) Use a file handle
After successful initialization, you can start to use this log file. Including obtaining the number of records contained in a log file, reading and deleting records, and adding records to the log file records.
Example of a simple application:
// Load a configuration from flash. If 0 is returned successfully, otherwise 1 is returned. // log file system is used, one slice can be used to store the configuration (in fact, you must do this-// flash can only be erased by slice). In this way, when multiple configuration changes are made, a new configuration is written, and delete // The previous configuration (set the delete flag). Only after the configuration is completed, the slice will be deleted and new writes will begin. // The following example uses the space of one slice as the configuration space. The size of the written configuration is determined by the parameter setting (CFG) lfsin_t lfs_cfg = {flash_offset_cfg, // start address offset (flash offset) 0, // start page 1, // end page [start, end), occupies one page space lfs_type_cfg, // sizeof (sort _t), // The maximum log size recorded-1, // internally indicates the start header (write location ), -1 is not required, // It is used internally to indicate the start end (read location), and 0 is not required, // number of available log records, you do not need to specify 0 // the position of the current read header (ID position of the sector), do not need to specify}; int loadcfg (void) {int rdlen; int Buf [10]; unsigned char performance_load = 0; lfsin_load (& lfs_cfg); // initialize the log file (SCAN record area) // read the first record (if one configuration item exists ), buf buffer used to store read data rdlen = lfsin_read (& lfs_cfg, 0, Buf, sizeof (cfg_t )) // determine whether the read data meets the requirements. If (rdlen = sizeof (partition _t) {partition _load = 1; // return 0;} else {partition _load = 0; // failed to load configuration return 1 ;}}
I will describe the specific implementation method in another blog.