A method for separating the compilation, loading, and execution of master-slaves software based on Cortex M.

Abstract

The application provides a master-slave software separation compiling, loading and running method based on Cortex M, which comprises the following steps: step 100: determining the flash space of master software and slave software according to the flash resource demand of the master software and the slave software and leaving space margin for each software; step 200: determining the Ram and TCM space of the master software and the slave software according to the Ram and TCM resource demand of the master software and the slave software and leaving space margin for each software; step 300: respectively connecting the power-on loading API pointer and the public API pointer to the Vector offset address 28 and 32 of the Cortex M platform; step 400: completing the hardware initialization and program loading of the master software; step 500: power-on initialization of the master software and the slave software; step 600: loading of the slave software and connection of the public API pointer; step 700: instantiating the public API of the slave software according to the public API header file of the slave software and calling; and step 800: instantiating the public API of the master software and other slave software according to the public API header file of the master software and other slave software and calling.

Description

Technical Field

[0001] This invention belongs to the field of embedded software, specifically relating to a method for separating the compilation, loading, and execution of master-slaves software based on Cortex M. Background Technology

[0002] In the traditional embedded software development process, when multiple software development teams work together to complete a complex software project, each team independently develops the software functional modules they are responsible for, and finally integrates the software to form a comprehensive software.

[0003] When software modules developed by different teams call each other during software development, such as software module A calling the API of software module B, software module A cannot be compiled independently if software module B is not available, which increases the software development cycle to some extent.

[0004] When teams collaborate on software development, software integration can be done in two ways: white-box integration, where the integrated object is the software source code, but this is not conducive to protecting the trade secrets between teams; or black-box integration, where the integrated object is a library, but the library cannot be directly debugged, increasing the difficulty of software development and debugging. Summary of the Invention

[0005] The purpose of this invention is to effectively solve the numerous problems encountered by multiple software teams in software development, integration, and debugging under the Cortex M platform. Specifically, considering the characteristics of embedded software, this invention provides a method for separating the compilation, loading, and execution of master-slaves software based on Cortex M, which can effectively improve the interoperability between embedded software modules under this platform and support the development, integration, and debugging of embedded software.

[0006] Technical solution: A method for separating the compilation, loading, and execution of master-slaves software based on Cortex M, the method including:

[0007] Step 100: Based on the Flash resource requirements of the master software and slave software, and with sufficient space reserved for each software, determine the Flash space for the master software and slave software respectively;

[0008] Step 200: Based on the RAM and TCM resource requirements of the master software and slave software, and with sufficient space for each software, determine the RAM and TCM space of the master software and slave software.

[0009] Step 300: The Vector offset addresses 28 and 32 of the Cortex M platform are respectively connected to the power-on load API pointer and the public API pointer;

[0010] Step 400: The master software completes hardware initialization and program loading;

[0011] Step 500: Power on and initialize the master and slave software;

[0012] Step 600: Load the slave software and attach the public API pointer;

[0013] Step 700: The master software instantiates the slave software's public API based on the slave public API header file and then calls it;

[0014] Step 800: The slave software instantiates and calls the common API of the master software and other slave software based on the common API header files of the master software and other slave software.

[0015] Furthermore, step 100 specifically includes:

[0016] Step 101: The master software must start from offset address 0 of the Flash memory, allocate Flash offset addresses 0 to (addr_1-1) according to the master software's requirements for Flash resources and leave space margin;

[0017] Step 102: Each slave software, in turn, allocates Flash space according to its Flash resource requirements and with corresponding slave space margin.

[0018] Furthermore, step 200 specifically includes:

[0019] Step 201: The master software must plan its running space in at least one of the Ram or TCM storage spaces.

[0020] Step 202: Each of the m slave software programs shall plan its running space in at least one of the storage spaces, Ram or TCM.

[0021] Furthermore, 300 specifically includes:

[0022] Step 301: The master software does not power on and load the API; write 0 to the vector offset address 28 of the master software; attach the master public API pointer to the vector offset address 32 of the master software.

[0023] Step 302: The slave software's Vector offset address 28 is attached to the slave software's power-on loading API pointer; the slave software's Vector offset address 32 is attached to the slave's public API pointer.

[0024] Furthermore, step 400 specifically includes:

[0025] Step 401: The master software completes the hardware initialization of the CPU Core, Clock Tree, and Bus of the Cortex M platform;

[0026] Step 402: The master software loads the software code segments and data segments stored in the Flash space into the Ram space and TCM space.

[0027] Furthermore, step 500 specifically includes:

[0028] Step 501: Save the public APIs provided by the master software into a separate Master public API header file;

[0029] Step 502: Connect the public API provided by the master software to the Vector offset address 32;

[0030] Step 503: The master software calls the power-on loading API pointer at the Vector offset address 28 of each slave software to complete the power-on loading of the slave software.

[0031] Furthermore, step 600 includes:

[0032] Step 601: The slave software completes the loading of the software code segment and data segment stored in the Flash space into the Ram space and TCM space upon power-on.

[0033] Step 602: Save the public APIs provided by the slave software into a separate slave public API header file;

[0034] Step 603: Connect the API that the slave software exposes to the outside world to the Vector offset address 32.

[0035] Furthermore, step 700 includes:

[0036] Step 701: The master software uses the slave public API header file to instantiate the public APIs provided by each slave software;

[0037] Step 702: The master software calls the public API of the instantiated slave software to complete the vector jump and execution in the slave software.

[0038] Furthermore, step 800 includes:

[0039] Step 801: The slave software uses the master's public API header file and other slave public API header files to instantiate the APIs provided by the master software and other slave software;

[0040] Step 802: The slave software calls the API of the instantiated master software to complete the vector jump and execution in the master software;

[0041] Step 803: The slave software calls the instantiated slave software API to complete the slave software vector jump and execution.

[0042] This invention provides a method for separating the compilation, loading, and execution of master-slaves software based on Cortex M. This method constrains the compilation and execution space of each software, enabling each software to run and load independently without interfering with each other. By constraining the public API calling method, this method greatly enhances the interoperability between software, facilitates software debugging, and effectively protects the trade secrets of each software team. Attached Figure Description

[0043] Figure 1 This is a schematic diagram of master-slave software Flash deployment provided by the present invention;

[0044] Figure 2 This is a schematic diagram of RAM deployment during master-slave software runtime provided by the present invention;

[0045] Figure 3 This is a schematic diagram of the master-slave software Vector connection provided by the present invention;

[0046] Figure 4 This is a schematic diagram of the power-on loading process of the master software provided by the present invention;

[0047] Figure 5 This is a schematic diagram of the master-slave software power-on initialization process provided by the present invention;

[0048] Figure 6 This is a schematic diagram of the power-on loading process of the slave software provided by the present invention;

[0049] Figure 7This is a schematic diagram of the process of the master software calling the slave public API provided by the present invention;

[0050] Figure 8 This is a schematic diagram of the process of slave software calling the master's public API provided by the present invention. Detailed Implementation

[0051] The method will now be described in further detail with reference to the accompanying drawings.

[0052] In practical applications, the master software schedules other slave software; however, this invention only allows for one master software. Slave software works in conjunction with the master software to perform specific functions; this invention can have multiple slave software.

[0053] The following example illustrates the process of independently developing and integrating one master software and m (m≥1) slave software modules, explaining the method provided by this invention. Specifically, it includes:

[0054] Step 100: Based on the Flash resource requirements of the master software and slave software, and with sufficient space reserved for each software, determine the Flash space for the master software and slave software respectively;

[0055] Understandably, master-slave software Flash deployment is part of the software compilation process, used to determine the address space for the master software and m slave software to be stored and run in Flash.

[0056] like Figure 1 As shown, step 100 specifically includes:

[0057] Step 101: The master software must start from offset address 0 of the Flash memory and allocate Flash offset addresses from 0 to (addr_1-1) according to the master software's Flash resource requirements and with sufficient space.

[0058] The master space should have a minimum margin of 20%.

[0059] Step 102: Each slave software, in turn, allocates Flash space according to its Flash resource requirements and with corresponding slave space margin.

[0060] The slave space margin should be at least 20%.

[0061] It should be noted that the order in which the slave software allocates Flash space is not important. The Flash space of the master software and slave software should be contiguous.

[0062] For example, if the master software's Flash space is 0 to (addr_1-1), then the next slave software's Flash space is (addr_1) to (addr_2-1); if there is more than one slave software, then the next slave software's Flash space is (addr_2) to (addr_3-1), and so on.

[0063] Step 200: Based on the RAM and TCM resource requirements of the master software and slave software, and with sufficient space for each software, determine the RAM and TCM space of the master software and slave software.

[0064] It should be noted that TCM includes ITCM and DTCM.

[0065] Understandably, the RAM deployment during master-slave software runtime is part of the software compilation process and is used to determine the runtime address space of a master software and m slave software in RAM, ITCM, and DTCM.

[0066] like Figure 2 As shown, step 200 specifically includes:

[0067] Step 201: The master software must plan its running space in at least one of the Ram or TCM storage spaces.

[0068] Step 202: Each of the m slave software programs shall plan its running space in at least one of the storage spaces, Ram or TCM.

[0069] It should be noted that, because TCM resources are limited, software with high computing demands will be prioritized for deployment there. Ultimately, x, y, and z software programs will be deployed in Ram, ITCM, and DTCM, respectively, satisfying (x≤(1+m)), (y≤(1+m)), and (z≤(1+m)).

[0070] For example, if the ITCM space of the master software is 0 to (addr_1-1), then the ITCM space of the next slave software is (addr_1) to (addr_2-1).

[0071] Step 300: The Vector offset addresses 28 and 32 of the Cortex M platform are respectively connected to the power-on load API pointer and the public API pointer;

[0072] Understandably, the master-slave software Vector attachment is part of the software compilation process. It uses reserved addresses in the Cortex-M platform's Vector as public API attachment addresses to facilitate interoperability between master and slave software. This invention uses offset addresses 28 and 32 in the Vector, where offset address 28 is used to attach the software power-on loaded API pointer, and offset address 32 is used to attach the public API pointer.

[0073] like Figure 3 As shown in the diagram, the parameter passing and result return during the function call process with numerical arrows are illustrated. Step 300 specifically includes:

[0074] Step 301: The master software does not power on and load the API. Write 0 to the vector offset address 28 of the master software; attach the master public API pointer to the vector offset address 32 of the master software.

[0075] Step 302: The slave software's Vector offset address 28 is attached to the slave software's power-on loading API pointer; the slave software's Vector offset address 32 is attached to the slave's public API pointer.

[0076] Step 400: The master software completes hardware initialization and program loading;

[0077] Understandably, the master software is loaded upon power-up, which is part of the software loading process. After power-up, it completes the hardware initialization of the embedded system, including the CPU Core, ClockTree, Bus, etc.; and loads the master software code segment, data segment, etc., into RAM, ITCM, and DTCM.

[0078] like Figure 4 As shown, step 400 specifically includes:

[0079] Step 401: The master software completes the hardware initialization of the CPU Core, Clock Tree, and Bus of the Cortex M platform.

[0080] Step 402: The master software loads the software code segments and data segments stored in the Flash space into the Ram space and TCM space.

[0081] Step 500: Power on and initialize the master and slave software;

[0082] Understandably, the master software's power-on initialization is part of the software operation process and is completed by the master software: the master software connects its externally developed APIs to the Vector offset address 32, and the master software calls the function pointers at the Vector offset address 28 of each slave to complete the slave software's power-on loading.

[0083] like Figure 5 As shown, step 500 specifically includes:

[0084] Step 501: Save the public APIs provided by the master software into a separate Master public API header file;

[0085] The Master public API header file is shown in Table 1.

[0086] Step 502: Connect the public API provided by the master software to the Vector offset address 32;

[0087] The master software public API connections are shown in Table 2.

[0088] Step 503: The master software calls the power-on loading API pointer at the Vector offset address 28 of each slave software to complete the power-on loading of the slave software.

[0089] It should be noted that the software power-on loading API pointer is the same as the slave software power-on loading API in step 600.

[0090] Table 1 Master Public API Header Files

[0091]

[0092] Table 2 Master Software Public API Connections

[0093]

[0094] Step 600: Load the slave software and attach the public API pointer;

[0095] Understandably, the slave software power-on loading is part of the software loading process: loading the slave software code segment, data segment, etc., into RAM, ITCM, and DTCM; and attaching the slave software's public API to Vector offset address 32.

[0096] Specifically, step 600 includes:

[0097] Step 601: The slave software completes the loading of the software code segment and data segment stored in the Flash space into the Ram space and TCM space upon power-on.

[0098] like Figure 6 As shown, the initialization data segment is first loaded into the Ram space, ITCM space, and DTCM space, and then all uninitialized segments are filled with 0.

[0099] Step 602: Save the public APIs provided by the slave software into a separate slave public API header file, as shown in Tables 3, 4, and 5.

[0100] Step 603: Connect the API that the slave software exposes to the outside world to the Vector offset address 32.

[0101] It should be noted that the Flash offset addresses of the slave software determined in step 1 are addr_1, addr_2, ..., addr_m, as follows: Figure 1 As shown in Table 6, the power-on loading function pointers for each slave software are addr_1+32, addr_2+32...addr_m+32, respectively.

[0102] Table 3 slave_1 Public API Header Files

[0103]

[0104] Table 4 slave_2 Public API Header Files

[0105]

[0106] Table 5 slave_m public API header file

[0107]

[0108] Table 6. Slave Software Public API Connections

[0109]

[0110] Step 700: The master software instantiates the slave software's public API based on the slave public API header file and then calls it;

[0111] It is understandable that the master software calls the slave API, which is part of the software operation process. After instantiating the APIs provided by each slave, the call is executed.

[0112] Specifically, step 700 includes:

[0113] Step 701: The master software uses the slave public API header file to instantiate the public APIs provided by each slave software, as shown in Table 7.

[0114] Step 702: The master software calls the public API of the instantiated slave software to complete the vector jump and execution in the slave software, such as... Figure 7 As shown in the figure, the parameter passing and result return during the function call process with the numbered arrows are illustrated.

[0115] Table 7 shows the instantiation of the slave public API in the master.

[0116]

[0117] Step 800: The slave software instantiates and calls the common API of the master software and other slave software based on the common API header files of the master software and other slave software.

[0118] It is understandable that when slave software calls the public APIs of the master software and other slave software, it is part of the software operation process. After instantiating the public APIs provided by the master software and other slave software, the call execution is completed.

[0119] Specifically, step 800 includes:

[0120] Step 801: The slave software uses the master public API header file and other slave public API header files to instantiate the APIs provided by the master software and other slave software, as shown in Table 8.

[0121] Step 802: The slave software calls the instantiated master software API to complete the vector jump and execution in the master software, such as... Figure 8 As shown in the figure, the parameter passing and result return during the function call process with the numbered arrows are illustrated.

[0122] Step 803: The slave software calls the instantiated slave software API to complete the slave software vector jump and execution, such as... Figure 8 As shown in the figure, the parameter passing and result return during the function call process with the numbered arrows are illustrated.

[0123] Table 8. Instantiation of the public APIs for master and slave in slave mode.

[0124]

[0125] In summary, this invention provides a method for separating the compilation, loading, and execution of master-slaves software based on Cortex M. This method includes: (1) master-slave software Flash deployment; (2) master-slave software runtime RAM deployment; (3) master-slave software Vector attachment; (4) master software power-on loading process; (5) master software power-on initialization process; (6) slave software power-on loading process; (7) master calling slave API methods; and (8) slave calling master and other slave API methods. This solves the following two problems faced in the collaborative development of "master-slaves," i.e., one master software and multiple slave software: (1) white-box integration, where the integrated object is the software source code, which is detrimental to the protection of commercial secrets between teams; and (2) black-box integration, where the integrated object is a library, which cannot be directly debugged, increasing the difficulty of software development and debugging.

Claims

1. A method for separating the compilation, loading, and execution of master-slaves software based on Cortex M, characterized in that, The methods include: Step 100: Based on the Flash resource requirements of the master and slave software, and with sufficient space allocated for each software, determine the Flash space required for the master and slave software respectively; Step 200: Based on the RAM and TCM resource requirements of the master software and slave software, and with sufficient space for each software, determine the RAM space and TCM space of the master software and slave software. Step 300: The Vector offset addresses 28 and 32 of the Cortex M platform are respectively connected to the power-on load API pointer and the public API pointer; Step 400: The master software completes hardware initialization and program loading; Step 500: Power on and initialize the master and slave software; Step 600: Load the slave software and attach the public API pointer; Step 700: The master software instantiates the slave software's public API based on the slave public API header file and then calls it; Step 800: The slave software instantiates and calls the common API of the master software and other slave software based on the common API header files of the master software and other slave software.

2. The method according to claim 1, characterized in that, Step 100 specifically includes: Step 101: The master software must start from offset address 0 of the Flash memory and allocate Flash offset address 0~(addr_1-1) according to the master software's Flash resource requirements and with sufficient space. Step 102: Each slave software, in turn, allocates Flash space according to its Flash resource requirements and with corresponding slave space margin.

3. The method according to claim 1, characterized in that, Step 200 specifically includes: Step 201: The master software must plan its runtime space in at least one of the Ram or TCM storage spaces; Step 202: Each of the m slave software programs shall plan its running space in at least one of the storage spaces, Ram or TCM.

4. The method according to claim 1, characterized in that, 300 specifically includes: Step 301: The master software does not power on and load the API; write 0 to the vector offset address 28 of the master software; attach the master public API pointer to the vector offset address 32 of the master software. Step 302: The slave software's Vector offset address 28 is attached to the slave software's power-on loading API pointer; the slave software's Vector offset address 32 is attached to the slave's public API pointer.

5. The method according to claim 1, characterized in that, Step 400 specifically includes: Step 401: The master software completes the hardware initialization of the CPU Core, Clock Tree, and Bus of the Cortex M platform; Step 402: The master software loads the software code segments and data segments stored in the Flash space into the Ram space and TCM space.

6. The method according to claim 1, characterized in that, Step 500 specifically includes: Step 501: Save the public APIs provided by the master software into a separate Master public API header file; Step 502: Connect the public API provided by the master software to the Vector offset address 32; Step 503: The master software calls the power-on loading API pointer at the Vector offset address 28 of each slave software to complete the power-on loading of the slave software.

7. The method according to claim 1, characterized in that, Step 600 includes: Step 601: The slave software completes the loading of the software code segment and data segment stored in the Flash space into the Ram space and TCM space upon power-on. Step 602: Save the public APIs provided by the slave software into a separate slave public API header file; Step 603: Connect the API that the slave software exposes to the outside world to the Vector offset address 32.

8. The method according to claim 1, characterized in that, Step 700 includes: Step 701: The master software uses the slave public API header file to instantiate the public APIs provided by each slave software; Step 702: The master software calls the public API of the instantiated slave software to complete the vector jump and execution of the slave software.

9. The method according to claim 1, characterized in that, Step 800 includes: Step 801: The slave software uses the master's public API header file and other slave public API header files to instantiate the APIs provided by the master software and other slave software; Step 802: The slave software calls the instantiated master software API to complete the vector jump and execution in the master software; Step 803: The slave software calls the instantiated slave software API to complete the slave software vector jump and execution.

Images