Method for managing memory allocation of embedded device, and embedded device

Abstract

Provided in the present application is a method for managing memory allocation of an embedded device. The method comprises: a linker placing a plurality of sections of at least one link module in physically continuous locations in instruction memory and data memory of the embedded device; and after operation of the at least one link module is completed, releasing the at least one link module, such that the physically continuous locations in the instruction memory and the data memory can be released into a dynamic memory pool to be used as allocatable data memory. The technical solution of the present invention can effectively optimize memory allocation and release of embedded devices, particularly the timely release of static memory used during compilation, thereby improving the utilization rate of memory.

Description

A method for managing memory allocation of an embedded device and an embedded device Technical Field

[0001] The present application relates to the field of embedded technology, and in particular to a method for managing memory allocation of an embedded device, an embedded device, and a computer-readable storage medium. Background Art

[0002] An embedded system integrates computer hardware and software, typically used in specific application scenarios such as industrial control, smart homes, and the Internet of Things. Embedded systems are characterized by high requirements for performance, power consumption, cost, and reliability. Therefore, the design and development of embedded systems requires consideration of multiple factors, one of which is memory optimization.

[0003] Memory is a crucial resource in embedded systems, impacting system speed, stability, and functionality. Memory in embedded systems is typically divided into random access memory (RAM) and read-only memory (ROM). RAM is a read-write memory used to store data and variables during program execution. It has fast read and write speeds and can communicate directly with the CPU, but data is lost after a power outage. Furthermore, instructions and data stored in RAM in embedded systems are typically accessed using different buses. Therefore, RAM can be further divided into instruction RAM (IRAM) for storing instructions and data RAM (DRAM) for storing data.

[0004] Due to the limited memory capacity in embedded systems, especially in the low-cost single-chip microcomputer (MCU) sector, users tend to maximize chip performance and memory utilization, often leading to insufficient memory. Therefore, memory optimization is a frequent concern for those skilled in the art. Memory usage in embedded systems is primarily divided into two phases: compile time and runtime. However, existing memory optimization techniques primarily focus on runtime memory optimization, using techniques such as dynamic memory management, memory pools, memory compression, and memory mapping to improve RAM utilization and reduce memory fragmentation. In contrast, the prior art lacks sufficient research on compile-time memory optimization. Even the few existing techniques that optimize compile-time memory primarily focus on reducing the memory consumed by compilation, without addressing the overall release of module memory occupied during compilation. Consequently, even if a corresponding memory module is only used once during compilation, it remains occupied throughout the product's operating life, resulting in low memory utilization and significant waste.

[0005] In view of this, providing a memory management method that can release memory used during compilation for reuse and reduce memory fragmentation as much as possible is one of the technical problems that urgently need to be solved by those skilled in the art.

[0006] It should be understood that the technical problems listed above are only examples and not limitations of the present invention, and the present invention is not limited to technical solutions that solve all of the above technical problems at the same time. The technical solution of the present invention can be implemented to solve one or more of the above or other technical problems. Summary of the Invention

[0007] To solve the above and other problems, the present application provides a method for managing memory allocation of an embedded device, comprising: placing, by a linker, multiple segments of at least one link module in physically continuous locations of the instruction memory and data memory of the embedded device; and releasing at least one link module after the at least one link module has completed execution, so that the physically continuous locations of the instruction memory and data memory are released into a dynamic memory pool for use as allocatable data memory.

[0008] Optionally, each of the multiple sections is selected from one or more of a .text section, a .data section, and a .bss section.

[0009] Further optionally, the step of placing multiple segments of at least one link module in physically consecutive locations of the instruction memory and the data memory includes: placing the .text segment of the multiple segments in the instruction memory, and placing the .data segment and / or .bss segment of the multiple segments in the data memory.

[0010] Optionally, physically consecutive locations of the instruction memory and the data memory can be consecutively addressed by the embedded device.

[0011] Further optionally, the step of releasing at least one link module further includes: converting the address of the instruction memory where the .text section in the at least one link module is located into the address of the corresponding data memory.

[0012] Optionally, the at least one link module comprises one link module. In an alternative embodiment, the at least one link module comprises two or more link modules.

[0013] Optionally, the step of releasing at least one link module comprises releasing two or more link modules simultaneously. In an alternative embodiment, the step of releasing at least one link module comprises releasing two or more link modules in batches.

[0014] The present application also provides an embedded device comprising one or more processors, a volatile memory and a non-volatile memory, wherein the non-volatile memory stores computer-readable instructions, and when the computer-readable instructions are configured to be executed by one or more processors, the one or more processors execute any one of the methods described above.

[0015] The present application also provides a computer-readable storage medium having computer-readable instructions stored thereon. When the computer-readable instructions are executed by a processor, the processor is caused to execute any one of the methods described above.

[0016] The purpose of this application is to improve the memory utilization rate of embedded devices, especially the optimization of static memory used during compilation. There are some program modules in embedded devices, such as BLE network configuration modules, etc. These modules need to occupy a certain amount of static memory during compilation. However, these modules will no longer be needed after execution, so it is possible to consider how to optimize the allocation of static memory occupied by the segments of these modules. According to the technical solution of this application, the linker allocates the various segments of a specific link module to static memory with continuous physical addresses, and releases this part of static memory to the dynamic memory pool in a timely manner after the link module is used up, which can avoid memory waste. After implementing the technical solution of this application, the embedded device will no longer need to retain the corresponding static memory after executing a specific module, so this part of the memory can be released, which is conducive to reusing this part of the memory and improving the efficiency of memory use. In addition, the application also provides an embedded device and computer-readable medium with the above-mentioned technical advantages. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Hereinafter, the present application will be further explained based on embodiments with reference to the accompanying drawings.

[0018] FIG1 shows a schematic flow chart of compiling source code into a target file and finally loading the target file into a memory in the prior art;

[0019] FIG2 shows a schematic diagram of memory distribution when there are multiple target files in the prior art;

[0020] FIG3 is a schematic diagram showing the division of the physical memory of an embedded device according to the present invention;

[0021] FIG4 is a schematic flow chart showing a method for managing memory allocation of an embedded device according to an embodiment of the present invention;

[0022] FIG5 is a schematic diagram showing memory allocation of a link module according to an embodiment of the present invention;

[0023] FIG6 shows a schematic diagram of memory release of the link module shown in FIG5 according to an embodiment of the present invention;

[0024] FIG7 shows a schematic diagram of memory allocation and release of a link module according to another embodiment of the present invention;

[0025] FIG8 shows a schematic diagram of memory allocation and release of a link module according to yet another embodiment of the present invention;

[0026] FIG9 shows a schematic diagram of a structural block diagram of an embedded device according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] The following will be combined with the accompanying drawings and specific implementation methods to describe the method, device and system of the present application in detail. It should be understood that the embodiments shown in the accompanying drawings and described below are merely illustrative and not intended to limit the present application.

[0028] In embedded systems, such as 32-bit single-chip microcomputers, instructions and data are generally stored in different memories and accessed using different buses. For example, instructions can be stored in instruction memories such as IRAM, IROM, and RTC FAST memory, and data can be stored in data memories such as DRAM and DROM. Instruction memory is executable and can be read or written using, for example, 4-byte aligned words. Data memory is non-executable and can be accessed using separate byte operations. Since instruction memory can only be accessed by the instruction bus and data memory can only be accessed by the data bus, even if instructions and data are stored on a physically continuous piece of memory, the memory needs to be divided into IRAM and DRAM.

[0029] As shown in FIG1 , it shows a schematic flow chart of compiling source code into target files and finally loading the target files into memory in the prior art.

[0030] First, the source code is compiled into a target file. Taking the C language source code as an example, after compilation, the binary code is obtained, which becomes the target file. The target file consists of a series of sections. Common sections include:

[0031] -.text text segment: used to store executable instructions;

[0032] -.data initialized data segment: used to store initialized data;

[0033] -.bss uninitialized data segment: used to store uninitialized data;

[0034] -Other segments: for example, segments that store header file information, segments that store debugging information, etc.

[0035] Furthermore, the linker links one or more target files into an executable file during the linking phase, and completes the organization of the address space of each target file in a program module, i.e., address allocation. The linker assigns a load address to the segments (e.g., instruction segments, data segments, etc.) in each target file. For example, as shown in Figure 1, the linker allocates the .text text segment containing instructions to an instruction memory such as IRAM, with an address of addr1, and allocates the .data segment and .bss segment to a data memory such as DRAM, with addresses of addr2 and addr3, respectively. Since the physical addresses of the memories where these segments are located are usually discontinuous, if the memories where these segments are located are released after the program is executed, more fragments will appear in the memory and cannot be used effectively. It will be understood by those skilled in the art that, generally, a program module includes one or more target files obtained by compiling the source code.

[0036] The following, in conjunction with Figure 2, illustrates a schematic diagram of memory distribution when multiple target files exist in the prior art. As shown in Figure 2, when the linker stores the multiple target files obtained by compilation into the memory, it will piece together the .text segments of each target file and place them in the .text segment storage area (e.g., IRAM) in the memory. Similarly, it will piece together the .data segment and .bss segment of each target file and store them in the .data segment storage area and .bss storage segment, respectively. For example, if the module corresponding to target file 1 is no longer used after running, if you want to release the memory occupied by target file 1, you will release the corresponding parts of the .text segment, .data segment, and .bss segment in the memory. However, since these released memories are physically discontinuous and the memory size is very small, only a few small memory spaces are available after release, which can hardly be used for other purposes, resulting in a waste of space.

[0037] The physical memory of an embedded device refers to the memory units actually present in its hardware, typically consisting of RAM (random access memory). As shown in Figure 3, the physical memory of an embedded device according to an embodiment of the present invention is divided into two categories: static memory and dynamic memory. Static memory is memory allocated during program compilation and includes instruction memory (IRAM) for storing instructions and data memory (DRAM) for storing data. For example, IRAM is used to store the .text instruction segment, while DRAM is used to store the .data initialized data segment and the .bss uninitialized data segment, such as global variables. Data in static memory remains unchanged throughout the program lifecycle, such as global variables, static variables, and constants. Dynamic memory is memory that is allocated and released as needed during program execution, and its size can be adjusted at any time. Dynamic memory is allocatable data memory (DRAM) used to store temporary or mutable data, such as temporary buffers, stacks, and other data that requires dynamic allocation and release. Dynamic memory is typically allocated by functions such as malloc and new, and its lifecycle begins with allocation and ends with release. Those skilled in the art will understand that the larger the dynamic memory, the more functions it can implement. Therefore, in the prior art, memory optimization for embedded devices primarily focuses on dynamic memory, rather than static memory. This is because the size of static memory is fixed during the life cycle of a program and cannot be recycled or reused. In addition, according to the solution of the prior art, such as shown in Figure 2, even if a program is terminated, releasing the static memory it occupied will only form memory fragments, which are difficult to be used by other programs.

[0038] To address the above problems, the present invention provides a method for managing memory allocation in embedded devices. FIG4 is a flow chart illustrating a method for managing memory allocation in embedded devices according to an embodiment of the present invention.

[0039] The method specifically includes the following steps 402 and 404:

[0040] In step 402, a linker places multiple sections of at least one link module in physically contiguous locations in the instruction memory and data memory of the embedded device. Preferably, each of the multiple sections is selected from one or more of the following: a .text section, a .data section, and a .bss section. Preferably, user-defined sections can also be selected from the multiple sections.

[0041] Preferably, the .text section of the plurality of sections is placed in the instruction memory, and the .data section and / or the .bss section of the plurality of sections is placed in the data memory. For example, as shown in FIG3 , the .data section is placed in the .text section of the data memory, and the .bss section is placed in the .bss section of the data memory.

[0042] Preferably, physically consecutive locations of the instruction memory and the data memory in the embedded device can be consecutively addressed by the embedded device.

[0043] Specifically, as shown in Figure 5, a schematic diagram of the memory allocation of a link module according to an embodiment of the present invention is shown. Figure 5 takes program module A as an example, which is a link module that can be released after execution. In some examples, the link module can be a program module for BLE network configuration, which is no longer needed after the embedded device completes network configuration and is not reloaded until the embedded device's chip is reset. Therefore, the link module can be released after running once. The link module includes multiple segments: A.text text segment and A.data and A.bss data segments. One innovation of the present invention is to reorganize the original static memory structure, allocating the A.text text segment to the end of the instruction memory and the A.data and A.bss data segments to the beginning of the data memory. In this way, since the physical locations of the instruction memory and the data memory are continuous, the physical locations of the memory where the three segments in the link module are located are also continuous, facilitating release and management.

[0044] In step 404 , after at least one link module is completed, the at least one link module is released so that the physically continuous locations where the instruction memory and the data memory are located are released to the dynamic memory pool to be used as allocable data memory.

[0045] Preferably, the step of releasing the at least one link module further comprises converting the address of the instruction memory where the .text segment of the at least one link module is located into the address of the data memory corresponding to the same physical location.

[0046] Those skilled in the art will appreciate that the CPU accesses the internal memory of an embedded device via different buses, with the CPU accessing data memory via the data bus or accessing instruction memory via the instruction bus. In some cases, the embedded device may also support the CPU accessing the same memory via the data bus or the instruction bus in the same sequence. For example, the CPU may access the same portion of memory in the same sequence via the instruction bus address segment 0x4038_0000 to 0x403D_FFFF or the data bus address segment 0x3FC8_0000 to 0x3FCD_FFFF. In other words, the instruction bus address 0x4038_0000 and the data bus address 0x3FC8_0000 access the same word, and the instruction memory address and the data memory address have a corresponding relationship. According to an embodiment of the present invention, by converting the address corresponding to the memory storing the instruction segment into the address of the data memory, it is possible to facilitate the subsequent continuous release of the memory where the various segments of the connection module are located to form a larger overall memory space, thereby avoiding excessive memory fragmentation.

[0047] Specifically, as shown in Figure 6, a schematic diagram of the memory release of the link module shown in Figure 5 according to an embodiment of the present invention is shown. First, the memory address where the text segment A.text of the A link module is located is converted into the address of the data memory. Since the physical locations of the memory where the text segment and the data segment are located are continuous, the addresses of the obtained data memory are also continuous. Further, the memory where the three segments of the link module are located is released together into the dynamic memory pool to be used as allocable dynamic memory. Those skilled in the art will understand that after this part of the static memory is released as dynamic memory, this part of the memory can be subsequently allocated and used through functions such as malloc. According to an embodiment of the present invention, the static memory at the continuous addresses occupied by the .text segment, the .data segment and the .bss segment is released into the dynamic memory pool in a merged manner, which helps to reduce the generation of memory fragmentation, thereby improving the efficiency of memory use.

[0048] Preferably, the at least one link module in this embodiment includes one link module. In an alternative embodiment, the at least one link module may also include two or more link modules.

[0049] Further preferably, when there are two or more link modules, the two or more link modules are released simultaneously. In an alternative embodiment, the two or more link modules are released in batches.

[0050] Referring to FIG7 , a schematic diagram of memory allocation and release of link modules according to another embodiment of the present invention is shown. As shown in FIG7 (1), the embedded device includes two link modules A and B that can be released after running, wherein the link module A includes multiple segments: A.text text segment and A.data and A.bss data segments, and the link module B includes multiple segments: B.text text segment and B.data and B.bss data segments. According to an embodiment of the present invention, as shown in FIG7 , the A.text and B.text text segments are allocated to the end of the instruction memory, and the B.data, B.bss, A.data, and A.bss data segments are allocated to the beginning of the data memory in any order. In this way, since the physical locations of the corresponding instruction memory and data memory are continuous, the physical locations of the memory where all segments of the two link modules A and B are located are also continuous, which is convenient for release and management. In the embodiment shown in FIG7 , when the two link modules have been running and are no longer used, the static memory of the two link modules can be released in batches. First, as shown in FIG7 (2), the memory address of the text segment B.text of the B link module is converted to the address of the data memory. Since the physical locations of the memory where the text segment and the data segment are located are continuous, the addresses of the obtained data memory are also continuous. Furthermore, the memory where the three segments of the B link module are located is released together to the dynamic memory pool to be used as allocable dynamic memory. Similarly, as shown in FIG7 (3), the static memory where all segments of the A link module are located is released to the dynamic memory pool. Those skilled in the art will understand that after releasing this part of the static memory into dynamic memory, this part of the memory can be subsequently allocated and used through functions such as malloc.

[0051] Referring to FIG8 , a schematic diagram of memory allocation and release of link modules according to another embodiment of the present invention is shown. As shown in FIG8 (1), the embedded device includes two link modules A and B that can be released after running, wherein the link module A includes multiple segments: A.text text segment and A.data and A.bss data segments, and the link module B includes multiple segments: B.text text segment and B.data and B.bss data segments. According to an embodiment of the present invention, as shown in FIG8 , the A.text and B.text text segments are allocated to the end of the instruction memory, and the B.data, B.bss, A.data, and A.bss data segments are allocated to the beginning of the data memory. In this way, since the physical locations of the corresponding instruction memory and data memory are continuous, the physical locations of the memory where all segments of the two link modules A and B are located are also continuous, which is convenient for release and management. In the embodiment shown in FIG8 , when the two link modules have been running and are no longer used, the static memory occupied by the two link modules can be released at the same time. As shown in FIG8 (2), the memory address of the text segment A.text of the A link module and the memory address of the text segment B.text of the B link module are converted into data memory addresses. Since the physical locations of the memory where all segments in A and B are located are continuous, the addresses of the obtained data memory are also continuous. Furthermore, the memory where all segments of the A and B link modules are located is released together into the dynamic memory pool to be used as allocable dynamic memory. It will be understood by those skilled in the art that after releasing this part of static memory into dynamic memory, this part of memory can be subsequently allocated and used through functions such as malloc. In addition, it should be understood that, under the premise that the physical locations of the memory where each segment is located after aggregation are continuous, the order of the segments shown in FIG8 is variable. For example, the order of B.text and A.text can be allocated to the instruction memory, or the B.data, B.bss, A.data, and A.bss segments can be allocated to the data memory in any order.

[0052] The present invention aims to optimize the memory management of special modules, particularly the static memory used during compilation. Some special modules in embedded devices have their required static memory space determined during compilation. For example, the .text segment is allocated in the instruction memory, and the .data and .bss segments are allocated in the data memory. However, these special modules are no longer needed after use, so it is necessary to consider how to release the static memory used by these special modules during compilation. According to the above-mentioned embodiments of the present invention, the linker places the segments in the link module in a physically contiguous memory area, and after the link module is used, it is released as a whole and recycled into the dynamic memory pool. Taking Espressif's ESP32-C2 microcontroller as an example, its physical memory space is only 256KB, and the static memory of the BLE network configuration module (including the .text segment, .data segment, and .bss segment) occupies 20KB, leaving very limited space for dynamic memory during runtime. After implementing the technical solution of the present invention, the embedded device will no longer need to retain the BLE network configuration module after completing the BLE network configuration, so the static memory occupied by the module can be released, thereby increasing 20KB of available dynamic memory, which is conducive to improving memory usage efficiency.

[0053] In addition, the present application also provides an embedded device, as shown in the structural block diagram of the embedded device according to an embodiment of the present application in Figure 9, the embedded device specifically includes: one or more processors 902, a volatile memory 904 and a non-volatile memory 906, wherein the non-volatile memory stores computer-readable instructions, and when the computer-readable instructions are configured to be executed by one or more processors, the one or more processors execute the method for managing memory allocation of an embedded device as described in any embodiment of this document.

[0054] It is understandable that the process of executing memory allocation by the embedded device corresponds to the above-mentioned method for managing memory allocation applied to the embedded device, and reference may be made to the above-mentioned content, which will not be repeated here.

[0055] In addition, the present application also provides a computer-readable storage medium having computer-readable instructions stored thereon. When the computer-readable instructions are executed by a processor, the processor executes the method for managing memory allocation of an embedded device as described in any embodiment of the present invention.

[0056] It can be understood that the process of executing memory allocation by the computer-readable storage medium corresponds to the above-mentioned method for managing memory allocation applied to embedded devices, and reference can be made to the above content, which will not be repeated here.

[0057] The technical solution of the present invention can effectively optimize memory allocation and release in embedded devices, particularly single-chip microcomputers. The solution of the present application solves the problem of static memory occupied during compilation remaining occupied throughout the life cycle of the embedded device. It can promptly release the static memory corresponding to some no longer needed special modules to the dynamic memory pool, thereby improving memory utilization.

[0058] Although various embodiments of various aspects of the present application have been described for the purposes of this disclosure, it should not be understood that the teachings of this disclosure are limited to these embodiments. Features disclosed in a specific embodiment are not limited to that embodiment, but can be combined with features disclosed in different embodiments. For example, one or more features and / or operations of the method according to the present application described in one embodiment may also be applied individually, in combination or as a whole in another embodiment. It should be understood by those skilled in the art that there are possible more optional implementations and variations, and various changes and modifications may be made to the above-mentioned system without departing from the scope defined by the claims of this application.

Claims

1. A method for managing memory allocation of an embedded device, characterized in that, Comprising: Placing, by a linker, multiple sections of at least one linked module at physically contiguous positions in the instruction memory and data memory of the embedded device; And After the at least one linked module finishes running, releasing the at least one linked module so that the physically contiguous positions in the instruction memory and data memory are released into a dynamic memory pool for use as allocatable data memory.

2. The method according to claim 1, wherein Each of the multiple sections is selected from one or more of a.text section,.data section, and.bss section.

3. The method according to claim 2, wherein The step of placing multiple sections of at least one linked module at physically contiguous positions in the instruction memory and data memory includes placing the.text section among the multiple sections in the instruction memory and placing the.data section and / or.bss section among the multiple sections in the data memory.

4. The method according to claim 1, characterized in that The physically contiguous positions in the instruction memory and data memory can be continuously addressed by the embedded device.

5. The method according to claim 4, wherein The step of releasing the at least one linked module further includes converting the address of the instruction memory where the.text section of the at least one linked module is located into the address of the corresponding data memory.

6. The method according to claim 1, wherein The at least one linked module includes one linked module.

7. The method according to claim 1, wherein The at least one linked module includes two or more linked modules.

8. The method according to claim 7, characterized in that, The step of releasing the at least one linked module includes releasing the two or more linked modules simultaneously.

9. The method according to claim 7, wherein The step of releasing the at least one linked module includes releasing the two or more linked modules in batches.

10. An embedded device includes one or more processors, volatile memory, and non-volatile memory, and computer-readable instructions are stored in the non-volatile memory, wherein, The computer-readable instructions are configured to cause the one or more processors to execute the method according to any one of claims 1-9 when executed by the one or more processors.

11. A computer-readable storage medium having computer-readable instructions stored thereon, characterized in that, When the computer-readable instructions are executed by a processor, causing the processor to execute the method according to any one of claims 1-9.

Images