File resource access method and device without file system platform and medium

Abstract

The invention discloses a file resource access method without a file system platform. The method comprises the following steps: distributing a memory space for respectively storing file resources and a file list area; file resources are put into a PC folder; defining a file object in the code; searching all files in the folder on the PC; converting the binary data of the file into an array of a system platform programming language; formatting an array name and redefining a variable; the array length is formatted and redefined; the array and the length are stored by using a. C file; determining a file object for generating an array name file, adding the file object to a file list area, and storing all converted file objects by using an array; traversing all files and defining header file integration; and establishing a general interface for file operation, and executing a function for accessing the file. According to the method, file resources can be accessed with high performance and high efficiency, a file system does not need to be carried, the cost is low and the workload is small.

Description

Technical Field

[0001] The present invention relates to the technical field of data file access, and in particular to a file access method, device and storage medium in a low-performance embedded platform without a file system. Background Art

[0002] In embedded systems, file access is an important means of storing and reading data. For embedded platforms with sufficient resources, the use of file systems (such as FatFS, LittleFS, etc.) can provide efficient and flexible data management solutions. These file systems usually support standard operating interfaces, such as POSIX API, allowing developers to easily perform file operations and easy cross-platform porting.

[0003] However, when applying such file systems in low-performance embedded environments, although using file systems to manage storage space is a common practice, this approach has several significant problems:

[0004] (1) The code size of the file system is relatively large, which not only increases the demand for program storage space, but also increases the capacity requirements for hardware such as storage Flash and processor RAM, thereby indirectly pushing up the overall hardware cost;

[0005] (2) Due to the differences between different platforms, the workload of file system code transplantation increases. Transplanting file system code to new or uncommon or embedded platforms that do not support transplantation often requires additional time and effort.

[0006] (3) When there are requirements for access performance, in order to achieve specific application performance indicators, optimization and adaptation require a lot of debugging time;

[0007] (4) It has requirements for the basic platform and relies on the services provided by the underlying operating system, such as the RTOS scheduling mechanism or dynamic memory allocator, which further limits the scope of application.

[0008] At the same time, using commercial file systems in existing technologies will bring additional cost burdens, and choosing open source projects requires carefully evaluating licensing terms to avoid potential legal risks.

[0009] To this end, the present application specifically proposes a file access method, device and storage medium in a low-performance embedded platform without a file system to solve the above technical problems. Summary of the Invention

[0010] The main purpose of the present invention is to provide a file access method in a low-performance embedded platform without a file system, so as to solve the technical problems raised in the background technology.

[0011] The present invention adopts the following technical solutions to solve the above technical problems:

[0012] A method for accessing file resources on a non-file system platform, comprising: performing the following steps by a computer device:

[0013] S1. On a development board without a file system, allocate designated memory space for storing file resources.

[0014] S2 allocates a designated memory space for storing the file list area without a file system platform;

[0015] S3. Place the file resources to be used in the designated folder on the PC and name them using letters + numbers.

[0016] S4. Define a file object in the code. The file object attributes include: file name, array variable name, array length, and the file object is named struct file_obj.

[0017] S5. Search all files in the specified folder on the PC and iterate through each file;

[0018] S6. Convert the binary data of the file into an array in the programming language used by the non-file system platform, where the array is represented as the value corresponding to the array variable name in the file object;

[0019] S7. Format the array name and define the array variable in the form of file name + prefix;

[0020] S8. Format the array length using C language macros, defining the array length in the form of file name + prefix and suffix;

[0021] S9. The array and length obtained in step S6 are saved in the project path using a .c file;

[0022] S10. Determine the file object for generating the array name file and add the file object to the file list area. The data in the file list area is an array of struct file_obj, the command is struct file_obj file_list[], and a separate .c file is used to save it, and the file name is file_list.c;

[0023] S11. After traversing and processing all files on the PC, N+1 .c files are generated, and a header file is defined for file integration;

[0024] S12. Establish a general interface for file operations, execute functions for accessing files, and achieve seamless connection with middleware that requires file operations.

[0025] Preferably, the memory in the step S1 and the step S2 is set to a non-volatile memory including NAND flash memory, NOR flash memory, and flash memory.

[0026] Preferably, the file object attributes in step S4 further include file status information flag and file location information curr_index, wherein:

[0027] flag=0 means off, flag=1 means on;

[0028] curr_index is used to indicate the current index or current position of a file block.

[0029] Preferably, in the step S8, the prefix is ​​named after the file resource name, and the suffix is ​​represented by length, which is used for macro definition as the length.

[0030] Preferably, in the step S8, the macro definition of the C language is used to define the array length, which replaces the length specified during array declaration and uses dynamic memory allocation to define the array length.

[0031] Preferably, in the step S9, the .c file is replaced with a file format obtained based on other programming languages.

[0032] Preferably, the file operations in step S12 include file opening, file reading, file writing and file closing.

[0033] Preferably, the specific operation steps of executing the function for accessing the file in step S12 include:

[0034] The corresponding array is found using the table in the file list area, where the file list area is represented as the array structfile_obj file_list[], which is used to contain the file objects converted by the tool.

[0035] In another aspect, the present invention further discloses a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the processor executes the steps of the above method.

[0036] On the other hand, the present invention further discloses a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the above method.

[0037] As can be seen from the above technical solution, the present invention provides a method for accessing file resources without a file system platform. Compared with the prior art, the present invention has the following advantages:

[0038] 1. The present invention does not need to rely on the traditional file system, can reduce the overall code volume, and is convenient for external maintenance and use of the system. In addition, by selecting a chip with less Flash and RAM, it can further reduce costs.

[0039] 2. The present invention can provide a structured way to manage files, thereby improving file access efficiency and achieving high-performance data access on low-performance embedded platforms.

[0040] 3. The present invention has low transplantation workload. For platforms that map Flash to the MCU bus, it can reduce the workload of software transplantation and reduce the dependence on a specific hardware environment.

[0041] 4. The present invention can seamlessly connect to applications or middleware that need to perform file operations, thereby improving system compatibility and flexibility, and facilitating developers to edit and develop applications across platforms. At the same time, it has no requirements for the basic platform, and both front-end and back-end development frameworks and RTOS are acceptable, making it easy to cross platforms.

[0042] 5. The present invention solves the problem of efficient file access in low-end embedded environments, and can access file resources with high performance and high efficiency, without the need for a file system, requiring less debugging time and at low cost.

[0043] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become easy to understand through the following description. Of course, it is not necessary to achieve all of the above-mentioned advantages simultaneously in order to implement any product of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings, which constitute part of this application, are intended to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are intended to explain the present invention and do not constitute an undue limitation of the present invention. In the accompanying drawings:

[0045] Figure 1 Schematic diagram of the data processing flow of the present invention;

[0046] Figure 2 Schematic diagram of the data access process of the present invention. DETAILED DESCRIPTION

[0047] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. In the absence of conflict, the embodiments in this application and the features in the embodiments can be combined with each other. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0048] In the embodiment, see Figures 1 to 2 .

[0049] like Figure 1 and Figure 2 As shown, the file access method proposed in the embodiment of the present invention on a platform without a file system has the following specific steps for accessing data within the system: Figure 2 As shown in the figure, the data processing inside the specific system is as follows Figure 1 As shown, the data processing performed by computer equipment includes the following steps:

[0050] S1. On a development board without a file system, allocate some space for storing file resources based on the flash device model of the development board (other non-volatile memory can also be plugged in);

[0051] In a specific embodiment, Flash space is allocated for storing file resources;

[0052] In addition, it should be noted that memories other than flash can also be used, such as NAND flash, NOR flash, etc., which are mainly related to embedded platforms;

[0053] S2. Allocate Flash space for storing the file list area;

[0054] It should be noted that by allocating space for file storage based on the Flash device model on a development board without a file system, without relying on a traditional file system, the overall code size can be reduced, making it easier to maintain and use the system externally. In addition, by selecting a chip with less Flash and RAM, costs can be further reduced.

[0055] S3. Place the required file resources into the res folder on your PC. Name the file resources alphanumeric for easy retrieval.

[0056] It should be noted that the folder here can be customized;

[0057] In a specific embodiment, assume that there are 100 files therein, named test1.png to test100.png;

[0058] S4. Define a file object in the code. This file object has the following attributes {file name, array variable name, array length, other parameters} and can be named struct file_obj

[0059] It can also be explained that other parameters include file object attributes including file status and file location, and specifically, the file object attributes also include file status information flag and file location information curr_index, where:

[0060] Flag indicates the file opening status, flag = 0 means closed, flag = 1 means open;

[0061] curr_index is used to indicate the current index or current position of the file block;

[0062] At this time, by defining the file status information flag and the file location information curr_index, it is possible to avoid searching from the beginning every time a file is searched, reducing the computational overhead and improving the efficiency of the code.

[0063] S5. Use a tool on your PC to search for all files in the res folder and iterate through each file.

[0064] S6. You can use tools on your PC to convert the binary data of the entire file resource (here, the file test_n.png) into an array (the value corresponding to the array variable name) in the C programming language (C is commonly used in embedded platforms, but other languages ​​such as assembly and Rust can also be used) to facilitate subsequent programming language calls;

[0065] S7. Format the array name and define the array variable in the form of file name + prefix, for example, uint8_tfile_test_n_png[];

[0066] It should be noted here that the prefix in the array variable name can be customized, but it must comply with the coding standards and is generally prefixed with the name of the file resource;

[0067] S8. To improve the versatility and reusability of the program, increase readability and maintainability, and reduce input errors, format the array length. Use C language macros to define the array length in the form of file name + prefix and suffix, for example, #define CN_file_test_n_png_length(xx);

[0068] The prefix is ​​usually the file resource name command, and the suffix is ​​usually length to indicate the length of the macro definition;

[0069] At this point, it can also be added that in addition to using C language macro definitions, you can also specify the length when declaring the array and use dynamic memory allocation to achieve the same effect;

[0070] In addition, by converting the file into an array in C language and using macro definitions to specify the array length, the file content can be stored in the memory in an easy-to-process form, thereby simplifying the file operation logic, reducing the workload of the overall system software porting and reducing the dependence on a specific hardware environment;

[0071] S9. To reduce the file size, save the array and length of the file obtained in step S6 into a .c file in the project directory according to the programming language. The file can have the same name as the original file for easier reading.

[0072] S10. The tool will generate a file object for file_n.png and add this file object to the file list area. The data in the file list area is an array of struct file_obj, the command is struct file_obj file_list[], and a separate .c file is used to save it. The file name can be file_list.c.

[0073] It should be noted here that a file_list.c file is generated here. File_list.c defines an array of struct file_obj to save all the file objects converted by the tool, so each file object can be indexed through the array;

[0074] S11. After the tool traverses all files, it will generate N+1 .c files. For easy integration, you can also define a header file;

[0075] It should be noted that the header file here integrates the array declaration of all N file objects and the declaration of file_list[] of one file list area to facilitate mutual reference between file objects;

[0076] S12. Write a general interface for file operations (file open, read, write, and close operations), such as a POSIX interface, to implement functions for accessing files (the implementation method mainly uses a table in the file list area to find the corresponding array. The efficient access characteristics of the array improve the performance of the present invention). It can seamlessly connect with middleware that requires file operations;

[0077] By building a universal file operation interface based on the file list area, it can seamlessly connect to applications or middleware that require file operations, thereby improving system compatibility and flexibility and making it easier for developers to edit and develop applications across platforms.

[0078] It should also be noted that the file list area is specifically the struct file_obj file_list[]. This array contains the file objects converted by the tool and is used to quickly index the file objects. The array table is formed by allocating continuous space in memory and storing data elements of the same type. At this time, the array elements are the definition of structfile_obj, including the file name, array variable name, array length, and other parameters.

[0079] In summary, this method can provide a structured way to manage files by defining file objects and their attributes (file names, array variable names, etc.) and associating them with actual file data, thereby improving file access efficiency and achieving high-performance data access on low-performance embedded platforms.

[0080] Therefore, this method solves the problem of efficient file access in low-end embedded environments. It can access file resources with high performance and high efficiency, does not require a file system, takes less debugging time, is low-cost, and has low porting workload. For platforms that map Flash to the MCU bus, there is no porting work. At the same time, there are no requirements for the basic platform. Both front-end and back-end development frameworks and RTOS are acceptable, making it easy to cross-platform.

[0081] In addition, in actual use, this method refers to Figure 2 As shown, it is possible to access file resources without a file system (embedded system), and by converting the file resources to be accessed into a C language array, the file access is completed through the array index. It is suitable for environments that have strict requirements on startup time and memory usage or do not have a traditional file system at all. It is also free from the cost pressure of commercial file systems and the pollution risk of open source file systems. It can access file resources with high performance and high efficiency, does not require a file system, is low in cost and workload, is easy to cross-platform, and is convenient for practical application.

[0082] In another aspect, the present invention further discloses a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the processor executes the steps of the above method.

[0083] On the other hand, the present invention further discloses a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the above method.

[0084] In another embodiment provided by the present application, a computer program product including instructions is also provided, which, when executed on a computer, enables the computer to execute any of the file resource access methods for a file system-free platform in the above embodiments.

[0085] It is understandable that the system provided by the embodiment of the present invention corresponds to the method provided by the embodiment of the present invention, and the explanation, examples and beneficial effects of the relevant contents can refer to the corresponding parts of the above method.

[0086] The embodiment of the present application further provides an electronic device, comprising a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus.

[0087] Memory for storing computer programs;

[0088] The processor is used to implement the file resource access method of the non-file system platform when executing the program stored in the memory.

[0089] The communication bus mentioned in the above electronic device may be a Peripheral Component Interconnect (PCI) bus or an Extended Industrial Standard Architecture (EISA) bus, etc. The communication bus may be divided into an address bus, a data bus, a control bus, etc.

[0090] The communication interface is used for communication between the above electronic device and other devices.

[0091] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Alternatively, the memory may be at least one storage device located away from the processor.

[0092] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0093] It should also be noted that electronic devices also include terminal devices, which can also be referred to as terminals, user equipment, mobile stations, mobile terminals, etc. Terminal devices can be mobile phones, smart TVs, wearable devices, tablet computers, computers with wireless transceiver functions, virtual reality terminal devices, augmented reality terminal devices, wireless terminals in industrial control, wireless terminals in unmanned driving, wireless terminals in remote surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, etc. The embodiments of this application do not limit the specific technologies and specific device forms used by terminal devices.

[0094] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium, or a semiconductor medium.

[0095] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

[0096] In addition, it should be noted that if the embodiments of the present invention involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are only used to explain the relative position relationship, movement status, etc. between the components under a certain specific posture. If the specific posture changes, the directional indications will also change accordingly.

[0097] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present invention, the descriptions of "first", "second", etc. are only for descriptive purposes and cannot be understood as indicating or suggesting their relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of such features. In addition, the meaning of "and / or" appearing throughout the text includes three parallel schemes. Taking "A and / or B" as an example, it includes scheme A, or scheme B, or schemes in which A and B are satisfied at the same time. In addition, in the embodiments of the present invention, "multiple" refers to more than two. In addition, the technical solutions between the various embodiments can be combined with each other, but it must be based on the ability of ordinary technicians in this field to implement. When the combination of technical solutions is mutually contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

Claims

1. A file resource access method without a file system platform, characterized in that: Follow these steps on your computer device: S1. On a development board without a file system, allocate a specified memory space for storing file resources; S2. Allocate a designated memory space of the non-file system platform for storing the file list area; S3. Put the file resources to be used into the specified folder of the PC and name the file resources in the form of letters + numbers; S4. Define a file object in the code. The file object attributes include: file name, array variable name, array length, and the file object is named struct file_obj. S5. Search all files in the specified folder on the PC and traverse each file; S6. Convert the binary data of the file into an array in the programming language used by the non-file system platform, where the array is represented as a value corresponding to the array variable name in the file object; S7. Format the array name and define the array variable in the form of file name + prefix; S8. Format the array length, use the C language macro definition, and define the array length in the form of file name + prefix and suffix; S9. The array and length obtained in step S6 are saved in a .c file under the project path; S10. Determine the file object of the generated array name file, and add the file object to the file list area, the data in the file list area is an array of struct file_obj, the command is struct file_obj file_list[], and a separate .c file is used to save it, and the file name is file_list.c; S11. After traversing and processing all the files on the PC, N+1 .c files are generated, and then a header file is defined for file integration; S12. Establish a general interface for file operations, execute functions for accessing files, and achieve seamless connection with middleware that requires file operations.

2. The file resource access method for a non-file system platform as claimed in claim 1, characterized in that: In the step S1 and the step S2, the memory is set to be a non-volatile memory including NAND flash memory, NOR flash memory, and flash memory.

3. The file resource access method for a non-file system platform as claimed in claim 1, characterized in that: The file object attributes in step S4 also include file status information flag and file location information curr_index, where: flag=0 means off, flag=1 means on; curr_index is used to indicate the current index or current position of a file block.

4. The file resource access method for a non-file system platform as claimed in claim 1, characterized in that: In the step S8, the prefix is ​​named after the file resource name, and the suffix is ​​represented by length, which is used for the macro definition as the length.

5. The file resource access method for a non-file system platform as claimed in claim 1, characterized in that: In the step S8, the macro definition of the C language is used to define the array length, replacing the length specified during array declaration and using dynamic memory allocation to define the array length.

6. The file resource access method for a non-file system platform as claimed in claim 5, characterized in that: In the step S9, the .c file is replaced with a file format obtained based on other programming languages.

7. The file resource access method for a non-file system platform as claimed in claim 1, characterized in that: The file operations in step S12 include file opening, file reading, file writing and file closing.

8. The file resource access method for a non-file system platform as claimed in claim 1, characterized in that: The specific operation steps of executing the function for accessing the file in step S12 include: The corresponding array is found using the table in the file list area, where the file list area is represented by the array struct file_obj file_list[], which is used to contain the file objects converted by the tool.

9. A computer-readable storage medium, characterized in that: A computer program is stored, and when the computer program is executed by a processor, the processor is caused to perform the steps of the method according to any one of claims 1 to 8.

10. A computer device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the method according to any one of claims 1 to 8.

Images