JP2020135656A - File management system - Google Patents

Abstract

To materialize a file system that is suitable for a system having small memory size.SOLUTION: A file management system 20 comprises: a data region 22 that is a memory space in which file data is stored; and a management region 24 that is a memory space in which attribute information pertaining to the file data is stored. The data region 22 is divided into a plurality of sectors, and one piece of file data is stored in continuing sectors. When the one piece of file data is stored in the data region 22, an identification name of the file data and one piece of attribute information indicating a beginning position of the continuing sectors are stored in the management region 24.SELECTED DRAWING: Figure 2

Description

The present disclosure relates to data processing techniques, especially file management systems.

The IoT (Internet of Things), in which various devices are connected to communication networks, is progressing. A microcontroller (also called a one-chip microcomputer) may be used in a computer system (also called an embedded system) incorporated in a home appliance or a sensor device connected to a communication network.

Patent No. 4745337

As with PCs, the advantage of being able to use a file system is great in embedded systems. However, the memory size of the microcontroller is at most several MB. Therefore, it has been difficult to use a conventional file system in an embedded system.

The present disclosure has been made in view of these circumstances, and one object is to realize a file system suitable for a system having a small memory size.

In order to solve the above problems, the file management system of a certain aspect of the present invention includes a data area which is a memory space in which file data is stored, a management area which is a memory space in which attribute information related to file data is stored, and the like. To be equipped. The data area is divided into a plurality of sectors, one file data is stored in consecutive sectors, and when one file data is stored in the data area, the management area identifies one file data. One attribute information indicating the name and the start position of consecutive sectors is stored.

It should be noted that any combination of the above components and the expression of the present disclosure converted between an apparatus, a method, a computer program, a recording medium on which a computer program is recorded, and the like are also effective as aspects of the present disclosure.

According to the present disclosure, it is possible to realize a file system suitable for a system having a small memory size.

It is a figure which shows the hardware configuration of the microcontroller of an Example. It is a block diagram which shows the functional block of the file management system of an Example. It is a figure which shows the structure of the management information stored in a management area. It is a figure which shows the wear leveling of management information schematically. It is a flowchart which shows the operation at the time of starting a file management system. It is a flowchart which shows the operation at the time of writing a file data. It is a flowchart which shows the operation at the time of deleting a file data. It is a figure which shows typically the state which the file data was deleted. 9 (a) and 9 (b) are diagrams showing an example of writing file data to a non-contiguous sector group.

The subject of the device or method in the present disclosure comprises a computer. By executing the program by this computer, the function of the subject of the device or method in the present disclosure is realized. A computer has a processor that operates according to a program as a main hardware configuration. The type of processor does not matter as long as the function can be realized by executing the program. A processor is composed of one or more electronic circuits including a semiconductor integrated circuit (IC) or an LSI (large scale integration). Although they are called ICs and LSIs here, they may be called system LSIs, VLSIs (very large scale integrations) or USLIs (ultra large scale integrations), depending on the degree of integration. Field programmable gate arrays (FPGAs), which are programmed after the LSI is manufactured, or reconfigurable logic devices that can reconfigure the junction relationships inside the LSI or set up circuit partitions inside the LSI should also be used for the same purpose. Can be done. The plurality of electronic circuits may be integrated on one chip or may be provided on a plurality of chips. A plurality of chips may be integrated in one device, or may be provided in a plurality of devices. The program is recorded on a non-temporary recording medium such as a computer-readable ROM, optical disc, or hard disk drive. The program may be stored in the recording medium in advance, or may be supplied to the recording medium via a wide area communication network including the Internet or the like.

The outline of the embodiment will be described. The CPU and SoC (System-On-a-Chip) (microcontroller in the embodiment) used in the embedded system have very small ROM (Read Only Memory) and RAM (Random Access Memory) sizes. For example, in an embedded system in which Linux (registered trademark) is installed in an OS, the minimum size of ROM and RAM is about 64 MB, respectively, but the size of ROM and RAM in a microcontroller is about 2 MB at the maximum.

When utilizing ROM or RAM data in a PC or the like, it is common to use a file system to manage the data in file units. Even in an embedded system, when the OS provides a file system function (embedded Linux, etc.), data can be managed in file units. However, when using a lightweight OS such as a real-time OS that does not assume a file system, either port the file system used in a PC or the like, or manage the ROM data directly without using the file system. There is a need to.

There is a FAT file system as a conventional example of a file system. In the FAT file system, various management data are arranged in the ROM in the same manner as the user data, and a reference table called "File Allocation Table (FAT)" is provided. The FAT is a table for managing fragmented data on the ROM or the hard disk as one file, and occupies a certain memory area according to the capacity of the ROM. Further, in the FAT file system, there is a concept of a directory (also called a folder) in addition to a file, and the folder is managed in the same manner as a file and occupies a certain memory area.

Another conventional example of a file system is JFFS2 (Journaling Flash File System, version 2). JFFS2 is a file system used in Linux installed in an embedded system, and is made on the assumption that a non-volatile memory such as a flash ROM is used. The flash ROM is composed of a plurality of sectors, and each sector is an erasing unit when erasing data in the flash ROM. In JFFS2, a plurality of nodes (data chunks) are recorded in one sector, and one file is composed of a plurality of nodes.

The advantage of being able to use the file system is great even in embedded systems with small ROM and RAM sizes. By using a file system, for example, files can be managed using a common API (Application Programming Interface) in a plurality of programs, and data can be easily added or deleted. On the other hand, conventional file systems (FAT file system, JFFS2, etc.) use a large amount of ROM area due to file and directory management information, so it is difficult to use in embedded systems with small ROM and RAM sizes. ..

In embedded systems with small ROM and RAM sizes, the size of data to be stored is assumed to be at most several hundred KB. Further, in an embedded system, basically, the data written in the ROM at the beginning (for example, at the time of shipment from the factory) is continuously used as it is, and the addition or deletion of the data is rare. Also, since there are few types of files in embedded systems, there is no need to classify files by directory or extension. In consideration of these, in the embodiment, a file system suitable for an embedded system having a small size of ROM and RAM is proposed.

FIG. 1 shows the hardware configuration of the microcontroller 10 of the embodiment. The microcontroller 10 includes a CPU core 12, a ROM 14, a RAM 16, and an input / output device 18. The CPU core 12 executes various data processing. The ROM 14 and the RAM 16 store data that is referenced or updated in data processing by the CPU core 12. The ROM 14 of the embodiment is a rewritable flash ROM. Further, the RAM 16 of the embodiment is an SDRAM (Synchronous Dynamic RAM). The input / output device 18 transmits / receives data to / from an external device.

FIG. 2 is a block diagram showing a functional block of the file management system 20 of the embodiment. The file management system 20 of the embodiment is introduced into the microcontroller 10 of FIG. 1, and realizes a file system for managing data in a file unit in the microcontroller 10.

The file management system 20 includes a data area 22 and a management area 24 in the ROM 14. The data area 22 is a memory space in which file data, which is data to be managed as a file, is stored. The data area 22 is divided into a plurality of fixed-length sectors, and one file data is stored in consecutive sectors in principle. In the embodiment, the size of each sector is 512 bytes.

In FIG. 2, five file data (files f1 to f5) are stored in the data area 22. In ROM 14, file data is arranged in sector units. For example, the file f1 is arranged from the start address of the sector s0 to the sector s2. The entire area of sector s0 and sector s1 is filled with the data of file f1, and the remaining data of file f1 is arranged in a part or all area of sector s2.

The management area 24 is a memory space in which attribute information related to file data is stored. When one file data is stored in a data area (typically one or more consecutive sectors), one attribute information (also referred to as a "management block" in the embodiment) is stored in the management area 24. File. Hereinafter, one sector or a plurality of sectors are collectively referred to as a "sector group". As an exception, when one file data is distributed and stored in a discontinuous sector group, one management block is stored in the management area 24 for each discontinuous sector group.

In the management block corresponding to one file data, the identification name (typically the file name) of the one file data and the start position of consecutive sectors in which the one file data is stored are recorded. .. The management area 24 stores management information including a plurality of management blocks corresponding to the plurality of file data stored in the data area 22.

The management block 26a, management block 26b, and management block 26c (collectively referred to as "management block 26") are stored in the management area 24 of FIG. The management block 26a corresponds to the file f1, and the sector s0 is recorded as the start sector. The management block 26b corresponds to the file f2, and the sector s3 is recorded as the start sector. The management block 26c corresponds to the file f3, and the sector s5 is recorded as the start sector.

FIG. 3 shows the configuration of management information stored in the management area 24. The management information includes a management header (16 bytes) and management blocks for the number of files to be managed (the size of one management block is 16 bytes). In the data type "start sector" in the management block, the start position where the file data is stored, and in the embodiment, the start sector number where the file data is stored are recorded. As a modification, the address of the start position of the sector in which the file data is stored may be recorded in the "start sector".

In the data type "status" in the management block, the status related to the storage of file data is recorded, and for example, one of the busy, free, and deleted status is recorded. As will be described later, "in use" may be subdivided to indicate which part of the file data is divided and stored in discontinuous sector groups. For example, one of in use (beginning), in use (intermediate), and in use (end) may be recorded.

In the data type "ext info" in the management block, when the file data is stored in consecutive sector groups (that is, without division), or when the file data is distributed and stored in non-continuous sector groups (that is, with division). ) And the first part of the file data, the number of sectors of the continuous sector group in which the file data (the first part) is stored is recorded. On the other hand, when the file data is distributed and stored in non-contiguous sectors (that is, with division) and is a part other than the beginning of the file data, "ext info" contains a serial number (that is, a serial number according to the division mode of the file data). The number indicating which number of multiple management blocks corresponds to) is recorded.

In the data type "size" in the management block, when the file data is stored in consecutive sector groups (that is, without division), or when the file data is distributed and stored in non-continuous sector groups (that is, with division). If it is the first part of the file data, the entire size of the file data is recorded. On the other hand, when the file data is distributed and stored in non-contiguous sector groups (that is, there is division) and is a part other than the beginning of the file data, the size of the file data stored in the sector group corresponding to the management block is large. Recorded.

In the file management system 20 of the embodiment, as a general rule, one file data is stored in a continuous sector group, and one management block including the minimum attributes necessary for managing one file data is a management area 24. Stored in. As a result, even if the microcontroller 10 has a small size of the ROM 14 and the RAM 16, the file system can manage the data of the ROM 14 in file units, and the consumption and the processing amount of the ROM 14 and the RAM 16 are small. realizable.

For example, in the file management system 20 of the embodiment, when the size of the management area 24 is 4KB, (4096/16) -1 = 255 file data can be managed.

Returning to FIG. 2, the file management system 20 includes a sector map 28 in the RAM 16. The sector map 28 is data for determining whether or not file data can be written to the data area 22, and is data indicating the usage state of each sector of the data area 22. The usage status of each sector includes the usage status, free status, and deletion status.

The file management system 20 includes a control unit 30. The control unit 30 includes an activation processing unit 31, a reading unit 32, a writing unit 33, a management area update unit 34, and a deletion unit 35. A computer program including a plurality of modules corresponding to the plurality of functional blocks may be stored in a recording medium, and the computer program may be installed in the ROM 14 via the recording medium. Alternatively, the external device may send the computer program to the microcontroller 10 and the computer program may be installed in the ROM 14. The CPU core 12 of the microcontroller 10 may exert the function of each functional block by reading the computer program into the RAM 16 and executing the program.

Further, the read unit 32, the write unit 33, the management area update unit 34, and the delete unit 35 are implemented as library programs that are dynamically or statically linked to the application program that uses the file system provided by the file management system 20. May be done.

The startup processing unit 31 executes the processing at the time of starting the file management system 20. The startup processing unit 31 reads the management information (that is, the information of a plurality of management blocks) stored in the management area 24 and stores it in the RAM 16. Further, the activation processing unit 31 generates a sector map 28 showing the usage state of each sector of the data area 22 in the RAM 16 based on the management information stored in the management area 24. Since the access speed to the RAM 16 (SDRAM in the embodiment) is faster than the access speed to the ROM 14 (flash ROM in the embodiment), the management information of the management area 24 and the sector map 28 can be arranged in the RAM 16. The time required to read and write file data can be shortened.

When the reading unit 32 is requested to read the file data stored in the data area 22, the reading unit 32 executes the reading process of the file data. When the writing unit 33 is requested to write the file data to the data area 22, the writing unit 33 executes the file data writing process. When the deletion unit 35 is requested to delete the file data stored in the data area 22, the deletion unit 35 executes the file data deletion process. The request source for reading, writing, and deleting is typically an application program running on the CPU core 12.

When the file data stored in the data area 22 should be deleted, the deletion unit 35 leaves the file data stored in the data area 22 without erasing it, that is, the sector in which the file data to be deleted is stored. Do not erase. On the other hand, the deletion unit 35 records that the file data has been deleted in the management block corresponding to the file data to be deleted. Specifically, the deletion unit 35 records the "deletion status" in the status of the management block in which the name of the file data to be deleted is recorded. As will be described later, when new file data should be stored in the data area 22, the writing unit 33 stores the new file data in the sector indicated by the management block in which the deleted state is recorded.

When the management information stored in the RAM 16 is updated, the management area update unit 34 stores the updated management information in an area of ROM 14 different from the area of ROM 14 in which the management information before the update is stored. Although the ROM 14 (flash ROM in the embodiment) has a rewrite limit number of times, the service life of the ROM 14 can be extended by distributing the writing area of the management information (that is, wear leveling).

FIG. 4 schematically shows wear leveling of management information. Each time the management information read into the RAM 16 is updated, the management area update unit 34 uses the updated management information in the first management area 24a (sector N), the second management area 24b (sector N + 1), and the third. The management area 24c (sector N + 2) and the fourth management area 24d (sector N + 3) are cyclically stored in this order. When the management area update unit 34 stores the updated management information in a certain sector (for example, sector N + 1), the management area update unit 34 erases the sector (for example, sector N) in which the management information before the update is stored.

The operation of the file management system 20 with the above configuration will be described.
First, the operation at the time of starting the file management system 20 will be described. FIG. 5 is a flowchart showing the operation at the time of starting the file management system 20. The startup processing unit 31 reads the management information from the management area 24 in which the management information is stored in the plurality of management areas 24, and stores the read management information in the RAM 16 (S10). The startup processing unit 31 generates a sector map 28 based on the management information (which may be the management information of the management area 24) read into the RAM 16 and stores it in the RAM 16 (S12).

Next, the operation at the time of reading the file data will be described. The reading unit 32 receives a file data reading request from a computer program process running on the CPU core 12. This computer program is a computer program in which a process of reading the file data of the ROM 14 is implemented by using the file system provided by the file management system 20. In the read request, the file name to be read is specified.

The reading unit 32 refers to the management information read into the RAM 16 to identify the management block 26 in which the file name specified in the read request is recorded, and determines the start sector and size recorded in the management block 26. Identify. The reading unit 32 reads the file data of the specified size from the start sector of the specified data area 22, and outputs the read file data to the requesting program.

Next, the operation at the time of writing the file data will be described. FIG. 6 is a flowchart showing an operation at the time of writing file data. The writing unit 33 receives a file data writing request from the process of the computer program being executed by the CPU core 12. This computer program is a computer program in which a process of writing file data to the ROM 14 is implemented by using the file system provided by the file management system 20. In the write request, the address and the file name on the RAM 16 are specified for the file data to be written to the ROM 14.

The writing unit 33 that has received the write request refers to the management information read in the RAM 16, and the management area 24 has a free space for storing the management block (typically a new management block) for the file data to be written this time. Check if it exists. Further, the writing unit 33 refers to the sector map 28 and confirms whether or not there is a free sector in which the file data can be written (including a sector in a deleted state as described later). If there is a free space in the management area 24 (Y in S20) and there is a free sector in the data area 22 (Y in S22), the writing unit 33 is provided with the file data to be written in the RAM 16. Write to the sector cache (S24).

The sector cache is a storage area of the same size as one sector (512 bytes in the embodiment) provided for writing data in sector units. The sector cache temporarily stores 512 bytes of data in the file data. If there is no free space in the management area 24 (N in S20) or there is no free sector in the data area 22 (N in S22), the writing unit 33 returns an error to the requesting program and ends the writing process. (S26).

If the writing to the last data in the file data is incomplete (N in S28) and the writing of data for one sector to the sector cache is also incomplete (N in S30), the process returns to S24 and is sent to the sector cache. Continue writing file data. When the writing of the data for one sector to the sector cache is completed (Y in S30), the writing unit 33 writes the data for one sector stored in the sector cache to the free sector of the data area 22 (S32). The writing unit 33 records "in use" in the area of the sector map 28 corresponding to the free sector in which the file data is written (S34), and returns to S24. That is, the writing unit 33 writes the rest of the file data to the sector cache.

When writing to the last data in the file data to the sector cache is completed (Y in S28), the writing unit 33 writes the data for one sector stored in the sector cache to the free sector of the data area 22 (S36). ). The writing unit 33 records "in use" in the area of the sector map 28 corresponding to the free sector in which the file data is written (S38). Here, it is assumed that the file data is stored in a continuous sector group in the data area 22. The writing unit 33 is a management block corresponding to the written file data, generates one management block in which a file name, a start sector, etc. are set, and adds the management block to the management information read into the RAM 16. (S40).

Further, the writing unit 33 updates the management header in the management information read into the RAM 16 (S42). For example, the writing unit 33 increments the number of files in the management header. The management area update unit 34 stores the updated management information in a management area (for example, a second management area 24b) different from the management area (for example, the first management area 24a) in which the management information before the update is stored (for example, the second management area 24b). S44).

Next, the operation at the time of deleting the file data will be described. FIG. 7 is a flowchart showing the operation when the file data is deleted. The deletion unit 35 receives a file data deletion request from the computer program process running on the CPU core 12. This computer program is a computer program in which a process of deleting file data from the ROM 14 is implemented by using the file system provided by the file management system 20. In the deletion request, the file name of the file data to be deleted is specified.

The deletion unit 35 refers to the management information read into the RAM 16 and identifies a management block (referred to here as a “target management block”) in which the file name specified in the deletion request is recorded. The deletion unit 35 identifies one or more sectors of the data area 22 in which the file data to be deleted is stored, based on the start sector and the size recorded in the target management block. The deletion unit 35 updates the sector map 28 so that the information of one or more sectors in which the file data to be deleted is stored is in the “deleted state” (S50).

Further, the deletion unit 35 changes the “status” of the target management block in the management information read into the RAM 16 to the deleted state (S52), and the deletion unit 35 also changes the management header in the management information read into the RAM 16. Is updated, for example, the number of files in the management header is decremented (S54). The management area update unit 34 stores the updated management information in a management area (for example, a second management area 24b) different from the management area (for example, the first management area 24a) in which the management information before the update is stored (for example, the second management area 24b). S56).

FIG. 8 schematically shows a state in which the file data is deleted. When the file f2 in the data area 22 is deleted, the "deleted state" is recorded in the management block 26b corresponding to the file f2, and the "deleted state" is also recorded in the sector map 28 area corresponding to the sector s3 and the sector s4. Is recorded. Here, when the new file f6 is stored in the data area 22, in the embodiment, the file f6 is stored from the beginning of the free sector (for example, sector s11) in preference to reusing the deleted sector.

That is, the writing unit 33 preferentially selects a free sector as a storage destination of new file data over the sector indicated by the management block 26 in which the deletion is recorded. As a result, the number of times the data area 22 is rewritten for the same sector can be reduced, and the service life of the data area 22 can be extended. The writing unit 33 may reuse the management block 26b corresponding to the deleted file f2 for the newly added file f6. In this case, the "status", "ext info", "size", and "name" of the management block 26b can be changed according to the file f6, while the "start sector" can be used without any change.

When the file data is repeatedly deleted in the file management system 20, the "in use" area and the "deleted state" area are mixed in the data area 22. When the file data cannot be written to the free sector, the writing unit 33 reuses the deleted sector. For example, the writing unit 33 writes one file data to a non-continuous sector group. By effectively utilizing the deleted sector, more file data can be managed by the file management system 20.

9 (a) and 9 (b) show an example of writing file data to a non-contiguous sector group. The sectors s3, s4, and s7 of the data area 22 are in use. On the other hand, sectors s0 to sector s2, sector s5, sector s6, and sector s8 and subsequent sectors of the data area 22 are in the deleted state. In this example, the file f7 to be written has a size that occupies 8 sectors.

As shown in FIG. 9A, the writing unit 33 stores the head portion of the file f7 in sectors s0 to sector s2, stores the intermediate portion of the file f7 in sectors s5 and sector s6, and stores sectors s8 to sectors. The last part of the file f7 is stored in s10. When the write-destination sector is in the deleted state, the data to be deleted remains in that sector without being erased. Therefore, the writing unit 33 writes data to that sector after performing erase processing on that sector. ..

When writing file data to a non-contiguous sector group, the writing unit 33 allocates one management block 26 to each continuous sector sector group. In the example of FIG. 9A, the writing unit 33 stores the management block 26a, the management block 26b, and the management block 26c in the management area 24. The management block 26a corresponds to the first portion of the file f7 (in other words, sector s0 to sector s2), and sector s0 is recorded in the start sector. The management block 26b corresponds to an intermediate portion (in other words, sector s5 and sector s6) of the file f7, and sector s5 is recorded in the start sector thereof. The management block 26c corresponds to the end portion of the file f7 (in other words, sectors s8 to s10), and sector s8 is recorded in the start sector thereof.

FIG. 9B shows the data recorded in each management block. In the management block 26a, "in use (head)", which is a flag indicating that it is the head part, is recorded in status, and the number of sectors in the head part ("3" in the example of FIG. 9) is recorded in ext info. .. Further, the size of the entire file data is recorded in the size of the management block 26a.

In the management block 26b, "in use (intermediate)", which is a flag indicating that it is an intermediate part, is recorded in status, and a serial number ("1" in the example of FIG. 9) is recorded in ext info. Further, the number of sectors in the intermediate portion (“2” in the example of FIG. 9) is recorded in the size of the management block 26b. Since the entire area of the sector in which the intermediate portion of the file f7 is stored is the data of the file f7, the number of sectors in the intermediate portion is substantially synonymous with the data size of the intermediate portion.

In the management block 26c, "in use (end)", which is a flag indicating the end part, is recorded in status, and a serial number ("2" in the example of FIG. 9) is recorded in ext info. Further, the used size is recorded in the size of the management block 26c. Since a part of the last sector (sector s10 in the example of FIG. 9) may be unused, the actual data size of the last part is recorded in the size of the management block 26c, not the number of sectors. ..

The process of reading the fragmented file data shown in FIGS. 9A and 9B will be described. When the reading unit 32 receives the reading request for which the file name "test.bin" is specified, the reading unit 32 refers to the management information of the management area 24 (actually, the management information read into the RAM 16; the same applies hereinafter) and files. The management block 26a in which "test.bin" is recorded in the name and "in use (top)" is recorded in the status is specified. The reading unit 32 reads data for the number of sectors recorded in ext info from the sector s0, which is the starting sector of the management block 26a, as the data of the head portion.

Next, the reading unit 32 refers to the management information of the management area 24 and identifies the management block 26b in which "test.bin" is recorded in the file name and the serial number "1" is recorded. The reading unit 32 reads data for the number of sectors recorded in size from the sector s5, which is the starting sector of the management block 26b, as data in the intermediate portion.

Next, the reading unit 32 refers to the management information of the management area 24 and identifies the management block 26c in which "test.bin" is recorded in the file name and the serial number "2" is recorded. The reading unit 32 reads the data of the length recorded in size from the sector s8, which is the starting sector of the management block 26c, as the data of the trailing portion. The reading unit 32 generates the file data of "test.bin" requested by synthesizing the data of the head portion, the data of the middle portion, and the data of the tail portion, and returns the file data to the requesting program. ..

The present disclosure has been described above based on the examples. This embodiment is an example, and it will be understood by those skilled in the art that various modifications are possible for each component or combination of each processing process, and that such modifications are also within the scope of the present disclosure.

Any combination of the examples and modifications described above is also useful as an embodiment of the present disclosure. The new embodiments resulting from the combination have the effects of the combined examples and the modifications. It is also understood by those skilled in the art that the functions to be fulfilled by each of the constituent elements described in the claims are realized by a single component or a cooperation thereof shown in the examples and modifications.

The techniques described in the examples and modifications may be specified by the following items.
[Item 1]
A data area (22), which is a memory space for storing file data, and a management area (24), which is a memory space for storing attribute information related to file data, are provided.
The data area (22) is divided into a plurality of sectors, and one file data is stored in consecutive sectors.
When the one file data is stored in the data area, one attribute information indicating the identification name of the one file data and the head position of the continuous sector is stored in the management area. A file management system (20) characterized by.
[Item 2]
A plurality of management areas (24) are provided in a rewritable ROM (14).
When the attribute information stored in the first management area (24a) is read into the RAM (16) and the attribute information is updated, a second management area different from the first management area (24a) is used. The file management system (20) according to item 1, wherein the updated attribute information is stored in (24b).
[Item 3]
The management area (24) is provided in the ROM (14).
This data is used to determine whether or not file data can be written to the data area (22) based on the attribute information stored in the management area (24) when the file management system (20) is started. The file management system according to item 1 or 2, further comprising a generation unit (31) for storing data (28) indicating a usage state of each sector of the data area (22) in a RAM (16). (20).
[Item 4]
When the file data stored in the data area (22) should be deleted, the file data stored in the data area (22) is left unerased and the deletion is recorded in the attribute information corresponding to the file data. Delete part (35) and
When new file data should be stored in the data area (22), a writing unit (33) that stores the new file data in the sector indicated by the attribute information in which the deletion is recorded, and
The file management system (20) according to any one of items 1 to 3, further comprising.
[Item 5]
Item 4 characterized in that the writing unit (33) preferentially selects a free sector as a storage destination of the new file data over the sector indicated by the attribute information in which the deletion is recorded. The file management system (20) described in.

10 Microcontroller, 14 ROM, 16 RAM, 20 File management system, 22 Data area, 24 Management area, 31 Startup processing unit, 33 Writing unit, 34 Management area update unit, 35 Delete unit.

Claims (5)

It has a data area that is a memory space for storing file data and a management area that is a memory space for storing attribute information related to file data.
The data area is divided into a plurality of sectors, and one file data is stored in consecutive sectors.
When the one file data is stored in the data area, one attribute information indicating the identification name of the one file data and the head position of the continuous sector is stored in the management area. A file management system featuring. With a rewritable ROM for multiple management areas
When the attribute information stored in the first management area is read into the RAM and the attribute information is updated, the updated attribute information is stored in a second management area different from the first management area. The file management system according to claim 1, wherein the file management system is characterized in that. The management area is provided in ROM.
Data for determining whether or not file data can be written to the data area based on the attribute information stored in the management area when the file management system is started, and the use of each sector of the data area. The file management system according to claim 1 or 2, further comprising a generation unit that stores data indicating a state in a RAM. When the file data stored in the data area should be deleted, a deletion unit that records that the file data stored in the data area is deleted without being deleted and deleted in the attribute information corresponding to the file data, and a deletion unit.
When new file data should be stored in the data area, a writing unit that stores the new file data in the sector indicated by the attribute information in which the deletion is recorded, and a writing unit.
The file management system according to any one of claims 1 to 3, further comprising. The fourth aspect of claim 4, wherein the writing unit preferentially selects a free sector as a storage destination of the new file data over the sector indicated by the attribute information in which the deletion is recorded. File management system.

Images