A dynamic loading method and system for embedded devices

Abstract

The invention discloses a dynamic loading method and system for embedded devices, comprising the following steps: step S1: a host burns firmware and dynamic library files to a storage medium of the embedded device; step S2: running the firmware in the memory of the embedded device; in step S1, a dynamic library generation module generates corresponding dynamic library files from dynamic library source codes according to functions, and the firmware source codes are integrated with the dynamic loading module and compiled to generate a firmware file; wherein, information of the corresponding dynamic library file is stored in the firmware file, and the information at least includes the dynamic library name, the starting address of the dynamic library file in the storage medium, and the memory size occupied by the dynamic library file in the storage medium; in step S2, when the firmware runs to load a certain library function, the corresponding dynamic library file is found in the storage medium according to the information of the corresponding dynamic library file stored in the firmware file, the dynamic library file is mapped to the memory, and a global dynamic symbol table of the dynamic library is constructed to call the library function.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer embedded software development and hardware interaction, and in particular relates to a dynamic loading method and system for embedded devices. Background Art

[0002] Dynamic library loading technology originated from the development of operating systems and programming languages, aiming to address the limitations of statically linked libraries in large software systems. Static libraries statically integrate code into applications during compilation, which increases application size. In contrast, dynamic libraries allow programs to load and close library files at runtime, reducing memory usage. For firmware developers, using statically linked libraries improves firmware reliability. However, dynamic libraries offer greater flexibility and consume less memory than static libraries in terms of memory resource utilization. Dynamically loaded modules allow programs to load and unload modules without restarting. This technology uses a specific API to query and call functions and variables in dynamic libraries. Dynamic libraries and dynamically loaded modules play an important role in embedded systems, desktop applications, web servers, and mobile devices. They not only improve software flexibility and scalability, but also bring greater efficiency to software development and a better user experience. With continued technological advancement, dynamic libraries and dynamically loaded modules are expected to continue to play a vital role in software engineering.

[0003] Many existing approaches to dynamically loading modules in embedded devices utilize a file system. For example, this involves mounting the file system to an SD card or flash memory, transferring the dynamic library to the file system, and then directly calling the dynamic library from the file system when needed. While mounting a file system is a relatively standardized process, it can present challenges in practice, such as ensuring file system compatibility with the target hardware (such as storage media and processors), selecting a file system type that suits the application, ensuring driver support, and addressing the numerous file system dependencies.

[0004] At the same time, existing technologies have also proposed local dynamic loading methods that directly read and write to flash memory without using a file system. When loading locally in an embedded system, the system directly reads from the flash memory. However, this method depends on the design and requirements of the hardware platform and is difficult to be widely applied to all embedded devices. This is because firmware can run on a variety of storage media, such as eMMC, SD cards, and solid-state drives.

[0005] Therefore, in view of the defects of the existing technology, it is necessary to propose a technical solution to solve the technical problems existing in the existing technology. Summary of the Invention

[0006] In view of this, it is indeed necessary to provide a dynamic loading method and system for embedded devices. By storing the library file related information in the firmware, the dynamic library file stored in the storage medium is directly mapped to the RAM when the firmware is running, and a dynamic symbol table is generated from all dynamic symbols in the library file in the RAM and stored in a new memory space. When the firmware is running and called, only the dynamic symbol table needs to be accessed instead of the library file. Since the library function is mapped to the RAM, the speed of dynamic library calling can be greatly improved. At the same time, the memory resources applied in the RAM are released immediately after the library file is called, reducing the risk of data leakage and improving the utilization of memory resources.

[0007] In order to solve the technical problems existing in the prior art, the technical solutions of the present invention are as follows:

[0008] A dynamic loading method for an embedded device comprises the following steps:

[0009] Step S1: The host burns the firmware and dynamic library files to the storage medium of the embedded device;

[0010] Step S2: running the firmware in the embedded device memory;

[0011] In step S1, the dynamic library generation module generates corresponding dynamic library files according to the functions of the dynamic library source code, integrates the dynamic loading module with the firmware source code and compiles it to generate a firmware file; wherein the firmware file stores information of the corresponding dynamic library file, and the information at least includes the dynamic library name, the starting address of the dynamic library file in the storage medium, and the memory size occupied by the dynamic library file in the storage medium;

[0012] In step S2, when the firmware runs to load a certain library function, the corresponding dynamic library file is found in the storage medium according to the information of the corresponding dynamic library file saved in the firmware file, and the dynamic library file is mapped to the memory and the global dynamic symbol table of the dynamic library is constructed to call the library function.

[0013] As a further improvement, in step S1 , a structure array is defined in the firmware file to store relevant information of the corresponding dynamic library file.

[0014] As a further improvement, step S2 further includes:

[0015] Map the called dynamic library file to the memory according to its address and occupied size in the storage medium;

[0016] Parse the dynamic library in memory and count the global function symbols;

[0017] Apply for corresponding memory space in memory according to the statistical global function symbols and build a global dynamic symbol table;

[0018] Call the corresponding library function according to the memory address corresponding to each symbol in the global dynamic symbol table;

[0019] After completing the call to the library file, close the dynamic library and directly release the space applied in the memory.

[0020] As a further improvement, in step S1, the dynamic loading module of the RT-Thread operating system is adopted and integrated into the firmware.

[0021] As a further improvement, the dynamic library generation module manages the dependencies between the dynamic libraries so that each dynamic library generates a dynamic library file independently.

[0022] As a further improvement, the firmware and the dynamic library files are stored consecutively in the storage medium or stored in different locations in the storage medium.

[0023] As a further improvement, in step S2, a call history table is stored in the memory to record the call information left after the initial call to the dynamic library; when different library functions are called in different threads and a thread is entered again, the call history table is used to load the corresponding dynamic library into the memory in advance.

[0024] As a further improvement, when the firmware runs to load a certain library function, the interface of the dynamic loading module of the RT-Thread operating system is used to load the corresponding dynamic library file;

[0025] After building the global dynamic symbol table, a library handle is returned through the dlopen interface to indicate the address of the symbol table.

[0026] When the firmware runs and calls a library function, it uses the dlsym interface to obtain the dynamic library function address. The dlsym interface contains two input parameters. The first is the library handle of the calling library file, which is the return value of dlopen. The second input parameter is the dynamic function name to be called. According to the function name to be called in dlsym, the required function address is found in the global dynamic symbol table in the memory.

[0027] After completing the call to the library file, use the dlclose interface to close or unload the dynamic link library opened by the dlopen interface before, and release the space allocated for the library file in the memory.

[0028] As a further improvement, in step S1, the storage medium is any one of flash, eMMC or SD card.

[0029] The present invention also discloses a dynamic loading system for embedded devices, comprising a host and an embedded device, wherein the host is used to generate firmware and dynamic library files and burn them to a storage medium of the embedded device. The host comprises:

[0030] Dynamic library generation module, used to compile each dynamic library source code into different dynamic library files according to functional blocks;

[0031] A firmware generation module, used to compile the firmware source code into firmware, wherein the firmware is integrated with a dynamic loading module, and the dynamic loading module is used to dynamically load the corresponding dynamic library file;

[0032] Dynamic library burning module, used to burn the generated firmware and dynamic library files to the storage medium of the embedded device;

[0033] The embedded device is used to run firmware in memory and dynamically load dynamic library files, wherein the loading call of the dynamic library is realized through the dynamic loading module in the firmware; the information of the corresponding dynamic library file is saved in the firmware file, and the information at least includes the dynamic library name, the starting address of the dynamic library file in the storage medium, and the memory size occupied by the dynamic library file in the storage medium; when the firmware runs to load a certain library function, the corresponding dynamic library file is found in the storage medium according to the information of the corresponding dynamic library file saved in the firmware file, and the dynamic library file is mapped to the memory and the global dynamic symbol table of the dynamic library is constructed to call the library function.

[0034] Compared with the prior art, the technical solution of the present invention has the following technical effects:

[0035] 1. Take full advantage of the flexibility of RAM and the fast reading speed of CPU to map dynamic library files in other storage media into RAM, and integrate all dynamic symbols in the library files in RAM into a new memory space, namely the dynamic symbol table in RAM. When the firmware is running and calling, only the dynamic symbol table needs to be accessed instead of the library file. In comparison, the dynamic symbol table is smaller and indexing the specified library function is faster.

[0036] 2. It can be applied to any storage medium. For example, the actual library functions are stored in storage media such as eMMC or flash. Memory resources are only requested in RAM when they are called. Mapping library functions to RAM takes advantage of RAM's fast read speed on the CPU. After calling the library file, the memory resources requested in RAM are immediately released, reducing the risk of data leakage and improving memory resource utilization.

[0037] 3. Use structure arrays to manage repository file related information, which is simple and efficient. Based on the consideration of memory resource utilization and data leakage,

[0038] 4. Leveraging RT-Thread's highly scalable software architecture, lightweight design, and low resource usage, we ported RT-Thread's dynamically loaded module, utilizing only a few interfaces. This minimizes overall resource usage, making firmware porting of this module relatively easy and convenient, ensuring widespread applicability. The overall call speed is fast, and embedded devices do not require an operating system or file system, resulting in fewer restrictions. Memory resource utilization and data security are carefully considered, resulting in high memory resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 This is a flowchart of a dynamic loading method for embedded devices according to the present invention.

[0040] Figure 2 The figure is a schematic structural diagram of the dynamic loading system for embedded devices according to the present invention.

[0041] Figure 3 Generate an execution effect diagram of a module for a prior art dynamic library.

[0042] Figure 4 This is an execution effect diagram of the dynamic library generation module in the present invention.

[0043] Figure 5 This is a schematic diagram of the burning locations of the firmware and dynamic library files in the storage medium of the present invention.

[0044] Figure 6 This is a schematic diagram of the entire process of the firmware calling library functions of the present invention.

[0045] Figure 7 The present invention is a method flow chart of a preferred embodiment. DETAILED DESCRIPTION

[0046] The technical solution provided by the present invention will be further described below with reference to the accompanying drawings.

[0047] Dynamically loaded modules are an important technology in software engineering for improving code flexibility, reusability, and maintainability. Dynamic libraries are binary files containing code and resources that can be shared by multiple applications and are widely used in operating systems. This invention uses dynamically loaded modules to enable firmware to directly read and write dynamic library files to embedded system storage media. This allows the firmware to run on a variety of storage media, significantly reducing hardware platform limitations and providing broad applicability.

[0048] See also Figure 1 , which is a flowchart of a dynamic loading method for an embedded device according to the present invention, includes the following steps:

[0049] Step S1: The host burns the firmware and dynamic library files to the storage medium of the embedded device;

[0050] Step S2: running the firmware in the embedded device memory;

[0051] In step S1, the dynamic library generation module generates corresponding dynamic library files according to the functions of the dynamic library source code, integrates the dynamic loading module with the firmware source code and compiles it to generate a firmware file; wherein the firmware file stores information of the corresponding dynamic library file, and the information at least includes the dynamic library name, the starting address of the dynamic library file in the storage medium, and the memory size occupied by the dynamic library file in the storage medium;

[0052] In step S2, when the firmware runs to load a certain library function, the corresponding dynamic library file is found in the storage medium according to the information of the corresponding dynamic library file saved in the firmware file, and the dynamic library file is mapped to the memory and the global dynamic symbol table of the dynamic library is constructed to call the library function.

[0053] As a preferred embodiment, step S2 further includes:

[0054] Map the called dynamic library file to the memory according to its address and occupied size in the storage medium;

[0055] Parse the dynamic library in memory and count the global function symbols;

[0056] Apply for corresponding memory space in memory according to the statistical global function symbols and build a global dynamic symbol table;

[0057] Call the corresponding library function according to the memory address corresponding to each symbol in the global dynamic symbol table;

[0058] After completing the call to the library file, close the dynamic library and directly release the space applied in the memory.

[0059] See also Figure 2 , shown is a structural block diagram of a dynamic loading system for embedded devices in the present invention, including a host and an embedded device. The host is used to generate firmware and dynamic library files and burn them to the storage medium of the embedded device. The storage medium is any one of flash, eMMC or SD card.

[0060] The host includes:

[0061] Dynamic library generation module, used to compile each dynamic library source code into different dynamic library files according to functional blocks;

[0062] A firmware generation module, used to compile the firmware source code into firmware, wherein the firmware is integrated with a dynamic loading module, and the dynamic loading module is used to dynamically load the corresponding dynamic library file;

[0063] Dynamic library burning module, used to burn the generated firmware and dynamic library files to the storage medium of the embedded device;

[0064] The embedded device is used to run firmware in memory and dynamically load dynamic library files, wherein the loading call of the dynamic library is realized through the dynamic loading module in the firmware; the information of the corresponding dynamic library file is saved in the firmware file, and the information at least includes the dynamic library name, the starting address of the dynamic library file in the storage medium, and the memory size occupied by the dynamic library file in the storage medium; when the firmware runs to load a certain library function, the corresponding dynamic library file is found in the storage medium according to the information of the corresponding dynamic library file saved in the firmware file, and the dynamic library file is mapped to the memory and the global dynamic symbol table of the dynamic library is constructed to call the library function.

[0065] In a preferred embodiment, the dynamic loading module adopts the dynamic loading module of the RT-Thread operating system and integrates it into the firmware. RT-Thread is an open source real-time operating system (RTOS) designed for embedded devices. It has the characteristics of lightweight, flexible, efficient and modular, and is widely used in the fields of Internet of Things, industrial control, smart home, etc. Since the minimum resource occupancy of RT-Thread is very low and it has a highly scalable software architecture, the present invention adopts the dynamic loading module of the RT-Thread real-time operating system and makes compatibility modifications according to the firmware. The module includes POSIX standard dynamic loading APIs such as dlopen, dlsym, and dlclose. These APIs provide standard and unified interfaces for loading and using dynamic libraries, occupy little memory resources and have wide portability.

[0066] Specifically, the host includes a dynamic library generation module running on the host, a dynamic loading module integrated with the firmware and ported from the RT-Thread operating system, a firmware and dynamic library file burning module; and embedded devices that run the firmware and implement dynamic library calls, such as demo boards and EVB boards. The embedded devices have storage media for storing firmware and dynamic library files, such as eMMC and flash memory. The dynamic library generation module divides the dynamic library source code into functional blocks and compiles them into different dynamic library files using the riscv-linux-gnu-gcc cross-compilation chain. This allows the dynamic library files of specific functions to be called separately when calling library files, without having to call all dynamic library files, or rather, not all dynamic library files are compiled into a single dynamic library file. This reduces the loading time when calling the library, improves the efficiency of loading the library, and facilitates the management of the library files. The main firmware source code integrates the dynamic loading module content of the RT-Thread operating system. The integration part only involves the relevant interfaces and dependencies for dynamic loading without porting the entire RT-Thread operating system. The porting restrictions are relatively few and the memory space occupied is small. The dynamic loading module contains several interfaces such as dlopen, dlsym, dlclose and related dependencies, which is relatively flexible to use. The dynamic library burning module uses the serial port tool to realize the communication interaction between the embedded device and the host. The firmware and dynamic library files are burned to the storage medium of the embedded device, such as eMMc, through the serial port tool. Under the condition that data is not lost, the library file can be stored at any location on the storage medium without having to be continuous in the memory. After the firmware and dynamic library files are successfully stored in the storage medium of the embedded device, the firmware can be run, and the dynamic library loading call is realized through the dynamic loading module in the firmware.

[0067] In the above technical solution, in step S1, a structure array is defined in the firmware file to store the relevant information of the corresponding dynamic library file, thereby adopting a simple method to achieve the management of the dynamic library file. Specifically, a structure array shared_library_struct[] is defined in the firmware to store the relevant information of the library file, as shown in Table 1 below. The relevant elements of the shared_library_struct structure, among which the dynamic library name and the memory size occupied by the dynamic library file in the storage medium are known when the dynamic library file is generated, and the starting address of the dynamic library file in the storage medium is also known when it is burned to the storage medium.

[0068] Table 1 shared_library_struct structure

[0069]

[0070] In a preferred embodiment, the dynamic library generation module manages the dependencies between the dynamic libraries so that each dynamic library generates a dynamic library file independently. Assume that the dynamic library source code consists of two functional module projects, A and B, where there is a common dependency C in modules A and B. If the dependencies between the dynamic libraries are not managed, multiple copies of the same C part will be stored in the memory, resulting in redundant storage and wasting memory resources. Figure 3 Therefore, considering that the firmware needs to use multiple dynamic libraries, the dependencies between these libraries must be managed. This problem can be handled when compiling and generating dynamic library files and when actually calling. A dynamic library file C can be compiled separately based on the common dependency files of modules A and B. In this way, there is no need to add dependency source code to the source code of modules A and B. Figure 4 When the library file is actually stored in the memory, the memory will only contain one copy of file C. In actual calls, if there are calls to dynamic libraries A and B, dynamic library C must be called first.

[0071] In a preferred embodiment, the firmware and dynamic library files are stored continuously in the storage medium or stored in different locations in the storage medium. Figure 5 , shown is a schematic diagram of the burning location of the firmware and dynamic library files in the storage medium of the present invention. If memory resources permit and data loss is guaranteed when the firmware and dynamic library files are stored in the storage medium, the firmware and dynamic library files can be stored in different locations in the storage medium and do not have to be continuous in the memory.

[0072] In a preferred embodiment, when the firmware runs to load a certain library function, the interface of the dynamic loading module of the RT-Thread operating system is used to load the corresponding dynamic library file;

[0073] After building the global dynamic symbol table, a library handle is returned through the dlopen interface to indicate the address of the symbol table.

[0074] When the firmware runs and calls a library function, it uses the dlsym interface to obtain the dynamic library function address. The dlsym interface contains two input parameters. The first is the library handle of the calling library file, which is the return value of dlopen. The second input parameter is the dynamic function name to be called. According to the function name to be called in dlsym, the required function address is found in the global dynamic symbol table in the memory.

[0075] After completing the call to the library file, use the dlclose interface to close or unload the dynamic link library opened by the dlopen interface before, and release the space allocated for the library file in the memory.

[0076] Usually in the RT-Thread operating system, the struct rt_dlmodule*dlmodule_load(constchar*pgname) function is used to load the dynamic library file, where pgname is the dynamic module path. The function of this interface is to load the dynamic module from the file system into the memory. If the load is correct, the pointer to the module will be returned.

[0077] Since the present invention does not adopt a file system, but directly loads the dynamic library file from the storage medium, modifications are made to this interface. During the firmware running process, if the firmware runs to the dynamic function part in the dynamic library, the dynamic library file will be retrieved by the storage location of the dynamic library file in the storage medium instead of retrieving the dynamic library file by the dynamic module path. The above-mentioned structure for storing dynamic library file related information will be used here. For calling different dynamic library contents, the dynamic library file can be found in the storage medium according to the elements in the structure, that is, the starting address of the library file in the storage medium.

[0078] Since the speed of CPU accessing RAM is much higher than the speed of accessing disk or other storage media, and in order to quickly provide the required function or variable address when the program requests it, the parsing of library files is usually performed in RAM. Therefore, in the present invention, when calling the dynamic library content in the firmware, after indexing the corresponding dynamic library in eMMc or other storage media, it will be copied to RAM for parsing. For the dynamic library file in the storage medium, the malloc function is used to apply for the corresponding memory size in RAM according to the memory space it occupies, and then the library file in other storage media is mapped to RAM. In this way, the code is actually stored in flash or eMMc, and the CPU can also execute it as if it were accessing RAM. See Figure 6 , shown is the entire process diagram of firmware calling library functions.

[0079] See also Figure 7, shown is a method flow chart of a preferred embodiment of the present invention. For library files mapped in RAM, in order to facilitate dynamic calling and reduce calling time, the symbol table of the library file will be traversed, and the symbols with STB_GLOBAL and STB_FUNC attributes will be counted. These symbols are dynamic library functions called in the firmware. Based on the number of these symbols counted, the malloc function is used to apply for memory for these symbols in RAM to build a dynamic symbol table. The dynamic symbol table contains the address information of these symbols, and these symbols can be found through the address information. After the dynamic symbol table is successfully built, a library handle will be returned to the dlopen interface to indicate the address of the symbol table. When the firmware runs the library function call section, the dlsym interface is used. The dlsym interface contains two input parameters. The first is the library handle of the calling library file, which is the return value of dlopen. The second input parameter is the dynamic function name to be called. Based on the function name to be called in dlsym, the CPU can find the required function address in the dynamic symbol table in RAM. When the firmware runs to this point, it will jump to the RAM to execute the function call section. After the call is completed, it will return to the firmware address to continue running the firmware. After completing the call to the library file, use the dlclose interface to close or unload the dynamic link library opened by the previous dlopen interface, freeing up the space allocated by malloc in RAM for the library file. This can avoid potential memory leaks and improve the utilization of memory resources.

[0080] In a preferred embodiment, in step S2, a call history table is stored in the memory to record the call information left after the initial call to the dynamic library; different library functions called in different threads, when entering a thread again, the call history table is used to load the corresponding dynamic library into the memory in advance.

[0081] Specifically, for different library functions called in different threads, in order to improve the calling efficiency, a call history table is stored in RAM. For example, thread A calls dynamic library 1. It will be relatively slow to perform the above operation from flash during the first call. After the first call, the information of the calling library is left. When entering this thread next time, the library file can be loaded into RAM before waiting for the calling part, which can save loading time and release it at the end.

[0082] The above embodiments are only intended to help understand the method and core concept of the present invention. It should be noted that, without departing from the principles of the present invention, a number of improvements and modifications may be made to the present invention by those skilled in the art, and such improvements and modifications also fall within the scope of protection of the claims of the present invention.

[0083] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A dynamic loading method for embedded devices, characterized in that: The steps include: Step S1: The host burns the firmware and dynamic library files to the storage medium of the embedded device; Step S2: running the firmware in the embedded device memory; In step S1, the dynamic library generation module generates corresponding dynamic library files according to the functions of the dynamic library source code, integrates the dynamic loading module with the firmware source code and compiles it to generate a firmware file; wherein the firmware file stores information of the corresponding dynamic library file, and the information at least includes the dynamic library name, the starting address of the dynamic library file in the storage medium, and the memory size occupied by the dynamic library file in the storage medium; In step S2, when the firmware runs to load a certain library function, the corresponding dynamic library file is found in the storage medium according to the information of the corresponding dynamic library file stored in the firmware file, and the dynamic library file is mapped into the memory and the global dynamic symbol table of the dynamic library is constructed to call the library function; Step S2 further includes: Map the called dynamic library file to the memory according to its address and occupied size in the storage medium; Parse the dynamic library in memory and count the global function symbols; Apply for corresponding memory space in memory according to the statistical global function symbols and build a global dynamic symbol table; Call the corresponding library function according to the memory address corresponding to each symbol in the global dynamic symbol table; After completing the call to the library file, close the dynamic library and directly release the space requested in the memory; Step S2 further includes: When the firmware runs to load a certain library function, the corresponding dynamic library file is loaded using the interface of the dynamic loading module; After building the global dynamic symbol table, a library handle is returned through the dlopen interface to indicate the address of the symbol table. When the firmware runs and calls a library function, it uses the dlsym interface to obtain the dynamic library function address. The dlsym interface contains two input parameters. The first is the library handle of the calling library file, which is the return value of dlopen. The second input parameter is the dynamic function name to be called. According to the function name to be called in dlsym, the required function address is found in the global dynamic symbol table in the memory. After completing the call to the library file, use the dlclose interface to close or unload the dynamic link library opened by the dlopen interface before, and release the space allocated for the library file in the memory.

2. The dynamic loading method for embedded devices according to claim 1, characterized in that: In step S1, a structure array is defined in the firmware file to store relevant information of the corresponding dynamic library file.

3. The dynamic loading method for embedded devices according to claim 1, characterized in that: In step S1, the dynamic loading module of the RT-Thread operating system is used and integrated into the firmware.

4. The dynamic loading method for embedded devices according to claim 3, characterized in that: The dynamic library generation module manages the dependencies between the dynamic libraries, so that each dynamic library can generate a dynamic library file independently.

5. The dynamic loading method for embedded devices according to claim 3, characterized in that: The firmware and dynamic library files are stored consecutively in the storage medium or stored in different locations in the storage medium.

6. The dynamic loading method for embedded devices according to claim 3, characterized in that: In step S2, a call history table is stored in the memory to record the call information left after the initial call to the dynamic library; different library functions called in different threads, when entering a thread again, the call history table is used to load the corresponding dynamic library into the memory in advance.

7. The dynamic loading method for embedded devices according to claim 3, characterized in that: In step S1, the storage medium is any one of flash, eMMC or SD card.

8. A dynamic loading system for embedded devices, characterized in that: The host includes a host and an embedded device. The host is used to generate firmware and dynamic library files and burn them to the storage medium of the embedded device. The host includes: Dynamic library generation module, used to compile each dynamic library source code into different dynamic library files according to functional blocks; A firmware generation module, used to compile the firmware source code into firmware, wherein the firmware is integrated with a dynamic loading module, and the dynamic loading module is used to dynamically load the corresponding dynamic library file; Dynamic library burning module, used to burn the generated firmware and dynamic library files to the storage medium of the embedded device; The embedded device is used to run firmware in memory and dynamically load dynamic library files, wherein the loading call of the dynamic library is realized by the dynamic loading module in the firmware; the information of the corresponding dynamic library file is stored in the firmware file, and the information at least includes the dynamic library name, the starting address of the dynamic library file in the storage medium, and the memory size occupied by the dynamic library file in the storage medium; when the firmware runs to load a certain library function, the corresponding dynamic library file is found in the storage medium according to the information of the corresponding dynamic library file stored in the firmware file, and the dynamic library file is mapped to the memory and a global dynamic symbol table of the dynamic library is constructed to call the library function; Also includes: Map the called dynamic library file to the memory according to its address and occupied size in the storage medium; Parse the dynamic library in memory and count the global function symbols; Apply for corresponding memory space in memory according to the statistical global function symbols and build a global dynamic symbol table; Call the corresponding library function according to the memory address corresponding to each symbol in the global dynamic symbol table; After completing the call to the library file, close the dynamic library and directly release the space requested in the memory; Also includes: When the firmware runs to load a certain library function, the corresponding dynamic library file is loaded using the interface of the dynamic loading module; After building the global dynamic symbol table, a library handle is returned through the dlopen interface to indicate the address of the symbol table. When the firmware runs and calls a library function, it uses the dlsym interface to obtain the dynamic library function address. The dlsym interface contains two input parameters. The first is the library handle of the calling library file, which is the return value of dlopen. The second input parameter is the dynamic function name to be called. According to the function name to be called in dlsym, the required function address is found in the global dynamic symbol table in the memory. After completing the call to the library file, use the dlclose interface to close or unload the dynamic link library opened by the dlopen interface before, and release the space allocated for the library file in the memory.

Images