Interface forward multiplexing method, system starting method and electronic equipment
By storing API interface addresses in the boot loading layer and reading them in the control layer, positive reuse of API interfaces in the MCU system is achieved, solving the code redundancy problem in resource-constrained systems, reducing storage costs, and improving system reliability and maintainability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-20
- Publication Date
- 2026-03-27
AI Technical Summary
In resource-constrained MCU embedded systems, there is a large amount of redundant code, which leads to increased storage space and higher costs.
In the startup loading layer, the addresses of the API interfaces to be reused are stored in the exit table and in a preset area. The control layer reads and calls these API interfaces from the preset area, thus avoiding duplicate definitions and redundant code through the interface forward reuse method.
By using the interface forward reuse method, code redundancy is significantly eliminated, limited storage resources are maximized, hardware costs are reduced, and the reliability and maintainability of the system are improved.
Smart Images
Figure CN121742907A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of embedded technology, and in particular to an interface forward multiplexing method, a system startup method, and an electronic device. Background Technology
[0002] In resource-constrained MCU (Microcontroller Unit) embedded systems, it has been found that MCUs contain a large amount of redundant code, which increases storage space and leads to increased costs. Summary of the Invention
[0003] The technical problem to be solved by this invention is to provide an interface forward reuse method, a system startup method, and an electronic device to reduce code redundancy and lower costs in resource-constrained MCUs.
[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: An interface forward reuse method, applied to an electronic device, the method comprising: In the startup loading layer, the addresses of the API interfaces to be reused in the startup loading layer are stored in the exit table, and the exit table is stored in a preset area; The control layer reads the exit table from the preset area and calls the API interfaces to be reused in the exit table.
[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A system startup method for an electronic device, the electronic device including a startup loading layer and a control layer, comprising: The startup loading layer and the control layer are executed sequentially. When the control layer is executed, the API interface to be reused obtained in the above-mentioned interface forward reuse method is called, and the startup is completed.
[0006] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described interface forward reuse method.
[0007] The beneficial effects of this invention are as follows: In the boot loading layer, the addresses of API interfaces to be reused are stored in an exit table, and the exit table is stored in a preset area. The control layer reads the exit table from the preset area and calls the API interfaces to be reused in the exit table. In this way, through an exit table containing API addresses provided to the control layer by the boot loading layer, the control layer can directly access and reuse these API addresses when jumping to the control layer, thereby significantly eliminating code redundancy, maximizing the use of limited storage resources, and reducing hardware costs. Attached Figure Description
[0008] Figure 1 A flowchart illustrating the steps of an interface forward reuse method provided in an embodiment of the present invention; Figure 2 A structural diagram of an embedded system provided in an embodiment of the present invention; Figure 3 This is a structural diagram of the system in an application embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0009] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.
[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0011] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.
[0012] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0013] In related technologies, resource-constrained MCU embedded systems often employ a strictly layered architecture design to improve system reliability, security, and maintainability. A typical architecture includes: a bootloader (BOOT) layer, responsible for firmware updates (burning, downloading, verification), low-level hardware initialization, secure boot verification, and application layer jump management. This layer typically executes first after system power-on or reset. A controller (CTRL) layer, responsible for core device driver control (such as peripheral drivers and real-time control algorithms), basic services (such as communication protocol stacks, basic encryption / decryption, and function drivers), and providing a runtime environment for upper-layer applications. This layer is taken over and executed by the bootloader layer after startup. A user application layer (User) layer implements specific business logic and functions, relying on the services provided by the controller layer to run. In the architecture, the user application layer can be considered a task or thread of the controller layer.
[0014] Furthermore, in related technologies, the bootloader layer and control layer have completely independent compilation environments (potentially using different compilers, optimization options, and libraries), separate linking processes (generating independent executable images), fixed non-overlapping Flash memory partitions (each image is stored in different address ranges), and time-sharing mutually exclusive execution (after the bootloader layer finishes execution, it jumps to the control layer; during the control layer's execution, the bootloader layer's code does not reside in memory). This independence prevents the two layers from directly sharing code or data segments. In addition, due to time-sharing execution and resource reuse (especially SRAM and peripherals), during inter-layer jumps, the runtime state of the previous layer (such as global variables, heap memory, and peripheral register states) is completely reset or reinitialized by the next layer to avoid conflicts caused by residual states. However, MCUs have limited storage space for data and code, and many functional codes implemented in the bootloader layer may be identical to those in the control layer. Therefore, MCUs have a large amount of redundant code, which increases storage space and leads to increased costs.
[0015] To address the aforementioned problems, this application provides an interface forward reuse method, a system startup method, and an electronic device. The interface forward reuse method of this application is described in detail below.
[0016] The interface forward reuse method in this application can be used in MCU application scenarios with extremely limited Flash resources. The electronic device in this application can be a financial-related electronic device, such as a POS machine, cash register, or key distribution device.
[0017] The following details the interface forward reuse method of this invention, with reference to the appendix. Figure 1 This includes steps 110 to 120.
[0018] Step 110: In the startup loading layer, store the addresses of the API interfaces to be reused in the startup loading layer to the exit table, and store the exit table to a preset area.
[0019] Step 120: The control layer reads the exit table from the preset area and calls the API interface to be reused in the exit table.
[0020] The bootloader layer is the client BOOT, the control layer is the client CTRL, and program execution starts from the bootloader layer and runs through the control layer. The API interfaces to be reused are the interfaces of the bootloader layer, which can be provided to the control layer for reuse. The exit table is a structured exit table that lists the addresses of the bootloader layer's API interfaces that need to be provided to the control layer. The preset area is the storage area agreed upon by the bootloader layer and the control layer, which can be a register, SRAM, or a physical address.
[0021] As described in the above embodiments, this method stores the addresses of API interfaces to be reused that meet the reuse conditions of the control layer in an exit table during the boot loading layer. The exit table is then stored in a pre-defined area agreed upon by the boot loading layer and the control layer. When the system reaches the control layer, the control layer can read the exit table from the pre-defined area and call the API interfaces to be reused. This approach achieves efficient interface reuse between the boot loading layer and the control layer, avoids redundant definitions and code, maximizes the use of limited Flash resources, reduces dependence on high-capacity Flash MCUs, and effectively reduces hardware costs. Furthermore, the unified agreement on the pre-defined area enhances the reliability and maintainability of interface calls, making it suitable for firmware layering design requirements in various scenarios.
[0022] In one embodiment of this application, the method of storing the export table to a preset area in step 110 includes step 111.
[0023] Step 111: Before jumping from the boot loading layer to the control layer, write the base address of the exit table into a register pre-agreed upon by the boot loading layer and the control layer. The base address of the exit table is the starting position of the exit table; the boot loading layer and the control layer may pre-agre upon one or more CPU general-purpose registers.
[0024] The method for the control layer to read the exit table from the preset area in step 120 includes step 121.
[0025] Step 121: During control layer initialization, read the base address of the exit table from the register, and then read the exit table through the base address of the exit table.
[0026] Specifically, before the loading layer completes its tasks and prepares to jump to the control layer entry point, the starting address (base address) of the exit table structure is written into one or more pre-agreed CPU general-purpose registers (such as R0). During the initialization phase, the control layer first reads the exit table base address from the register.
[0027] In this way, the base address of the exit table can be dynamically passed through the register. Even if the runtime state of the startup loading layer is completely reset or reinitialized by the control layer, the control layer can still obtain the exit table to get a reusable API interface.
[0028] In one embodiment of this application, the method of storing the export table to the preset area in step 110 can be step 112 in addition to step 111.
[0029] Step 112: Obtain the storage area jointly reserved by the linker scripts of the bootloader and control layers. Before the bootloader jumps to the control layer, write the base address of the exit table into the storage area. The storage area jointly reserved by the linker scripts of the bootloader and control layers can be a fixed SRAM location.
[0030] In step 120, the method by which the control layer reads the exit table from the preset area can be either step 121 or step 122.
[0031] Step 122: During control layer initialization, read the base address of the exit table from the storage area, and then read the exit table through the base address of the exit table.
[0032] Specifically, before the startup loading layer completes its tasks and prepares to jump to the control layer entry point, the starting address (base address) of the exit table structure is written to a fixed SRAM location jointly reserved by the startup loading layer and the control layer linker script. During the initialization phase, the control layer first reads the exit table base address from this reserved RAM location.
[0033] In this way, the base address of the exit table can be dynamically passed through the SRAM location. Even if the runtime state of the startup loading layer is completely reset or reinitialized by the control layer, the control layer can still obtain the exit table to get a reusable API interface.
[0034] In one embodiment of this application, the method of storing the export table to the preset area in step 110 can be steps 1131 to 1132 in addition to step 111 or step 112.
[0035] Step 1131: Obtain the absolute address of the flash memory pre-agreed upon by the boot loading layer and the control layer, and bind the exit table to the absolute address through the linker script of the boot loading layer.
[0036] Step 1132: Declare an exit table with absolute addresses in the source code or header file of the control layer. Typically, a pointer to an absolute address is declared in the source code or header file of the control layer to access the exit table.
[0037] In step 120, the method by which the control layer reads the exit table from the preset area can be either step 121 or step 122, or step 123.
[0038] Step 123: During the compilation of the control layer, the exit table is read by absolute address.
[0039] Specifically, the exit table structure is forcibly located to a pre-agreed and known absolute physical address in flash memory, such as 0x02008000, through the linker script of the bootloader layer. During compilation, the control layer's code directly accesses the exit table structure through this known absolute address. This requires the bootloader layer's linker script to ensure that this symbolic address is fixed, and that the control layer declares the exit table structure at that address in its source code or header file, typically by declaring a constant pointer to that address. In this way, the exit table can be statically bound through the absolute physical address, ensuring that even if the runtime state of the bootloader layer is completely reset or reinitialized by the control layer, the control layer can still access the exit table to obtain a reusable API interface.
[0040] In one embodiment of this application, the export table in step 110 includes the magic number magic_number, the version field versoin, the number of API interfaces number, and the list of API interface pointers. The export table is a structure data type. Step 120 includes steps 124 through 128, which precede steps 124 to 128, which call the API interfaces to be reused in the exit table.
[0041] Step 124: Verify whether the magic number in the export table matches the preset value to obtain the first verification result; Step 125: Verify whether the version field of the export table is the preset compatible version to obtain the second verification result; Step 126: Verify whether the number of API interfaces in the export table is within the preset range, and obtain the third verification result; Step 127: Perform a validity check on the API interface pointer list in the export table to obtain the fourth verification result; Step 128: When the first verification result, the second verification result, the third verification result, and the fourth verification result are all verified as passed, call the API interface to be reused in the exit table.
[0042] Specifically, before calling any API interface through the pointer in the exit table, the control layer must perform a reliability check on the exit table: verifying whether the magic number matches the preset value; verifying version compatibility; verifying whether the number of interfaces meets the preset range; and performing a simple validity check on the obtained function pointer itself. This method prevents call failures such as compatibility issues and exceeding the call limit when calling API interfaces in the exit table.
[0043] In one embodiment of this application, step 127 includes step 1271.
[0044] Step 1271: Check whether the API interface pointers in the API interface pointer list fall within the address range of the flash memory where the boot loading layer is located.
[0045] Specifically, a simple validity check can be performed on the API interface pointers obtained from the API interface pointer list, such as checking whether the pointer falls within the Flash address range where the code in the boot loading layer is located. This approach can further improve the reliability of reused API interfaces.
[0046] In one embodiment of this application, the API interface to be reused in step 110 must meet interface constraints, including interface parameter passing constraints, interface call constraints, interface context constraints, interface dependency constraints, interface interruption reentrancy constraints, and interface access to peripherals constraints. The interface parameter passing constraints are: the API does not use global variables or static local variables; the API explicitly passes state information through function parameters; and the API function uses local variables on the stack and the passed parameters. The API call constraints stipulate that API functions are prohibited from calling heap memory management functions, and the working buffer required by the API function is passed in as a parameter by the control layer; Interface context constraints are other functions whose API function calls also satisfy interface parameter passing constraints and interface call constraints. The interface dependency constraint is that API functions should not call operating system-related services; The interface interrupt reentrancy constraint requires that API functions be interruptible and reentrant. Interface access to peripherals constraints are that API functions access peripherals under preset conventions or preset guarantees.
[0047] Although the boot loading layer and the control layer share the same physical SRAM chip, their compilation and linking processes are completely independent. This means that: (1) .data segment (initialized static / global variables): The address ranges allocated to the .data segments by the two linker scripts may be completely different. When the control layer starts up and initializes its own .data segment, it will overwrite the .data variables left in SRAM by the control layer.
[0048] (2) .bss segment (uninitialized static / global variables): Similarly, its runtime address range is different. When the control layer initializes its own .bss (clears it to zero), it will destroy the .bss data left by the startup loading layer.
[0049] (3) Heap: The two layers typically use independent memory pool management (such as different malloc / free implementations or different heap start addresses / sizes). After the control layer is initialized, its heap manager cannot be aware of or safely use the heap memory blocks allocated by the bootloader layer.
[0050] (4) Stack: When jumping between layers, the stack pointer will be reset to the stack space defined by the control layer.
[0051] (5) Peripheral registers: The required peripherals will be reconfigured during the initialization of the control layer, overriding the settings of the startup loading layer.
[0052] Therefore, to ensure that the reused bootloader layer APIs do not depend on the corrupted bootloader layer state when called in the control layer environment, these APIs must strictly adhere to the following constraints: (1) Stateless: API functions cannot use any global variables or static local variables. All state information required for operations must be explicitly passed through function parameters. The function should only use local variables (automatic variables) on the stack and the passed parameters.
[0053] (2) No Dynamic Memory Operations: API functions are prohibited from calling heap memory management functions such as malloc, calloc, realloc, and free. The heap manager of the control layer is independent of the bootloader layer. It is dangerous and undefined to operate on heap memory allocated by the bootloader layer or attempt to allocate on the control layer's heap. The working buffer required by the API should be passed in as a parameter by the caller (control layer).
[0054] (3) Context-Independent / Pure Functions: API functions can only call other functions that also satisfy the conditions of being stateless and having no dynamic memory constraints. Pure functions from the standard library that do not depend on global state and are thread-safe (i.e., stateless in this scenario) are allowed, such as memcpy, memset, and basic mathematical operations (sin and cos require verification of whether their implementations are stateless). Library functions that depend on errno, internal buffers, or static state (such as some strtok implementations) are prohibited.
[0055] (4) Not dependent on specific OS / RTOS: API functions cannot call any operating system-related services (such as task creation, semaphores, queues, timers of specific OS) because the OS environment in which the control layer runs is unrelated to the boot loading layer.
[0056] (5) Interrupts & Reentrancy: If the API may be called by an interrupt service routine (ISR) or may be interrupted itself, or if the control layer is a multitasking environment, then the API must be reentrant. This is usually also guaranteed by being stateless and using only stack variables. Avoid using non-reentrant library functions.
[0057] (6) Peripheral access constraints: Generally, APIs do not directly access peripheral registers. The required peripheral operations should be passed to the control layer via parameters with a configured peripheral handle or completely initialized and used by the API internally before being closed. However, this may violate statelessness or introduce timing dependencies. But for APIs that must operate on peripherals, such as Flash erase / write drivers, it is necessary to explicitly agree and guarantee that: before the API call, the control layer must ensure that the relevant peripherals are in the initial state required by the API, such as clock enabled and necessary configuration completed; the API should not assume any specific configuration of the peripherals except for the configuration of the lowest-level clock it depends on, and should configure the required registers itself; after the API is executed, the peripheral state may be changed, and the control layer needs to be responsible for subsequent management.
[0058] Please refer to Figure 2Another embodiment of this application provides a system startup method for an electronic device, the electronic device including a startup loading layer 202 and a control layer 203, the method including step S210.
[0059] Step S210: Execute the startup loading layer and control layer in sequence. When executing the control layer, call the API interface to be reused obtained in the above-mentioned interface forward reuse method and complete the startup.
[0060] Specifically, during system startup, the boot loading layer 202 and control layer 203 are executed sequentially. After system power-on or reset, the loading layer is executed first, storing reusable API interface information in the exit table. After the boot loading layer starts, the control layer takes over execution, retrieving reusable API interface information from the exit table to achieve forward interface reuse during startup. The system also includes a user application layer 204, which typically shares the same runtime environment with the control layer, such as the same SRAM space, stack, and peripheral access permissions. The lifecycle of the user application layer is managed by the control layer, such as starting as a thread. The user application layer implements specific business logic and functions, relying on services provided by the control layer. The system also includes a manufacturer layer 201, through which firmware code and other information are passed to the boot loading layer 202. This approach avoids redundant definitions and code for the same API interfaces in the boot loading layer and control layer, effectively reducing hardware costs.
[0061] Please refer to Figure 3 The following describes in detail an application embodiment of this application: an interface forward multiplexing method for electronic devices, including a Bootloader 301 (equivalent to...). Figure 2 (manufacturer level), customer BOOT302 (equivalent to) Figure 2 (startup loading layer), customer CTRL303 (equivalent to) Figure 2 The control layer) and the client APP304 (equivalent to Figure 2 (User application layer), where customer BOOT302, customer CTRL303 and customer APP304 belong to the upper-layer customer code, the method includes steps 310 to 320.
[0062] Step 310: Store the addresses of the API interfaces to be reused in the customer's BOOT to the exit table, and store the exit table to a register or an absolute address. This is equivalent to step 110 above.
[0063] Step 320: The client uses CTRL to read the exit table from the register or absolute address and calls the API interface to be reused in the exit table. This is equivalent to step 120 above.
[0064] In this application example, forward multiplexing involves the upper layer (client CTRL) calling the lower layer (client BOOT) code. The upper layer can load from the lower layer and pass the exit table through registers or absolute addresses.
[0065] The process involves the manufacturer's Bootloader 301 transmitting firmware code and other information to the customer's Bootloader. The customer's application typically shares the same runtime environment as the customer's CTRL, and the customer's application lifecycle is managed by the customer's CTRL. The user application layer implements specific business logic and functions, relying on services provided by the customer's CTRL. This approach avoids redundant definitions and code for the same API interfaces in both the customer's Bootloader and CTRL, effectively reducing hardware costs.
[0066] Please refer to Figure 4 The present invention also provides an electronic device 400, including a memory 401 and a processor 402, and a computer program stored on the memory 401 and running on the processor 402. When the processor 402 executes the computer program, it implements the various steps in the interface forward reuse method described above.
[0067] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.
[0068] In summary, this invention provides an interface forward reuse method, a system startup method, and an electronic device. In the startup loading layer, the addresses of API interfaces to be reused are stored in an exit table, and the exit table is stored in a preset area. The control layer reads the exit table from the preset area and calls the API interfaces to be reused in the exit table. To ensure that the reused APIs do not depend on the corrupted startup loading layer state when called in the control layer environment, the API interfaces to be reused must satisfy the following requirements: statelessness, no dynamic memory operations, independence from a specific operating system, interruptibility and reentrancy, and constraints on peripheral access. Furthermore, when storing the exit table in the preset area, the information of the exit table can be dynamically passed to a register agreed upon by the startup loading layer and the control layer, or to a fixed SRAM location reserved for both. During the initialization phase, the control layer first reads the base address of the exit table from the register or the reserved RAM location; alternatively, the exit table and an absolute physical address pre-agreed upon by the startup loading layer and the control layer can be forcibly located through static binding. In this way, in a heterogeneous execution environment with a layered bootloader layer and a control layer, the method of safely and efficiently reusing the key functional APIs of the bootloader layer can significantly eliminate code redundancy, maximize the utilization of limited Flash resources, and reduce dependence on high-capacity Flash MCUs, thereby effectively reducing system hardware costs. At the same time, this method strictly ensures that after resource reclamation and reinitialization caused by inter-layer jumps, the reused APIs can still be safely and reliably called by the control layer.
[0069] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.
Claims
1. A method for forward reuse of an interface, characterized in that, Applied to electronic devices, the method includes: In the startup loading layer, the addresses of the API interfaces to be reused in the startup loading layer are stored in the exit table, and the exit table is stored in a preset area; The control layer reads the exit table from the preset area and calls the API interfaces to be reused in the exit table.
2. The interface forward reuse method according to claim 1, characterized in that, The step of storing the export table to a preset area includes: Before the startup loading layer jumps to the control layer, the base address of the exit table is written into a register pre-agreed between the startup loading layer and the control layer; The step of the control layer reading the export table from the preset area includes: During control layer initialization, the base address of the exit table is read from the register, and the exit table is read through the base address of the exit table.
3. The interface forward reuse method according to claim 1, characterized in that, The step of storing the export table to a preset area includes: Obtain the storage area jointly reserved by the linker scripts of the startup loading layer and the control layer, and write the base address of the exit table into the storage area before the startup loading layer jumps to the control layer; The step of the control layer reading the export table from the preset area includes: During control layer initialization, the base address of the exit table is read from the storage area, and the exit table is read through the base address of the exit table.
4. The interface forward reuse method according to claim 1, characterized in that, The step of storing the export table to a preset area includes: Obtain the absolute address of the flash memory pre-agreed upon by the boot loading layer and the control layer, and bind the exit table to the absolute address through the linker script of the boot loading layer; Declare the exit table for the absolute address in the source code or header file of the control layer; The step of the control layer reading the export table from the preset area includes: During the compilation of the control layer, the exit table is read through the absolute address.
5. The interface forward reuse method according to claim 4, characterized in that, The exit table that declares the absolute address in the source code or header file of the control layer includes: Declare a pointer to the exit table in the source code or header file of the control layer, the pointer pointing to the absolute address.
6. The interface forward reuse method according to claim 1, characterized in that, The export table includes a magic number, a version field, the number of API interfaces, and a list of API interface pointers; The step of calling the API interface to be reused in the export table includes: Verify whether the magic number in the export table matches the preset value to obtain the first verification result; Verify whether the version field of the export table is a preset compatible version to obtain a second verification result; Verify whether the number of API interfaces in the export table is within the preset range to obtain a third verification result; The validity of the API interface pointer list in the export table is checked to obtain the fourth verification result; When the first verification result, the second verification result, the third verification result, and the fourth verification result are all verified as passed, the API interface to be reused in the exit table is called.
7. The interface forward reuse method according to claim 6, characterized in that, The validity check of the API interface pointer list in the export table includes: Check whether the API interface pointers in the API interface pointer list fall within the address range of the flash memory where the boot loading layer is located.
8. The interface forward reuse method according to claim 1, characterized in that, The API interface to be reused satisfies the interface constraints, which include interface parameter passing constraints, interface call constraints, interface context constraints, interface dependency constraints, interface interruption reentrancy constraints, and interface access to peripherals constraints. The interface parameter passing constraints are: the API does not use global variables or static local variables; the API explicitly passes state information through function parameters; and the API function uses local variables on the stack and the passed parameters. The interface call constraints stipulate that API functions are prohibited from calling heap memory management functions, and the working buffer required by the API functions is passed in by the control layer through parameters; The interface context constraint is that the API function call also satisfies the interface parameter passing constraint and the interface call constraint for other functions. The interface dependency constraint is that API functions do not call operating system-related services; The interface interrupt reentrancy constraint requires that API functions have interruptibility and reentrancy. The interface access peripheral constraints are that API functions access peripherals under preset conventions or preset guarantees.
9. A system startup method for an electronic device, characterized in that, The electronic device includes a boot loading layer and a control layer, including: The startup loading layer and the control layer are executed sequentially. When the control layer is executed, the API interface to be reused obtained in any one of the interface forward reuse methods described in claims 1 to 8 is called, and the startup is completed.
10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements each step of the interface forward reuse method according to any one of claims 1 to 8.