An embedded software generation method and system based on a real-time operating system

Abstract

The application relates to a real-time operating system-based embedded software generation method and system, which comprises the following steps: performing relevance analysis on software functions, splitting software codes into multiple function modules with low relevance, each function module corresponding to single program code; specifying memory addresses for the program codes of each function module, respectively compiling the program codes of each function module to generate executable programs of each function module; loading the executable programs corresponding to each function module into the memory of a real-time operating system according to the memory addresses of the program codes of each function module to generate tasks corresponding to each function module.

Description

Technical Field

[0001] This invention relates to the field of embedded software hot repair technology, and in particular to an embedded software generation method and system based on a real-time operating system. Background Technology

[0002] Hotfix technology is a repair technique that allows software to continue working normally during the update process. This repair technique does not require interrupting software services or restarting the system and has been widely used in traditional software fields such as Linux servers.

[0003] In embedded systems, software runs in a soft-core environment built on an FPGA (Nios II, RISC-V is a processor unit built from logic units). The program generated by the software development tools provided by the chip manufacturer can only be a single program running on the chip (although a multi-tasking operating system can run on the chip, the entire system can only be regarded as a single program).

[0004] Although software design typically employs modular code design, when a bug in a function needs fixing or a new feature is added during operation, other functions should be stopped before proceeding, as software is usually updated as a whole. However, in actual product applications, software upgrades and optimizations are inevitable. Upgrades often require erasing the entire program and rewriting it, rendering the device unusable for a period. This presents a critical problem that needs to be addressed when updating software functionality in real-time and online environments within embedded systems. Summary of the Invention

[0005] Based on the above analysis, the embodiments of the present invention aim to provide an embedded software generation method and system based on a real-time operating system, so as to solve the problem that existing embedded software cannot be updated with new functions after generation.

[0006] On one hand, embodiments of the present invention provide an embedded software generation method based on a real-time operating system, comprising the following steps:

[0007] Perform correlation analysis on the software functions and break down the software code into multiple functional modules with low correlation, with each functional module corresponding to a separate program code;

[0008] Assign memory addresses to the program code of each functional module, and compile the program code of each functional module to generate the executable program of each functional module.

[0009] Based on the memory address of the program code for each functional module, the executable program corresponding to each functional module is loaded into the memory of the real-time operating system, and the task corresponding to each functional module is generated.

[0010] Based on the further improvement of the above technical solution, the compiler's global registers are turned off before compiling the code of each functional module.

[0011] Furthermore, the linker script specifies the memory address and memory size for each code segment of the program code for each functional module.

[0012] Furthermore, based on the memory address of the program code for each functional module, the executable program corresponding to each functional module is loaded into memory, including:

[0013] Based on the specified memory address of each code segment of the program code of each functional module, load each code block of the functional module into the specified memory address.

[0014] Furthermore, when embedded software needs to add new functional modules,

[0015] Specify the memory address for the program code of the newly added functional module, and compile the program code of the functional module to generate the executable program of the functional module;

[0016] Based on the memory address of the program code of the functional module, the executable program corresponding to the functional module is loaded into the memory of the real-time operating system, and the task corresponding to the functional module is generated.

[0017] Furthermore, when embedded software needs to update functional modules,

[0018] Specify the memory address for the program code of the update function module, and compile the program code of the update function module to generate the executable program of the update function module;

[0019] Delete the tasks corresponding to the functional modules that need to be updated in the real-time operating system;

[0020] Based on the memory address of the program code of the update function module, the executable program corresponding to the update function module is loaded into the memory of the real-time operating system, and the task corresponding to the update function module is generated.

[0021] Furthermore, the real-time operating system includes resource lock instructions for controlling peripheral interface access, the resource lock instructions including read lock instructions and write lock instructions.

[0022] Furthermore,

[0023] The read lock instruction is used to determine whether the currently accessed interface is occupied based on the interface parameters when a task accesses a peripheral interface.

[0024] The write lock instruction is used to mark a peripheral interface as occupied when the peripheral interface accessed by the task is not occupied.

[0025] On the other hand, embodiments of the present invention provide an embedded software generation system based on a real-time operating system, comprising the following modules:

[0026] The code generation module is used to perform correlation analysis on software functions, breaking down the software code into multiple functional modules with low correlation, with each functional module corresponding to a separate program code;

[0027] The compilation module is used to specify the memory address for the program code of each functional module, and compile the program code of each functional module to generate the executable program of each functional module.

[0028] The task generation module loads the executable program corresponding to each functional module into the memory of the real-time operating system based on the memory address of the program code of each functional module, and generates the task corresponding to each functional module.

[0029] Based on the further improvement of the above technical solution, the compilation module disables the compiler's global registers before compiling the code of each functional module.

[0030] Compared with existing technologies, this invention breaks down embedded software code into multiple low-correlation functional modules, compiles each functional module separately to generate a corresponding executable program, and generates a corresponding task for each functional module. Thus, the various functional modules of the embedded software run in a multi-tasking manner in a real-time operating system. Each functional module is an independently completed runnable program. Therefore, when it is necessary to update or modify the software functional modules, only the corresponding task of the functional module needs to be updated, without affecting the operation of other tasks. Thus, software function updates can be performed without power outages or restarts, realizing online function updates of embedded software.

[0031] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0032] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0033] Figure 1 This is a flowchart of an embedded software generation method based on a real-time operating system according to an embodiment of the present invention;

[0034] Figure 2This is a block diagram of an embedded software generation system based on a real-time operating system according to an embodiment of the present invention;

[0035] Figure 3 This is a schematic diagram of the code for compiling and linking the script in an embodiment of the present invention;

[0036] Figure 4 This is a schematic diagram of the machine code generated for an embodiment of the present invention. Detailed Implementation

[0037] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0038] Although software design typically employs modular code design, when a bug in a function needs fixing or a new feature is added during operation, other functions should be stopped before proceeding, as software is usually updated as a whole. However, in actual product applications, software upgrades and optimizations are inevitable. Upgrades often require erasing the entire program and rewriting it, rendering the device unusable for a period. This presents a critical problem that needs to be addressed when updating software functionality in real-time and online environments within embedded systems.

[0039] Based on this, a specific embodiment of the present invention discloses an embedded software generation method based on a real-time operating system, such as... Figure 1 As shown, it includes the following steps:

[0040] S1. Conduct correlation analysis on the software functions and break down the software code into multiple functional modules with low correlation, with each functional module corresponding to a separate program code;

[0041] S2. Specify the memory address for the program code of each functional module, and compile the program code of each functional module to generate the executable program of each functional module.

[0042] S3. Load the executable program corresponding to each functional module into the memory of the real-time operating system according to the memory address of the program code of each functional module, and generate the task corresponding to each functional module.

[0043] By breaking down embedded software code into multiple less related functional modules, compiling each module separately to generate a corresponding executable program, and generating corresponding tasks for each module, the embedded software's functional modules can be run in a multi-tasking manner within a real-time operating system. Each functional module is an independently completed executable program. Therefore, when it is necessary to update or modify a software functional module, only the corresponding task of that functional module needs to be updated, without affecting the operation of other tasks. This allows for software function updates without the need for power outages or restarts, enabling online function updates for embedded software.

[0044] It should be noted that the embedded software generation method based on a real-time operating system of the present invention is for cases where there is no memory protection MPU and address mapping unit MMU.

[0045] In implementation, the embedded soft core can be RISC-V, and the real-time operating system can be FreeRTOS.

[0046] Embedded software generation mainly includes four stages: compilation stage, storage stage, loading stage, and runtime stage.

[0047] The compilation phase involves compiling and linking the program code written by developers into an executable program. Existing technology compiles embedded software into a single, complete program, thus requiring a complete software update upon update. This invention breaks down the software into its functional modules, compiling each module separately to generate its own executable program. In implementation, because different software programs have different functions and varying interrelationships, manual analysis of each functional module is necessary to break down the software code into multiple low-relationship functional modules, each corresponding to a separate executable program.

[0048] In existing technologies, embedded program code is compiled with a fixed starting address, for example, 0x1000. Therefore, when compiling the code of each functional module after splitting it, the starting address is still set to 0x1000, meaning all functional modules have the same starting address after compilation. This will obviously cause conflicts during later loading, preventing parallel execution. Therefore, it is necessary to specify a memory address for the program code of each functional module.

[0049] Research has revealed that existing systems use global registers, such as the GP register, during compilation. These global registers are initialized every time the system is compiled. Therefore, it is not convenient to allocate specific memory for each program or to run multiple programs simultaneously. Thus, the compiler's global registers are disabled before compiling the code of each functional module separately, thereby improving the flexibility of dynamic program loading.

[0050] In implementation, for example, when using the RISC-V architecture, the cross-compiler used is riscv-none-embed. In this case, the GP register can be turned off by deleting the "-DUSE_GP" macro definition of CFLAGS+=-march=$(MARCH)-mabi=$(MABI)-DUSE_GP in the riscv64-unknown-elf.mk file.

[0051] When compiling program code, the compiler divides the program code into segments, including: the init segment, the text segment, the bss segment, the data segment, and the stack segment. The init segment is used to initialize the C / C++ language environment; the bss segment is used to store uninitialized global and static variables; the data segment stores initialized global and static variables; the text segment stores the program's executable code; and the stack segment stores local variables inside functions.

[0052] During implementation, the address and size of each code segment can be determined by the developers, ensuring that the code segments between different functional modules do not overlap.

[0053] Specifically, the linker script specifies the memory address and memory size for each code segment of the program code for each functional module.

[0054] During implementation, the MEMORY command in the linker script defines a memory space for each piece of code to be compiled, for example, Figure 3 The system defines two memory spaces, start and ram, using the MEMORY command.

[0055] The SECTIONS command defines the link distribution of various code segments (.text, .data, .bss, etc.). For example, Figure 3 The code uses the AT> keyword to link the text segment to the RAM address, starting at address 0x00100200.

[0056] During implementation, in order to further facilitate the rapid generation of real-time operating system tasks, a main code segment is defined in the code segment to store the entry function address of each functional module.

[0057] During implementation, the main section is defined as follows:

[0058] main:{

[0059] *(.main);

[0060] }>ramAT>ram:ram

[0061] After compiling each functional module, an executable program corresponding to each functional module is generated.

[0062] To facilitate rapid loading of code segments, the starting address and size of each code segment of the functional module are added before each executable program, so that the corresponding code segment can be quickly loaded into the corresponding memory address space.

[0063] During the storage phase, the compiled executable program can be stored in an on-chip or off-chip memory chip.

[0064] During the loading phase, the executable program corresponding to each functional module is loaded into memory according to the memory address of the program code of each functional module. Specifically, step S3 includes:

[0065] Based on the specified memory address of each code segment of the program code of each functional module, load each code segment of the functional module into the specified memory address.

[0066] During implementation, the header information of the executable file is read first, and each code segment is loaded into the corresponding memory address according to the starting address of each segment recorded in the header information.

[0067] For example, corresponding Figure 3 If the text segment in the memory has a corresponding load address of 0x00100200, then the text segment will be placed in memory at address 0x00100200.

[0068] It should be noted that the executable file is loaded after the embedded system is powered on, the hardware is initialized, and the real-time operating system is running.

[0069] After the program code segment is loaded into memory, the init segment is executed to initialize the C / C++ environment. It then calls the real-time operating system's task creation function with the main segment address and stack segment address as parameters to generate the corresponding tasks. This allows the various functional modules of the software to run independently and simultaneously.

[0070] When embedded software needs to add new functional modules

[0071] Specify the memory address for the program code of the newly added functional module, and compile the program code of the functional module to generate the executable program of the functional module;

[0072] Based on the memory address of the program code of the functional module, the executable program corresponding to the functional module is loaded into the memory of the real-time operating system, and the task corresponding to the functional module is generated.

[0073] That is, the newly added functional module is assigned memory space and size according to step S2, and it is compiled into an independent executable program. According to step S3, the various code segments of the executable program are loaded into memory through the loader. The newly added functional module is created as a new task by creating a task function, thereby realizing the addition of embedded software functions without power-off restart and without interrupting the operation of the entire software.

[0074] When embedded software needs to update functional modules

[0075] Specify the memory address for the program code of the update function module, and compile the program code of the update function module to generate the executable program of the update function module;

[0076] Delete the tasks corresponding to the functional modules that need to be updated in the real-time operating system;

[0077] Based on the memory address of the program code of the update function module, the executable program corresponding to the update function module is loaded into the memory of the real-time operating system, and the task corresponding to the update function module is generated.

[0078] That is, the updated functional module is assigned memory space and size according to step S2, compiled into an independent executable program, and the various code segments of the executable program are loaded into memory by the loader according to step S3.

[0079] The delete task function removes the original task corresponding to the updated functional module. The create task function creates a new task for the updated functional module, thus enabling the embedded software to be updated without power restart or interruption of the overall software operation.

[0080] Since the various functional modules run simultaneously as tasks, access conflicts may occur to the interfaces of hardware and other peripherals. Therefore, resource locks need to be added to resolve access conflicts.

[0081] Existing real-time operating systems have complex locking mechanisms and long code implementations. To improve efficiency, this invention uses custom instructions to add resource locks, employs single-pipeline execution by the CPU itself, and implements them with circuit logic. This results in short latency, less code, and ease of use for resource access control.

[0082] Specifically, peripherals commonly used in embedded systems include GPIO, UART, SPI, and I2C. These peripheral interfaces are mapped to a single bit of a 32-bit parameter. For example, the mapping relationship can be shown in Table 1.

[0083] Table 1 Interface Parameter Definition Table

[0084] 31～9 8-bit 7 people 6 people 5 people 4 people 3 people 2 people 1 person 0th idle I2C1 I2C0 SPI1 SPI0 UART1 UART0 GPIO2 GPIO1 GPIO0

[0085] When a parameter of a certain bit is 1, it means that the device corresponding to that bit is occupied, and when it is 0, it means that it is idle.

[0086] The interface parameters are stored in the CPU's internal registers. Initially, all parameter values ​​are 0.

[0087] Specifically, the resource lock instructions include read lock instructions and write lock instructions. The read lock instruction is used to determine whether the currently accessed interface is occupied based on the interface parameters when a task accesses the peripheral interface; the write lock instruction is used to mark the peripheral interface as occupied when the peripheral interface accessed by the task is not occupied.

[0088] During implementation, firstly through

[0089] #define RRK(rs1,rs2)opcode_R(CUSTOM0,0x00,0x00,rs1,rs2)

[0090] #define RWK(rs1,rs2)opcode_R(CUSTOM0,0x01,0x00,rs1,rs2)

[0091] Define the read lock instruction RRK and the write lock instruction RWK respectively.

[0092] First, machine code is generated for the instructions using opcode_R. Specifically, the code for generating the machine code is as follows: Figure 4 As shown.

[0093] Then, the RISC-V module is used to provide a custom instruction interface, adding functional code for the RRK and RKW instructions.

[0094] The RRK instruction returns the value of a specific bit in the interface parameter, either 1 or 0.

[0095] The RWK instruction writes a 1 to a specific bit of the interface parameter. It's worth noting that the functionality of the RWK instruction can be achieved through XOR. For example, to lock the 5th bit of the interface parameter, shift the 1 left by 5 bits, then XOR it with the interface parameter. The result is the new interface parameter, where all other bits are the same as before, except the 5th bit is 1. To unlock the 5th bit, similarly shift the 1 left by 5 bits, then XOR it with the interface parameter. The result is the unlocked interface parameter, where the 5th bit is 0, and the others are the same as before.

[0096] If a functional module needs to access a peripheral interface, it can use the RRK read lock instruction in its program to read the status of the required interface. If the peripheral interface to be accessed is not occupied (i.e., the corresponding bit of the interface parameter is 0), then the RWK write lock instruction is used to lock the peripheral interface to be accessed, that is, to mark the corresponding bit of the interface parameter as 1, and then the interface can be accessed. After using the interface, the corresponding bit of the interface is marked as 0 again using the RWK instruction to achieve the unlocking function. For example, first, the 5th bit is read using RRK(0X20), i.e., whether SPI0 is occupied. If not, then the 5th bit of the interface parameter is set to 1 using RWK(0X20), indicating that SPI0 is occupied. It should be noted that rs2 in the instruction is an extended parameter and is not used at this time.

[0097] If other functional modules need to access the interface while it is occupied by this functional module, and find that the interface is occupied by the RRK lock read command, they will wait for the interface to be unlocked before using it.

[0098] By using commands to lock and unlock, resource access conflicts can be resolved quickly and easily.

[0099] On the other hand, a specific embodiment of the present invention provides an embedded software generation system based on a real-time operating system, such as... Figure 2 As shown, it includes the following modules:

[0100] The code generation module is used to perform correlation analysis on software functions, breaking down the software code into multiple functional modules with low correlation, with each functional module corresponding to a separate program code;

[0101] The compilation module is used to specify the memory address for the program code of each functional module, and compile the program code of each functional module to generate the executable program of each functional module.

[0102] The task generation module loads the executable program corresponding to each functional module into the memory of the real-time operating system based on the memory address of the program code of each functional module, and generates the task corresponding to each functional module.

[0103] Preferably, the compilation module disables the compiler's global registers before compiling the code for each functional module separately.

[0104] The above-described method and system embodiments are based on the same principles, and their related aspects can be referenced from each other to achieve the same technical effects. For specific implementation processes, please refer to the foregoing embodiments, which will not be repeated here.

[0105] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0106] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for generating embedded software based on a real-time operating system, characterized by, The method comprises the following steps: performing relevance analysis on software functions, splitting software codes into a plurality of function modules with low relevance, each function module corresponding to a separate program code; specifying a memory address for the program code of each function module, and compiling the program code of each function module to generate an executable program of each function module; loading the executable program corresponding to each function module into the memory of a real-time operating system according to the memory address of the program code of each function module to generate a task corresponding to each function module; the real-time operating system is a real-time operating system without a memory protection MPU and an address mapping unit MMU; specifying a memory address and a memory size for each code segment of the program code of each function module through a link script; loading the executable program corresponding to each function module into the memory according to the memory address of the program code of each function module, comprising: loading each code block of the function module in the specified memory address according to the specified memory address of each code segment of the program code of each function module.

2. The real-time operating system based embedded software generation method according to claim 1, characterized in that, Before compiling the program code of each function module, the global register of the compiler is closed.

3. The real-time operating system based embedded software generation method according to claim 1, characterized in that, When the embedded software needs to add a function module, specifying a memory address for the program code of the added function module, and compiling the program code of the function module to generate an executable program of the function module; loading the executable program corresponding to the function module into the memory of the real-time operating system according to the memory address of the program code of the function module to generate a task corresponding to the function module.

4. The real-time operating system based embedded software generation method according to claim 1, characterized in that, When the embedded software needs to update a function module, specifying a memory address for the program code of the updated function module, and compiling the program code of the updated function module to generate an executable program of the updated function module; deleting the task corresponding to the function module to be updated in the real-time operating system; loading the executable program corresponding to the updated function module into the memory of the real-time operating system according to the memory address of the program code of the updated function module to generate a task corresponding to the updated function module.

5. The real-time operating system based embedded software generation method according to claim 1, characterized in that, The real-time operating system comprises resource lock instructions for controlling access of peripheral interface, and the resource lock instructions comprise read lock instructions and write lock instructions.

6. The embedded software generation method based on a real-time operating system according to claim 5, wherein the read lock instructions are used to determine whether the current access interface is occupied according to interface parameters when a task accesses a peripheral interface; the write lock instructions are used to mark the peripheral interface as occupied when the peripheral interface accessed by the task is not occupied.

7. An embedded software generation system based on a real-time operating system, characterized by The method comprises the following modules: a code generation module, configured to perform relevance analysis on software functions, split software codes into a plurality of function modules with low relevance, and each function module corresponding to a separate program code; a compiling module, configured to specify a memory address for the program code of each function module, and compile the program code of each function module to generate an executable program of each function module; a task generation module, configured to load the executable program corresponding to each function module into the memory of a real-time operating system according to the memory address of the program code of each function module to generate a task corresponding to each function module; The real-time operating system is a real-time operating system without a memory protection MPU and an address mapping unit MMU; The memory address and the memory size are specified for each code segment of the program code of each function module through a link script; The executable program corresponding to each function module is loaded into the memory according to the memory address of the program code of each function module, including: Each code block of the function module is loaded in the specified memory address according to the specified memory address of each code segment of the program code of each function module.

8. The real-time operating system-based embedded software generation system according to claim 7, characterized in that, The compiling module closes the global register of the compiler before compiling the code of each function module respectively.

Images