Method and device for realizing solidification and sharing of function library in microcontroller system

Abstract

The invention provides a method and device for realizing solidification and sharing of a function library in a microcontroller system, and the method comprises the steps: dividing a bootstrap program region, a main program region and a solidification library region of which physical addresses are not overlapped in an internal nonvolatile memory of a microcontroller; compiling a target function library into an independent executable mirror image, and burning the executable mirror image in advance and fixing the executable mirror image in the solidified library area; a function jump table is stored at the preset fixed position of the solidified library area, and the function jump table comprises pointers pointing to all the performance functions in the target function library; and the bootstrap program and the main program read the function jump table by accessing the predetermined fixed position so as to call the function of the target function library according to a pointer in the function jump table. According to the method, the single version and the calling consistency of the function library in the system are ensured on the aspect of architecture, the system design is simplified, and the reliability and the maintainability are improved.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically to a method and apparatus for implementing function library fixation and sharing in a microcontroller system. Background Technology

[0002] In embedded applications such as industrial automation and the Internet of Things (IoT), providing devices with standard communication capabilities (such as the Modbus protocol) is a common requirement. To this end, developers typically integrate a lightweight protocol stack, such as the nanomodbus library implemented in C, into the firmware of embedded microcontrollers (such as the STM32 series). To improve system reliability and maintainability, such systems often employ a dual-program partition architecture: a separate bootloader area handles low-level management such as system startup and firmware upgrades; the main application area carries the core business logic.

[0003] In existing technical solutions, to enable communication between the Bootloader and Application, the conventional approach is to integrate and compile complete protocol stack libraries in two separate software projects, and then burn the two sets of library code to their respective memory partitions. However, this method has inherent technical drawbacks: First, it results in the duplicate storage of identical protocol stack code in the chip's limited non-volatile memory (such as Flash), wasting valuable storage resources; second, the Bootloader and Application each maintain an independent set of library code, and when the protocol stack needs to be upgraded or modified, both projects must be updated synchronously, compiled separately, and tested. This not only increases the complexity of development and maintenance but also easily leads to communication compatibility issues due to asynchronous version updates, affecting system stability. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention proposes a method for implementing function library embedding and sharing in a microcontroller system, comprising: Within the microcontroller's internal non-volatile memory, a boot program area, a main program area, and a firmware library area with non-overlapping physical addresses are divided. The target function library is compiled into a standalone executable image, and the executable image is pre-burned and fixed in the solidified library area; At a predetermined fixed location in the solidified library area, a function jump table is stored, the function jump table containing pointers to each function in the target function library; Both the bootloader and the main program access the predetermined fixed location to read the function jump table, and then call the functions of the target function library according to the pointers in the function jump table; Neither the bootloader nor the main program contains the implementation code of the target function library.

[0005] In one embodiment, the function jump table described above further includes a version identifier field and an integrity check code field; Before the bootstrap program and the main program access the predetermined fixed location to read the function jump table and call the function of the target function library according to the pointer in the function jump table, the following steps are also included: Version compatibility comparison is performed based on the version identifier field, and / or integrity verification is performed on the solidified library area based on the integrity check code field.

[0006] In one embodiment, the step of compiling the target function library into a standalone executable image includes: Create a separate project for the target function library in Keil MDK; Configure the linker script of the project to force the code segment of the target function library and the function jump table to be linked to the target address range corresponding to the solidified library area.

[0007] In one embodiment, a Keil configuration method is also included, comprising: In the Linker Miscellaneous Controls settings of the project options, add the "--keep" directive to specify and retain the target file and segment corresponding to the function jump table, preventing it from being removed by the linker optimization; Disable the "Use memory layout from target dialog" option to ensure that the linking process strictly follows the address mapping defined in the linker script and prevents addresses from being overwritten; If the operation of the target function library depends on the service interface provided by the real-time operating system, then a weak symbolic implementation of the service interface is provided in the main application so that the target function library can link and call it at runtime.

[0008] In one embodiment, a method for independently updating the firmware library is also included, comprising: When the target function library needs to be updated, the standalone project of the target function library is recompiled to generate a new executable image, which is then burned to the solidified library area without modifying the project code of the bootloader and the main program.

[0009] In one embodiment, a system verification method is also included, comprising: Use programming tools to burn the executable image of the target function library separately into the solidified library area; The bootloader is burned into the bootloader area; The main program is burned into the main program area; Start the system, run the bootloader, and verify whether its function calls to the target function library through the function jump table are normal; The bootloader is controlled to jump to the main program; Run the main program and verify whether its function calls to the same target function library through the same function jump table are normal, and the consistency of the communication results.

[0010] In one embodiment, the microcontroller is an STM32F429 series microcontroller; The solidification area is located in the region of its internal Flash memory starting at address 0x080E0000; The burning operation is completed through the firmware update function implemented by ST-Link Utility, STM32CubeProgrammer programming tool, or the bootloader.

[0011] This invention also provides a device for implementing function library fixation and sharing in a microcontroller system, applied to a smart ring, comprising: The partitioning module is used to divide the microcontroller's internal non-volatile memory into a boot program area, a main program area, and a firmware library area with non-overlapping physical addresses. The burning module is used to compile the target function library into an independent executable image, and to pre-burn and fix the executable image in the solidified library area; A storage module is used to store a function jump table at a predetermined fixed location in the solidified library area, the function jump table containing pointers to each function in the target function library; The calling module is used by both the bootloader and the main program to access the predetermined fixed location, read the function jump table, and call the functions of the target function library according to the pointers in the function jump table; Neither the bootloader nor the main program contains the implementation code of the target function library.

[0012] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described above for implementing function library fixation and sharing in a microcontroller system.

[0013] The present invention also provides a computer storage medium storing a computer program thereon, which, when executed by a processor, implements the method described above for implementing function library fixation and sharing in a microcontroller system.

[0014] This invention pre-programs the target function library as an independent entity into a dedicated firmware area within the microcontroller and establishes a unified calling interface based on a fixed-address function jump table. This allows the bootloader and main program to access all their functions by accessing the same physical resource, without needing their own integrated library implementation code. This solution directly overcomes the problem of duplicate storage space usage for the same function code in existing technologies, effectively saving chip storage resources. Simultaneously, it eliminates the version inconsistency risk and doubled maintenance workload caused by two separate programs maintaining the protocol stack. Architecturally, it ensures the single versioning and calling consistency of the function library within the system, simplifying system design and improving reliability and maintainability. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a method for implementing function library embedding and sharing in a microcontroller system according to the first embodiment of the present invention; Figure 2 This is a memory partition layout diagram of the first embodiment of the present invention; Figure 3 This is a detailed flowchart of S121 of the first embodiment of the present invention; Figure 4 A detailed flowchart of the Keil project configuration for the first embodiment of the present invention; Figure 5 This is one of the detailed flowcharts of the system verification process according to the first embodiment of the present invention; Figure 6 This is a structural block diagram of a device for implementing function library fixation and sharing in a microcontroller system according to the second embodiment of the present invention; Figure 7 This is a schematic diagram of the internal structure of a computer according to another embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Well-known modules, units, and their connections, links, communications, or operations are not shown or described in detail. Furthermore, the described features, architectures, or functions can be combined in any way in one or more embodiments. Those skilled in the art should understand that the various embodiments described below are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. It is also readily understood that the modules, units, or processing methods in the various embodiments described herein and shown in the accompanying drawings can be combined and designed in various different configurations. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Please refer to Figures 1 to 5 As shown, the first embodiment of the present invention discloses a method for implementing function library embedding and sharing in a microcontroller system, particularly suitable for embedded systems using STM32F429 as the hardware platform that require the Bootloader and Application to share the Modbus protocol stack. The method includes steps S11 to S14, wherein: S11 divides the microcontroller's internal non-volatile memory into a boot program area, a main program area, and a firmware library area, where physical addresses do not overlap.

[0019] The purpose of this step is to provide a physical storage foundation for subsequent code solidification and sharing, ensuring that different functional modules do not interfere with each other in terms of storage space.

[0020] In this embodiment, the microcontroller can be an STM32F429 chip, which integrates 2MB of Flash memory. Figure 2 The memory partition layout diagram shown is divided as follows: Bootloader area: Starting at address 0x08000000, size 128KB. This area stores the system bootloader, responsible for hardware initialization, firmware update verification, and jump to the main program.

[0021] Main program area (Application area): Starting address is 0x08020000, size is 768KB. This area is used to store the application programs that implement the main business logic of the device.

[0022] Solidified Library Area (LIB Area): Starting at address 0x080E0000, size 128KB. This area is specifically used for permanently storing target function libraries that will be shared.

[0023] The above-mentioned address and size planning needs to be strictly set in the subsequent integrated development environment (such as Keil MDK) project configuration to ensure that the code generated by compilation and linking can be accurately located in the specified area.

[0024] Preferably, this embodiment limits the microcontroller to the STM32F429 series, and specifically sets the firmware library in the Flash region starting at 0x080E0000. This specific planning provides a clear and operable example for implementing the present invention on a specific popular hardware platform. The programming operation can be completed using dedicated programming tools such as ST-Link Utility and STM32CubeProgrammer, or it can be completed through the firmware update (IAP, In-Application Programming) function implemented by the already programmed bootloader, providing a flexible implementation path.

[0025] S12, compile the target function library into an independent executable image, and pre-burn the executable image and fix it in the solidified library area.

[0026] The purpose of this step is to generate a separate, fixed-location shared library code entity. In this embodiment, the target function library is the nanomodbus library, a lightweight Modbus protocol stack implemented in C.

[0027] This step specifically includes two sub-steps, S121 and S122: S121 compiles the target function library into a standalone executable image.

[0028] This process can be completed within the Keil MDK (Microcontroller Development Kit) development environment. First, create a separate project for the nanomodbus library (you can name it NanoModbus_Lib). Add all the source files of the library (such as nanomodbus.c, nanomodbus.h, crc16.c, etc.) to this project, ensuring that it does not contain a main function, to generate a pure library file. Compiling this project will output a standalone executable image file (such as nanomodbus.bin or nanomodbus.hex).

[0029] For details, please refer to Figure 3 As shown, this step S121 specifically includes S1211 and S1212, wherein: S1211, Create a separate project for the target function library in Keil MDK.

[0030] S1212, Configure the linker script of the project to forcibly link the code segment of the target function library and the function jump table to the target address range corresponding to the solidified library area.

[0031] Steps S1211 and S1212 can be achieved by modifying the linker file (Scatter File) of the Keil project using the following instructions: LR_IROM1 0x080E0000 0x00010000 { ER_IROM1 0x080E0000 0x00010000 { *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } The compiler is forced to set the starting address of all code and data outputs to 0x080E0000, thereby ensuring that the generated image is physically bound to the solidified library area planned by S11.

[0032] Please refer to Figure 4 As shown, as a preferred solution, to ensure the linking process is correct, the Keil project configuration in this embodiment also includes the following configuration method: S21. In the project options, under Linker Miscellaneous Controls (Options for Target -> Linker -> MiscControls), add the directive "--keep=nm_api.o(.nm_api)". This directive specifies and preserves the target file and segment corresponding to the function jump table, preventing the linker from mistakenly removing them during optimization and ensuring the continued existence of shared interfaces.

[0033] S22, disable the "Use Memory Layout from TargetDialog" option. This operation ensures that the linking process strictly follows the custom linking script in S1212, preventing the IDE's default memory configuration from overriding the custom addresses.

[0034] S23, if the operation of the target function library depends on service interfaces provided by a real-time operating system (such as FreeRTOS) (e.g., task delay vTaskDelay, semaphore operations, etc.), then a weak symbol implementation of the service interface is provided in the main application. Weak symbols allow them to be overridden by strong symbols in the application during linking. By implementing these interfaces in the main program and pointing them to the actual RTOS API, the fixed nanomodbus library can correctly call system services at runtime, achieving decoupling between the library and the specific runtime environment, and enhancing the library's versatility and portability.

[0035] S122, The executable image is pre-burned and fixed in the solidified library area.

[0036] This step uses tools such as ST-Link Utility mentioned in S11 to burn the nanomodbus.bin file generated in S121 to address 0x080E0000 of the STM32F429 chip's Flash memory. After burning, the contents of this area are considered read-only and cannot be modified during normal system operation.

[0037] When future upgrades to the nanomodbus library are needed (such as fixing vulnerabilities or adding functionality), this invention provides a convenient update path: Simply modify the source code in the NanoModbus_Lib independent project, re-execute S121 to compile and generate a new image, and then execute S122 again to flash it to the firmware library. The entire process does not require modification and recompilation of the bootloader and main application project code, greatly reducing maintenance complexity and avoiding compatibility risks caused by inconsistent library versions in multiple projects.

[0038] S13, at a predetermined fixed position in the solidified library area, a function jump table is stored, the function jump table containing pointers to each function in the target function library.

[0039] As a specific solution rather than a limitation, this step defines the interface contract between the Bootloader and the Application for accessing the firmware library. In this embodiment, the predetermined fixed location is preferably the starting address of the firmware library area (i.e., 0x080E0000). The function jump table is a data structure generated at compile time and stored within the firmware library area.

[0040] In this embodiment, the function jump table can be defined as a structure of type nm_api_t, as shown in the following example: c typedef struct { int (*nm_init)(void*); / / Initialize function pointer int (*nm_read)(uint8_t*, uint16_t); / / Pointer to the function for reading data int (*nm_write)(uint8_t*, uint16_t); / / Pointer to the write data function uint32_t version; / / Version identifier field, for example, 0x0100 represents v1.0 uint32_t crc; / / Integrity checksum field, used for the CRC32 checksum value of the repository. } nm_api_t; Through the linker script configuration in step S1212 above, a constant of type nm_api_t (e.g., const nm_api_t nm_api) that has been initialized with specific function addresses and version information is placed at the starting address of the solidified library area. Thus, any program can access this directory containing all available function entries simply by accessing address 0x080E0000.

[0041] As a preferred option, the function jump table stored in step S13 also includes a version identifier field and an integrity check code field, which are used to add a security and compatibility guarantee mechanism to the system.

[0042] Based on this, as a preferred approach, the subsequent S14 step (function invocation) also includes a security verification sub-step: Version compatibility is compared based on the version identifier field. Specifically, before calling library functions, the bootloader or main program can read the nm_api.version field and compare it with the lowest supported or expected version. If the versions are incompatible, the call is aborted and an error is reported to prevent system anomalies caused by interface changes.

[0043] Integrity verification is performed on the solidified library area based on the integrity check code field. Specifically, during system startup (e.g., in the bootloader), a CRC32 checksum is calculated for the solidified library data starting at 0x080E0000 and compared with the value stored in the nm_api.crc field. If they do not match, it indicates that the library data may have been corrupted during storage or transmission, and the system can enter safe mode to avoid executing erroneous code.

[0044] The aforementioned security verification steps effectively improve the robustness and reliability of the system by embedding management information in the shared interface.

[0045] S14, both the bootloader and the main program access the predetermined fixed location to read the function jump table, and call the function of the target function library according to the pointer in the function jump table.

[0046] In this step, the importer (located at 0x08000000) and the main program (located at 0x08020000) no longer contain the source code (.c file) of the nanomodbus library or depend on its implementation within their respective projects. Instead, they access the same fixed address (0x080E0000) to obtain the same function jump table (nm_api), and thus call the same nanomodbus library code.

[0047] In the main application, calls are made using the exact same macro or header file definitions. This ensures that access to the Modbus protocol stack is consistent and based on the same binary code, whether during system startup or main runtime.

[0048] Please refer to Figure 5 As shown, to verify the correctness of the solution in this embodiment, the following system verification process can be executed: S31, Use a programming tool to burn the executable image of the target function library separately to the solidified library area (i.e., 0x080E0000).

[0049] S32, the boot program is burned into the boot program area (i.e., 0x08000000).

[0050] S33, burn the main program to the main program area (i.e., 0x08020000).

[0051] S34. Start the system, run the bootloader, and verify whether its function calls to the target function library through the function jump table are normal.

[0052] For example, observe whether the bootloader can successfully read device information via the Modbus protocol.

[0053] S35, control the bootloader to jump to the main program.

[0054] After completing tasks such as verification, the bootloader executes a specific jump instruction, which points the program counter (PC) to the starting address of the main program.

[0055] S36, run the main program and verify whether its function calls to the same target function library through the same function jump table are normal, and the consistency of the communication results.

[0056] For example, the main program performs the same Modbus read operation, confirms that the result is consistent with step S34, and the debugger confirms that the function addresses called by both are exactly the same.

[0057] This verification process systematically proves that the Bootloader and Application successfully share the firmware library, and that the entire system is fully functional and behaves consistently.

[0058] It should be noted that, throughout the entire process of this embodiment, neither the bootloader nor the main program contains the implementation code of the target function library.

[0059] This embodiment transforms the nanomodbus protocol stack, which originally needed to be repeatedly integrated in the bootloader and application, into a single public resource stored in a fixed physical location within the system through a "divided and solidified library area - independent compilation and solidification" technique. This directly realizes a system architecture that divides the MCU's internal Flash into shareable communication libraries, allowing two applications to call functions without needing to carry their own copies of the library code, simply through a unified address mapping interface.

[0060] Meanwhile, this embodiment provides a standardized, loosely coupled access contract for the Bootloader and Application by pre-setting a jump table containing all function pointers at the starting address of the solidified library area. This realizes a shared structure for the embedded protocol library based on the function jump table. This mechanism ensures that the two applications access the exact same binary code and the same set of interfaces, completely eliminating compatibility issues such as protocol version inconsistencies and interface differences that may occur due to independent maintenance at the architectural level, greatly enhancing system stability and reliability. In addition, in this embodiment, the library code is solidified and stored in the form of an independent image, allowing library upgrades to be performed completely independently of the main program and bootloader. This lays the foundation for the update and security verification mechanism after the nanomodbus library is solidified. When it is necessary to fix vulnerabilities or enhance functions, only the independent library project needs to be modified, compiled, and re-flashed; the Bootloader and Application do not require any changes, greatly simplifying the maintenance process and reducing upgrade risks and maintenance costs. At the same time, the solidified library code also provides convenient conditions for implementing runtime integrity verification (such as CRC check) and version management.

[0061] Second embodiment: Please refer to Figure 6 As shown, the present invention also provides an apparatus 100 for implementing function library embedding and sharing in a microcontroller system, comprising: The partitioning module 110 is used to divide the internal non-volatile memory of the microcontroller into a boot program area, a main program area, and a firmware library area with non-overlapping physical addresses. The programming module 120 is used to compile the target function library into an independent executable image, and to pre-program and fix the executable image in the solidified library area; The storage module 130 is used to store a function jump table at a predetermined fixed position in the solidified library area, the function jump table containing pointers to each function in the target function library; The module 140 is used so that both the bootloader and the main program can access the predetermined fixed location to read the function jump table, and call the function of the target function library according to the pointer in the function jump table; Neither the bootloader nor the main program contains the implementation code of the target function library.

[0062] The modules in this embodiment are the same as the corresponding steps in the first embodiment described above, and will not be repeated here.

[0063] This invention pre-programs the target function library as an independent entity into a dedicated firmware area within the microcontroller and establishes a unified calling interface based on a fixed-address function jump table. This allows the bootloader and main program to access all their functions by accessing the same physical resource, without needing their own integrated library implementation code. This solution directly overcomes the problem of duplicate storage space usage for the same function code in existing technologies, effectively saving chip storage resources. Simultaneously, it eliminates the version inconsistency risk and doubled maintenance workload caused by two separate programs maintaining the protocol stack. Architecturally, it ensures the single versioning and calling consistency of the function library within the system, simplifying system design and improving reliability and maintainability.

[0064] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0065] This invention also provides a computer storage medium storing a computer program that, when executed by a processor, implements the method for embedding and sharing function libraries in a microcontroller system as described in the above embodiments.

[0066] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above for implementing the function library fixation and sharing in a microcontroller system. Any references to memory, storage, database, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0067] Alternatively, if the integrated units of the present invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of the present invention, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, terminal, or network device, etc.) to execute all or part of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, RAM, ROM, magnetic disks, or optical disks.

[0068] Corresponding to the computer storage medium described above, one embodiment also provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method of embedding and sharing function libraries in the microcontroller system as described in the above embodiments.

[0069] The computer device can be a terminal, and its internal structure diagram can be as follows: Figure 7As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for embedding and sharing function libraries in a microcontroller system. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0070] This invention pre-programs the target function library as an independent entity into a dedicated firmware area within the microcontroller and establishes a unified calling interface based on a fixed-address function jump table. This allows the bootloader and main program to access all their functions by accessing the same physical resource, without needing their own integrated library implementation code. This solution directly overcomes the problem of duplicate storage space usage for the same function code in existing technologies, effectively saving chip storage resources. Simultaneously, it eliminates the version inconsistency risk and doubled maintenance workload caused by two separate programs maintaining the protocol stack. Architecturally, it ensures the single versioning and calling consistency of the function library within the system, simplifying system design and improving reliability and maintainability.

[0071] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0072] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. A method of implementing function library consolidation and sharing in a microcontroller system, characterized by, The application relates to a system and method for updating a target function library in a microcontroller. The application includes: In the internal non-volatile memory of the microcontroller, a boot program area, a main program area and a fixed library area are divided, and the physical addresses of the three areas do not overlap; The target function library is compiled into an independent executable image, and the executable image is pre-burned and fixed in the fixed library area; A function jump table is stored at a predetermined fixed position in the fixed library area, and the function jump table contains pointers to each function in the target function library; The boot program and the main program both read the function jump table by accessing the predetermined fixed position, and call the functions of the target function library according to the pointers in the function jump table; 2. The method of claim 1, wherein, The codes of the boot program and the main program do not contain the implementation codes of the target function library. The function jump table further includes a version identification field and an integrity check code field; Before the boot program and the main program read the function jump table by accessing the predetermined fixed position, and call the functions of the target function library according to the pointers in the function jump table, the application further includes:

3. The method of claim 2, wherein, Version compatibility comparison based on the version identification field, and / or integrity check of the fixed library area based on the integrity check code field. The step of compiling the target function library into an independent executable image includes: Creating an independent project for the target function library in Keil MDK; 4. The method of claim 3, wherein, Configuring the link script of the project to force link the code segment of the target function library and the function jump table to the target address range corresponding to the fixed library area. The application further includes a Keil configuration method, which includes: In the linker miscellaneous control settings of the project options, add the "--keep" instruction to specify and retain the target file and segment corresponding to the function jump table, and prevent them from being removed by the linker optimizer; Disable the "use memory layout from target dialog" option to ensure that the address mapping defined in the link script is strictly followed in the linking process, and prevent the address from being overwritten; 5. The method according to any one of claims 1 to 4, characterized in that, If the running of the target function library depends on the service interface provided by the real-time operating system, a weak symbol implementation of the service interface is provided in the main application program, so that the target function library can be linked and called at runtime. The application further includes a fixed library independent updating method, which includes:

6. The method according to any one of claims 1 to 4, wherein When the target function library needs to be updated, the independent project of the target function library is recompiled to generate a new executable image, and the executable image is burned into the fixed library area without modifying the project code of the boot program and the main program. The application further includes a system verification method, which includes: Using a programming tool to separately burn the executable image of the target function library into the fixed library area; Burning the boot program into the boot program area; Burning the main program into the main program area; Starting the system, running the boot program, and verifying whether the function call of the target function library through the function jump table is normal; Controlling the boot program to jump to the main program; Running the main program, verifying whether the function call of the target function library through the same function jump table is normal, and verifying the consistency of the communication results.

7. The method according to any one of claims 1 to 4, wherein The microcontroller is an STM32F429 series microcontroller; The solidification library area is arranged in a region with a starting address of 0x080E0000 in the internal flash memory of the microcontroller; The burning operation is completed by the firmware updating function realized by the ST-Link Utility, the STM32CubeProgrammer programming tool or the boot program.

8. An apparatus for implementing function library consolidation and sharing in a microcontroller system, comprising: Comprise: A partition module, configured to divide a boot program area, a main program area and a solidification library area with non-overlapping physical addresses in the internal non-volatile memory of the microcontroller; A burning module, configured to compile a target function library into an independent executable image, and to pre-burn and fix the executable image in the solidification library area; A storage module, configured to store a function jump table at a predetermined fixed position of the solidification library area, the function jump table containing pointers to each function in the target function library; A calling module, configured to read the function jump table by accessing the predetermined fixed position by the boot program and the main program, and to call the functions of the target function library according to the pointers in the function jump table; Wherein, the code of the boot program and the main program does not contain the implementation code of the target function library.

9. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to realize the method for realizing function library solidification and sharing in the microcontroller system according to any one of claims 1 to 7.

10. A computer storage medium having stored thereon a computer program, characterized in that The program is executed by the processor to realize the method for realizing function library solidification and sharing in the microcontroller system according to any one of claims 1 to 7.

Images