Method for solving bare computer layering

Abstract

The invention relates to the technical field of computers, in particular to a method for solving bare computer layering. Comprising the following steps: dividing the embedded bare computer system into a driving layer (OS) and an application layer (APP); establishing a function address mapping table in the driving layer; when the driving layer is compiled, the entry address of the interface function is written into a function address mapping table according to a preset sequence, and the entry address points to the head address of the mapping table through a constant variable apifunc; creating an intermediate library (API library); a middle library is introduced into an application layer project, an interface function of a driving layer is called through the middle library, and separated compiling and independent upgrading of the application layer and the driving layer are achieved. The invention provides a method for solving bare computer layering, which can realize physical separation, independent upgrading and interface safe calling of a driving layer and an application layer in a bare computer environment independent of an operating system.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a method for solving bare-metal layering. Background Art

[0002] In the field of embedded system development, bare-metal development (i.e., embedded development without an operating system) is widely used in industrial control, smart terminals, Internet of Things devices, etc. due to its low resource consumption and strong real-time performance. Under the traditional bare-metal development mode, hardware driver code (such as peripheral initialization, interrupt handling, etc.) and customer-customized application code are usually compiled into a single firmware and directly burned into the storage medium of the target device.

[0003] However, with the complexity of embedded device functions and the diversification of customer needs, this integrated firmware architecture gradually exposes the following technical defects: (1) Due to the high coupling between the driver code and the application code, the firmware size is large, resulting in the need to transfer the complete firmware file during remote upgrade. Especially in scenarios with limited network bandwidth, the upgrade time is significantly extended, affecting the user experience and device maintenance efficiency. (2) The driver layer code usually involves hardware low-level operations, and the source code needs to be protected to prevent being tampered with or reverse-engineered. However, in the traditional mode, application developers need to directly access the driver layer source code to call the interface, resulting in the confidentiality of the driver code being difficult to guarantee. (3) The driver development team and the application development team need to share the same code library, and any modification by either party may cause code conflicts or compatibility issues.

[0004] To address the above problems, in the prior art, attempts have been made to achieve code separation through modular design or static library linking, but these solutions still have the following limitations: (1) Although functional modules can be divided, the modules still depend on the same compilation environment and cannot achieve physical isolation and independent upgrade; (2) The driver code is provided in the form of a binary library, but the address allocation of library functions is dynamically determined by the compilation tool, resulting in the application layer being unable to stably call the driver interface, and the entire project still needs to be recompiled during upgrade. Summary of the Invention

[0005] The present invention provides a method for solving bare-metal layering, which can achieve physical separation, independent upgrade, and secure interface call between the driver layer and the application layer in a bare-metal environment without relying on an operating system.

[0006] The technical solution adopted by the present invention is: a method for solving bare-metal layering, including the following steps:

[0007] S1: Divide the embedded bare-metal system into a driver layer (OS) and an application layer (APP), where the driver layer includes hardware driver code and basic function interfaces, and the application layer includes customer-customized application code;

[0008] S2: Establish a function address mapping table in the driver layer. The function address mapping table is stored in a continuous mapping area of the chip ROM and contains the entry addresses of the interface functions opened by the driver layer to the application layer.

[0009] S3: When compiling the driver layer, write the entry addresses of the interface functions into the function address mapping table in a preset order, and use the constant variable api_func to point to the start address of the mapping table.

[0010] S4: Create an intermediate library (API library). The intermediate library converts the entry addresses of the interface functions into function interfaces that can be directly called by the application layer by parsing the function address mapping table.

[0011] S5: Introduce the intermediate library into the application layer project, and call the interface functions of the driver layer through the intermediate library to achieve separate compilation and independent upgrade of the application layer and the driver layer.

[0012] As a further improvement of the present invention, the function address mapping table is constructed in the following way: Define a constant variable api_func in the driver layer code, whose address points to a pre-allocated continuous mapping area in the chip ROM; Store the interface functions that need to be opened by the driver layer into the mapping area in sequence to form an address sequence, and ensure the fixity of the address sequence through a compilation tool.

[0013] As a further improvement of the present invention, in step S4, the construction of the intermediate library includes: Define a constant variable api_func in the intermediate library project that is the same as that in the driver layer, and its address points to the start address of the function address mapping table; Convert the entry addresses in the address sequence into function pointers recognizable by the application layer through forced type conversion, and encapsulate them as standard interfaces for the application layer to call.

[0014] As a further improvement of the present invention, the driver layer also includes encapsulation of memory management functions, specifically: Re-encapsulate the malloc and free functions of the standard library so that the application layer and the driver layer share the same heap memory space to save chip RAM resources.

[0015] As a further improvement of the present invention, the running processes of the driver layer and the application layer include: When the device starts, the bootloader loads the driver layer. After completing hardware initialization and stack configuration, it calls the main function of the application layer; After the application layer starts, it calls the interface functions of the driver layer through the intermediate library to achieve separation of hardware operations and business logic.

[0016] As a further improvement of the present invention, the ROM and RAM address spaces of the driver layer and the application layer are independently allocated during compilation, and the address ranges do not overlap with each other.

[0017] As a further improvement of the present invention, the function address mapping table is updated in a static and solidified manner, and will not be modified after the verification of the driver layer code is completed. Only function iteration is achieved through application layer upgrade.

[0018] As a further improvement of the present invention, the method is applicable to the development scenario of an embedded bare-metal system without an operating system, and realizes the improvement of driver code protection and remote upgrade efficiency through a layered architecture.

[0019] Through the physical separation of the driver layer and the application layer, the static solidification of the function address mapping table, and the dynamic interface conversion of the intermediate library, the present invention effectively solves the problems of low firmware upgrade efficiency, easy leakage of driver code, and difficult development collaboration in traditional bare-metal development, and achieves the following comprehensive technical effects: In a bare-metal environment without an operating system, through a layered architecture and an interface mapping mechanism, the remote upgrade time is significantly shortened (only the application layer needs to be updated), the security of the driver code is strictly protected (the source code does not need to be open to the application layer), and at the same time, independent development and maintenance of the driver layer and the application layer are supported, greatly improving the flexibility, security, and maintainability of the embedded system. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a schematic diagram of the overall structure of a method for solving bare-metal layering of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0021] In order to make the technical problems, technical solutions, and beneficial effects to be solved by the present application clearer, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0022] The present invention provides a method for solving bare-metal layering, including the following steps:

[0023] S1: Divide the embedded bare-metal system into a driver layer (OS) and an application layer (APP), where the driver layer includes hardware driver code and basic function interfaces, and the application layer includes customer-customized application code;

[0024] S2: Establish a function address mapping table in the driver layer. The function address mapping table is stored in a continuous mapping area of the chip ROM and includes the entry addresses of the interface functions opened by the driver layer to the application layer;

[0025] S3: When compiling the driver layer, write the entry addresses of the interface functions into the function address mapping table in a preset order, and point to the head address of the mapping table through the constant variable api_func;

[0026] S4: Create an intermediate library (API library). The intermediate library converts the entry addresses of the interface functions into function interfaces that can be directly called by the application layer by parsing the function address mapping table;

[0027] S5: Introduce the intermediate library into the application layer project, and call the interface function of the driver layer through the intermediate library to achieve separate compilation and independent upgrade of the application layer and the driver layer.

[0028] The function address mapping table in the present invention is constructed in the following way: a constant variable api_func is defined in the driver layer code, and its address points to a pre-allocated continuous mapping area in the chip ROM; the interface functions to be opened by the driver layer are stored in the mapping area in sequence to form an address sequence, and the fixity of the address sequence is ensured by a compilation tool.

[0029] In step S4 of the present invention, the construction of the intermediate library includes: defining a constant variable api_func that is the same as the driver layer in the intermediate library project, and its address points to the first address of the function address mapping table; converting the entry address in the address sequence into a function pointer recognizable by the application layer through forced type conversion, and encapsulating it into a standard interface for the application layer to call.

[0030] The driver layer in the present invention also includes encapsulation of memory management functions, specifically: re-encapsulating the malloc and free functions of the standard library so that the application layer and the driver layer share the same memory space to save chip RAM resources.

[0031] The operation process of the driver layer and the application layer in the present invention includes: when the device is started, the driver layer is loaded by the boot program, and after the hardware initialization and stack configuration are completed, the main function of the application layer is called; after the application layer is started, the interface function of the driver layer is called through the intermediate library to realize the separation of hardware operation and business logic.

[0032] In the present invention, the ROM and RAM address spaces of the driver layer and the application layer are independently allocated during compilation, and the address ranges do not overlap.

[0033] The updating mode of the function address mapping table in the present invention is static solidification, and it will not be modified after the driver layer code verification is completed, and the function iteration is realized only by upgrading the application layer.

[0034] The method of the present invention is applicable to embedded bare-metal development scenarios without an operating system, and achieves driver code protection and remote upgrade efficiency improvement through a layered architecture.

[0035] Embodiment 1 (layered architecture implementation of driver layer and application layer):

[0036] (I) System Layering and Address Allocation

[0037] Hardware environment: Based on an embedded chip without an operating system (such as the ARM Cortex-M series), its storage space is divided into ROM (for storing firmware) and RAM (for running data).

[0038] Driver layer (OS) configuration: (1) Limit the ROM address range of the driver layer firmware to the first half of the chip storage space (e.g., 0x08000000 - 0x0801FFFF), including hardware initialization, peripheral driver code, and basic function interfaces. (2) Configure the RAM address range to the first half of the chip memory (e.g., 0x20000000 - 0x2000FFFF) for stack and data storage during the operation of the driver layer.

[0039] Application layer (APP) configuration: (1) Limit the ROM address range of the application layer firmware to the second half of the chip storage space (e.g., 0x08020000 - 0x0803FFFF), without overlap with the driver layer address. (2) Configure the RAM address range to the second half of the chip memory (e.g., 0x20010000 - 0x2001FFFF) to ensure the independent operation of the application layer.

[0040] (2) Construction of the function address mapping table

[0041] Pre - allocate a continuous ROM area (e.g., starting address 0x0801F000) in the driver layer as the storage space for the function address mapping table.

[0042] Write the interface functions (such as serial communication, GPIO control, etc.) that the driver layer needs to expose to the application layer into the mapping table in a preset order to form a fixed address sequence.

[0043] Fix the position of the mapping table through the compilation tool to ensure that its address cannot be changed after compilation.

[0044] (3) Encapsulation and call of the intermediate library (API library)

[0045] Create an independent intermediate library project, parse the function address mapping table of the driver layer, and convert the address sequence into standard interfaces (such as function pointers) that can be directly called by the application layer.

[0046] After the application layer project introduces the intermediate library, it indirectly accesses the driver layer functions by calling the interfaces in the library without depending on the driver layer source code.

[0047] (4) System startup and operation process

[0048] After the device is powered on, the bootloader first loads the driver layer firmware to complete hardware initialization and stack configuration. After the driver layer starts, it jumps to the entry address of the application layer firmware (such as 0x08020000) to start the application layer main program. The application layer calls the driver layer interfaces through the intermediate library to separate hardware operations from business logic.

[0049] Example 2 (Independent upgrade of the driver layer and the application layer):

[0050] (I) Driver layer firmware solidification

[0051] After the driver layer code is verified, its ROM address range and function address mapping table are statically solidified, and subsequent upgrades only require replacing the application layer firmware.

[0052] (II) Remote upgrade process

[0053] The device receives the application layer upgrade package through the wireless communication module (such as Wi-Fi, Bluetooth), and writes it to the application layer ROM address range after checking the integrity. After restarting the device, the new version of the application layer runs automatically, and the driver layer code remains unchanged, which significantly shortens the upgrade time and reduces the amount of transmitted data.

[0054] Embodiment 3 (Driver Code Protection and Collaborative Development Mode):

[0055] (I) Driver code protection mechanism

[0056] The driver layer code is provided to the application development team in a compiled binary form (such as a static library). Only the intermediate library header file (which describes the interface function) is open, hiding the underlying implementation details. Application developers can only call driver functions through the intermediate library and cannot directly access or modify the driver layer source code to ensure code security.

[0057] 2. Team Collaborative Development

[0058] The driver development team and the application development team maintain independent projects and synchronize code through version management tools (such as Git) to avoid source code conflicts. When the driver layer function is iterated, only the intermediate library header file and mapping table need to be updated, and the application layer can adapt to the new interface without recompiling.

[0059] Technical effect verification

[0060] Through the implementation of the above-mentioned embodiments 1 to 3, the technical effects of the present invention in the following aspects can be verified:

[0061] (1) Improved upgrade efficiency: The application layer firmware volume is reduced to 30%-50% of the original overall firmware, and the remote upgrade time is shortened by more than 60%.

[0062] (2) Enhanced code security: The driver layer source code does not need to be open to the application team, effectively preventing reverse engineering and tampering.

[0063] (3) Optimized development flexibility: The driver layer and application layer can be developed in parallel, shortening the function iteration cycle by 40%.

[0064] In summary, the method for solving bare metal layering of the present invention provides an efficient and secure solution for embedded bare metal development without an operating system through an innovative layered architecture and interface mapping mechanism. In practical applications, this method not only significantly improves the efficiency of firmware upgrades, but also strengthens the protection of driver code, while optimizing the process of team collaborative development. The realization of these technical effects is due to the comprehensive application of core technologies such as the physical separation of the driver layer and the application layer, the static solidification of the function address mapping table, and the dynamic interface conversion of the intermediate library. In the future, with the continuous development of embedded technology, the method proposed by the present invention is expected to be widely used in more fields, bringing revolutionary changes to the development and maintenance of embedded systems.

[0065] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for solving bare-metal layering, characterized in that, The following steps are involved: S1: Divide the embedded bare metal system into a driver layer (OS) and an application layer (APP), wherein the driver layer includes hardware driver code and basic function interfaces, and the application layer includes customer customized application code; S2: Establishing a function address mapping table in the driver layer, wherein the function address mapping table is stored in a continuous mapping area of the chip ROM and contains entry addresses of interface functions opened by the driver layer to the application layer; S3: when compiling the driver layer, the entry address of the interface function is written into the function address mapping table in a preset order, and the first address of the mapping table is pointed to by the constant variable api_func; S4: creating an intermediate library (API library), which converts the entry address of the interface function into a function interface that can be directly called by the application layer by parsing the function address mapping table; S5: Introduce the intermediate library into the application layer project, and call the interface function of the driver layer through the intermediate library to achieve separate compilation and independent upgrade of the application layer and the driver layer.

2. The method for solving bare machine layering according to claim 1, wherein The function address mapping table is constructed in the following way: a constant variable api_func is defined in the driver layer code, and its address points to a pre-allocated continuous mapping area in the chip ROM; the interface functions to be opened by the driver layer are stored in the mapping area in sequence to form an address sequence, and the fixity of the address sequence is ensured by a compilation tool.

3. A method for solving bare machine layering according to claim 1, characterized in that, In step S4, the construction of the intermediate library includes: defining a constant variable api_func that is the same as that of the driver layer in the intermediate library project, and its address points to the first address of the function address mapping table; converting the entry address in the address sequence into a function pointer recognizable by the application layer through forced type conversion, and encapsulating it as a standard interface for the application layer to call.

4. A method for solving bare machine layering according to claim 1, characterized in that, The driver layer also includes encapsulation of memory management functions, specifically: re-encapsulating the malloc and free functions of the standard library so that the application layer and the driver layer share the same memory space to save chip RAM resources.

5. A method for solving bare machine layering according to claim 1, characterized in that The operation process of the driver layer and the application layer includes: when the device starts, the boot program loads the driver layer, completes hardware initialization and stack configuration, and then calls the main function of the application layer; after the application layer starts, the interface function of the driver layer is called through the intermediate library to achieve the separation of hardware operation and business logic.

6. A method for solving bare - machine layering according to claim 1, characterized in that, The ROM and RAM address spaces of the driver layer and the application layer are independently allocated during compilation, and the address ranges do not overlap.

7. A method for solving bare machine layering according to claim 1, characterized in that, The updating mode of the function address mapping table is static solidification, and it will not be modified after the driver layer code verification is completed, and the function iteration is realized only through the application layer upgrade.

8. A method for solving bare-metal layering according to any one of claims 1-7, characterized in that The method is applicable to embedded bare-metal development scenarios without an operating system, and achieves driver code protection and remote upgrade efficiency improvement through a layered architecture.

Images