A memory management method and device in an electric energy meter

Abstract

The application provides a memory management method and device in an electric energy meter, and relates to the technical field of electric energy meters.A memory application record table is constructed as a unique management hub, a record set to be released is accurately determined by executing a program to query the record table, the integrity of the release target is ensured, and memory omission release is avoided.According to the memory data model type in the record, a preset release program is associated, the release logic is strictly matched with the data structure, and logical errors introduced by manual writing are eliminated.The release program is used to automatically release the memory from the inside to the outside according to the nesting level, the order problem of the memory release of complex nested objects is solved, memory leakage or access exceptions are prevented, and finally, the corresponding entries of the record table are deleted after the release, the consistency between the record table and the physical memory state is maintained in real time, the problem that the memory of the electric energy meter is prone to leakage is solved, the effective release of the memory of the electric energy meter is realized, and the reliability of the electric energy meter operation is improved.

Description

Technical Field

[0001] This invention relates to the field of electricity meter technology, and in particular to an electricity meter memory management method and device. Background Technology

[0002] As a critical metering device, the core control unit of an electricity meter is typically implemented using an embedded microcontroller. The internal memory resources of such microcontrollers, especially RAM (Random Access Memory), are extremely limited. RAM is responsible for storing data generated during program execution, such as global variables, static variables, and data dynamically allocated via the heap. To efficiently handle tasks with variable or unpredictable data volumes within limited memory, developers often employ dynamic memory allocation techniques. This technique allows programs to request memory blocks of a specific size as needed during runtime and release them (free) after use, thereby achieving memory block reuse and avoiding resource waste or insufficiency caused by statically allocated fixed-size memory.

[0003] However, while dynamic memory management brings flexibility, it also introduces significant complexity and risks, which is particularly prominent in embedded systems such as electricity meters that have extremely high requirements for long-term operational stability.

[0004] On the one hand, memory release logic is complex and error-prone. In complex software functional modules, data objects often have multiple levels of nesting. For example, a functional module's data structure (parent object) may contain pointers to other substructures or strings (child objects), which also require dynamic memory allocation. When releasing such nested objects, a strict "inside-out" order must be followed: first release the memory occupied by all child objects, and only then can the parent object itself be released. If the release order is incorrect, or if the release of a certain level of child objects is missed, it will directly lead to a memory leak. Because memory leaks may not cause obvious program crashes in the short term, but rather manifest as a slow depletion of memory, this problem is insidious and difficult to fully detect during the testing phase. Ultimately, it can cause unpredictable failures after the equipment has been running for a long time, affecting the reliable metering and functional execution of the electricity meter.

[0005] On the other hand, the timing of memory release is difficult to fully control and prone to omissions. Program execution paths are not always linear. In a normal flow, developers can schedule memory release operations at function or module exit points. However, when the program enters an exception handling branch and exits prematurely due to unmet input conditions, external interference, or internal errors, memory allocated before the exception point is easily forgotten to be released. This type of memory leak caused by abnormal paths is a common flaw in traditional manual memory management.

[0006] Currently, users mainly rely on coding standards, code review, and debugging tools to avoid the above problems. However, this method is highly dependent on the user's personal experience and attention to detail, and cannot fundamentally guarantee the absolute correctness of memory operations. Especially when the code size increases, the nesting relationships become more complex, and multiple people collaborate on development, its uncertainty and risks increase significantly. Summary of the Invention

[0007] This invention provides a method and device for managing the memory of an electricity meter, which solves the problem of easy leakage of the memory in the electricity meter, realizes the effective release of the memory in the electricity meter, and improves the reliability of the electricity meter operation.

[0008] In a first aspect, the present invention provides a method for managing the memory of an electricity meter. The method includes: when the execution program of the electricity meter determines that memory needs to be released, querying a preset memory request record table based on the execution program, retrieving and determining a set of memory records to be released related to the execution program; for each record in the set of memory records to be released, associating and determining a memory release program for each record according to the memory data model type of each record; releasing the memory corresponding to each record sequentially according to the nesting hierarchy from the inside out based on the memory release program of each record; if the memory corresponding to a record is successfully released, deleting that record from the memory request record table.

[0009] Secondly, the present invention provides a memory management device for an electricity meter, comprising: a communication module for detecting whether the execution program of the electricity meter needs to release memory; and a processing module for, when the execution program of the electricity meter determines that memory needs to be released, querying a preset memory request record table based on the execution program, retrieving and determining a set of memory records to be released related to the execution program; for each record in the set of memory records to be released, associating and determining the memory release program for each record according to the memory data model type of each record; releasing the memory corresponding to each record sequentially according to the memory release program of each record in a nested order from the inside out; and deleting the record in the memory request record table if the memory corresponding to a record is successfully released.

[0010] Thirdly, embodiments of the present invention provide an electronic device including a memory and a processor. The memory stores a computer program, and the processor is configured to call and run the computer program stored in the memory to perform the steps of the method as described in the first aspect and any possible implementation thereof.

[0011] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps of the method as described in the first aspect and any possible implementation thereof.

[0012] This invention provides a method and device for managing the memory of an electricity meter. The invention constructs a memory request record table as the sole management center. By executing a program to query the record table, it accurately determines the set of memory records to be released, ensuring the integrity of the release targets and avoiding missed memory releases. Then, based on the memory data model type explicitly stated in the records, a pre-set release program is associated, ensuring a strict match between the release logic and the data structure, eliminating logical errors introduced by manual programming. Next, the release program automatically releases memory in a nested order from the inside out, solving the problem of the order of memory release for complex nested objects and preventing memory leaks or access anomalies. Finally, after release, the corresponding entry in the record table is synchronously deleted, maintaining the consistency between the record table and the physical memory state in real time. This solves the problem of memory leaks in electricity meters, achieves effective memory release, improves the reliability of electricity meter operation, significantly enhances the determinism and reliability of memory operations, and reduces the operational risks of embedded electricity meters caused by memory leaks. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart illustrating a method for managing the memory of an electricity meter according to an embodiment of the present invention;

[0015] Figure 2 This is a schematic diagram provided by an embodiment of the present invention;

[0016] Figure 3 This is a schematic diagram provided by an embodiment of the present invention;

[0017] Figure 4 This is a schematic diagram of the structure of an energy meter memory management device provided in an embodiment of the present invention;

[0018] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of the invention. However, those skilled in the art will understand that the invention can be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of the invention with unnecessary detail.

[0020] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.

[0021] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not limited to the steps or modules listed, but may optionally include other steps or modules not listed, or may optionally include other steps or modules inherent to such process, method, product, or device.

[0022] To make the objectives, technical solutions, and advantages of the present invention clearer, the following description will be provided in conjunction with the accompanying drawings and specific embodiments.

[0023] like Figure 1 As shown, this embodiment of the invention provides a method for managing the memory of an electricity meter. The method includes steps S101-S104.

[0024] S101. When the execution program of the electricity meter determines that memory needs to be released, the preset memory request record table is queried based on the execution program, and the set of memory records to be released related to the execution program is retrieved and determined.

[0025] As one possible implementation, step S101 can be specifically implemented as steps S1011-S1015.

[0026] S1011. Determine the current memory release trigger type based on the current execution state of the executor.

[0027] In some embodiments, the memory release trigger types include: function exit, completion of function module execution, or system restart.

[0028] S1012. Based on the current memory release trigger type, the target record corresponding to the executor is determined in the memory request record table through the association module.

[0029] S1013. Determine whether the target record is a nested data type.

[0030] S1014. If the target record is a nested data type, then identify multiple subordinate records that have a parent-child or subordinate relationship with the nested data model of the target record.

[0031] S1015. Determine the set of memory records to be released by taking the target record and multiple subordinate records.

[0032] As another possible implementation, step S101 can be specifically implemented as steps A1-A4.

[0033] A1. When the memory release trigger type is function exit, the temporary memory record belonging to the currently exiting function is determined through the associated module in the memory allocation record table.

[0034] A2. When the memory release trigger type is "when the function module has finished executing", query the records at the function module level and determine the memory data model associated with the executed function module based on the associated modules.

[0035] A3. When the memory release trigger type is system restart, filter records with a lifecycle level of system level.

[0036] A4. When the memory release trigger type is program abnormal exit, filter the memory allocation records related to the program that triggered the exception.

[0037] For example, memory release can be divided into the following cases:

[0038] Temporary cache-level memory release: This type of memory is used within the function that allocates it. Therefore, the memory release function of the corresponding data model can be called to release it uniformly when the function exits, which can avoid programming problems caused by disordered release order.

[0039] Functional module-level memory release: When a module program that performs a specific function finishes execution and exits, it calls the memory release program of the corresponding data model to release the memory uniformly.

[0040] System-level memory release, released upon system restart.

[0041] In abnormal memory handling situations, if the allocated memory fails to meet certain requirements due to some members not meeting specific conditions, or if the program cannot continue execution due to not meeting certain conditions and needs to exit abnormally, there may be cases where the allocated memory has not been released. In such cases, a specific type of memory release procedure should be called to release the memory.

[0042] The program malfunctions and memory is released as shown in the following example.

[0043] Functional module 1()

[0044] {

[0045] Allocate memory for TEST_OBJECT_MODULE; ...

[0046] Allocate memory for TEST_OBJECT_MODULE->TEST_OBJECT_ARRAY->Array;

[0047] The program's execution conditions are not met.

[0048] TEST_OBJECT_MODULE Model Release Process();

[0049] Exit this function module;

[0050] } ...

[0051] Apply for TEST_OBJECT_MODULE->TEST_OBJECT_TYPEX->TEST_OBJECT_

[0052] STRUCT memory; ...

[0053] / / This function module releases the allocated memory after execution.

[0054] TEST_OBJECT_MODULE Model Release Process();

[0055] }

[0056] S102. For each record in the set of records to be released, based on the memory data model type of each record, associate and determine the memory release procedure for each record;

[0057] As one possible implementation, embodiments of the present invention can determine the memory release procedure for each record by querying a pre-set type-program mapping table based on the memory data model type of each record.

[0058] S103. The memory release procedure based on each record releases the memory corresponding to each record in sequence from the inside to the outside of the nesting hierarchy.

[0059] As one possible implementation, step S103 can be specifically implemented as steps one through six.

[0060] Step 1: Receive the target to be released, which is a memory allocation record or a nested data model member.

[0061] Step 2: Parse the memory data model corresponding to the target to be released, and determine the data type of the first member of the target to be released.

[0062] Step 3: If the data type of the member is a nested type, then the member is designated as the target to be released, and steps 1 to 4 are repeated.

[0063] Step 4: If the data type of the member is a non-nested type, then directly release the memory block pointed to by the member.

[0064] Step 5: Analyze the next member of the current model. Repeat steps 3 to 5 until all members of the current model have been processed.

[0065] Step 6: Release the memory blocks currently occupied by the model itself.

[0066] like Figure 2 As shown, this embodiment of the invention provides an example of releasing a memory allocation record table. Memory is released uniformly upon exiting after the functional module has finished executing.

[0067] S104. If the memory corresponding to a record is successfully released, then delete that record from the memory request record table.

[0068] As one possible implementation, embodiments of the present invention can immediately search for and delete the corresponding record entry in the memory allocation record table after each memory block pointed to by a memory allocation record or corresponding to a nested member is released, using the starting address of the memory block as the search key.

[0069] For example, the present invention also includes a memory check task, which periodically checks the memory request record table, searches according to the memory lifecycle type to see if there is any temporary memory type, and if so, calls the specific type of memory release process to release it.

[0070] For example, the present invention can also periodically check each record in the memory request record table to determine whether there are any records of missed release or abnormal release. If so, the release procedure is repeated to ensure that the memory of the electricity meter is effectively released.

[0071] This invention provides a memory management method for electricity meters. It constructs a memory allocation record table as the sole management center, and executes a program to query the record table to accurately determine the set of memory records to be released, ensuring the integrity of the release targets and avoiding missed memory releases. Then, based on the memory data model type explicitly stated in the records, a pre-defined release program is associated, ensuring a strict match between the release logic and the data structure, eliminating logical errors introduced by manual coding. Next, the release program automatically releases memory in a nested order from the inside out, solving the problem of sequential memory release for complex nested objects and preventing memory leaks or access anomalies. Finally, after release, the corresponding entry in the record table is synchronously deleted, maintaining real-time consistency between the record table and the physical memory state. This solves the problem of memory leaks in electricity meters, achieves effective memory release, improves the reliability of electricity meter operation, significantly enhances the determinism and reliability of memory operations, and reduces the operational risks of embedded electricity meters caused by memory leaks.

[0072] Furthermore, this invention predefines specific data models according to functional requirements and requests memory for specific memory models according to functional modules. Memory usage is cohesive and unique, making the memory usage logic clear, avoiding the disorder of distributed memory allocation and release, and improving the reliability of program coding; at the same time, the checking mechanism during memory allocation enhances the security of memory usage.

[0073] When each application module terminates or exits abnormally, memory is released uniformly. The memory release time is clear and without omission. When releasing memory, the memory release process associated with the corresponding data model is called automatically, avoiding uncontrollable errors such as randomness in the timing of memory release, missed release, and duplicate release.

[0074] By using a memory allocation log table and a timed memory check mechanism to monitor memory usage, memory loss caused by code design flaws and runtime anomalies can be detected and avoided in a timely manner.

[0075] This invention effectively avoids memory leaks during electricity meter operation, providing a robust memory management mechanism for stable operation. It also prevents prolonged memory occupation, effectively reducing memory overhead and ensuring sufficient memory for stable electricity meter operation, thus significantly reducing reliance on large memory capacities.

[0076] Optionally, prior to step S101, this embodiment of the invention may create and initialize a memory request record table when the electricity meter is started. Each record in the memory request record table is used to store key information of a successful memory request. The key information includes: memory lifecycle level, memory data model type, memory starting address, memory length, and associated module; wherein, the memory lifecycle level includes system level, functional module level, and temporary cache level.

[0077] For example, this invention can establish a memory data model before program execution: memory data models are established for various data types and structures that require memory from the electricity meter, and a unique memory model for each functional module is constructed by nesting them according to functional modules. Members within the data model are defined by data type as needed, defining members that require memory as pointers of a specified type, allowing for multi-level nesting based on data type characteristics.

[0078] For example, in the memory data model, member 1 is a pointer to a structure of type A. The structure of type A can contain string pointers B and pointers to structures of type C. An example is attached. Figure 3 As shown.

[0079] After the power meter starts up (completing MCU core configurations such as clock configuration), a memory allocation record table is built first, containing the following information:

[0080] 1) The lifecycle level of newly allocated memory; based on the application to which the allocated memory belongs, it can be divided into:

[0081] System-level type: Requested by the system or task management module, with a fixed memory size and a determinable start and end address range sys_range, and released when the system stops running;

[0082] Functional module level type: Memory is allocated by each functional module program, and the size is variable, changing according to the amount of data being processed. If the allocated memory is insufficient, more can be allocated. Memory is released uniformly when the module program finishes execution.

[0083] Temporary cache level: Temporary memory required during program processing, which should be released immediately after use.

[0084] 2) The newly allocated memory type, i.e., the memory data model.

[0085] 3) The starting address of the newly allocated memory;

[0086] 4) The length of the newly allocated memory;

[0087] 5) Other extended information.

[0088] Table 1 shows an example of a memory allocation record table provided in this embodiment of the invention. The memory allocation record table is created immediately after the electricity meter is started and recorded as a system-level type to ensure that it cannot be illegally modified. The capacity can be determined based on the maximum number of memory allocations made by the application during runtime, and sufficient capacity is reserved.

[0089] Table 1 Memory Request Record Table

[0090]

[0091] The nested memory model constructed by the Func1 functional module (which already contains all the type definitions for the memory required by the module) has a corresponding address that serves as the sole entry point for allocating / dealing memory for that functional module. When freeing memory, the address is first retrieved from the memory record table, and the release procedure associated with the memory model is called.

[0092] Thus, this invention provides a global and accurate management ledger for dynamic memory by creating a structured memory allocation record table during system startup. This table comprehensively records key information such as the lifecycle level, data model type, address, and length of each memory allocation, enabling visualization and traceability of memory resources. This allows all subsequent memory management operations to be based on accurate and unified metadata, laying a reliable data foundation for precise release based on type matching and prevention of omissions, thereby improving the systematic nature and controllability of memory management from the source.

[0093] Optionally, the electricity meter memory management method provided in this embodiment of the invention further includes steps S201-S202 before step S101.

[0094] S201. Based on the type identifiers of various memory data models and the pre-built memory release functions, a unique association is established to create a type-program mapping table.

[0095] S202. Construct the recursive release logic of the memory release function to obtain the memory release program.

[0096] For example, the recursive release logic includes step ad:

[0097] a. Get the data type of the first member of the memory data model currently awaiting release.

[0098] b. Determine the data type of the member. If it is a nested memory data model type, then treat the member as a new target to be released and recursively execute step a; if it is a non-nested type, then directly release the memory pointed to by the member.

[0099] c. Obtain the next member of the memory data model to be released, and repeat step b until all members of the current model have been processed.

[0100] d. Release the memory occupied by the currently pending memory data model itself.

[0101] For example, embodiments of the present invention can construct memory release procedures for all data models based on the established data model and the nested relationships of defined data types, for use in performing a comprehensive memory release call when a specified data model is no longer in use. The construction steps are as follows:

[0102] S2021. Associate the data model type identifier with the release function. For example, functional module 1 can only call release program 1.

[0103] S2022. The release procedure first obtains the first member of the data model to be released, and then determines whether it is a nested data type based on the data type.

[0104] S2023, Non-nested data types execute step S2024, Nested data types execute step S2025.

[0105] S2024. For non-nested data types, execute the release of the specified memory address, retrieve the memory address from the memory record table, and delete the memory allocation record.

[0106] S2025, Nested data type execution steps S2022.

[0107] S2026. All members in the current nested data type have been released. Release the memory of the current nested data type, retrieve the memory address in the memory record table, delete the memory allocation record, and proceed to step S2028.

[0108] S2027. Obtain the next member type in the current nested data type, determine whether it is a nested data type, and execute step S2023.

[0109] S2028. Exit after all members have been released; otherwise, return to the upper-level data type and execute step S2027.

[0110] Thus, embodiments of the present invention can transform memory release operations from runtime decisions into a predefined automated process by pre-establishing type-program mapping relationships and constructing recursive release logic. This ensures a strict match between the release logic and the data model structure, making the release order of nested memory built into the program, completely avoiding sequence errors or logical inconsistencies caused by human coding oversights, and significantly improving the reliability and automation of complex object memory release.

[0111] Optionally, the electricity meter memory management method provided in this embodiment of the invention further includes steps S301-S308 before step S101.

[0112] S301. Obtain the memory requirement of the currently executing program.

[0113] S302. Query the memory request record table and calculate the total length of allocated memory for each record in the memory request record table.

[0114] S303. Determine whether the sum of the total length of the allocated memory and the length of the required memory exceeds the system's preset memory capacity threshold.

[0115] S304. If the limit is exceeded, terminate the current memory request and return an error message; if the limit is not exceeded, request a contiguous memory space of the required size from the system.

[0116] S305. If the allocation of contiguous memory space is successful, verify whether the starting address of the contiguous memory space is valid.

[0117] S306. If the address is valid, determine the memory data model type and memory lifecycle level corresponding to this memory request based on the current program's functional modules and data structures.

[0118] S307. Generate a new memory allocation record based on the memory lifecycle level, memory data model type, starting address of contiguous memory space, and memory length.

[0119] S308. Add the new memory request record to the memory request record table.

[0120] For example, memory allocation involves requesting memory of a specified type during program execution by following these steps.

[0121] 1) Before requesting memory, check whether the sum of the length accumulation value in the memory record table and the length of the memory to be requested exceeds the set memory length. If it does, exit and report an error.

[0122] 2) Call the memory allocation function to request memory of a specified length. If the allocation is successful, continue execution; if the allocation fails, exit and report an error.

[0123] 3) Check if the allocated memory address is valid. The memory address allocated for functional module level and temporary cache level cannot be within the system and type address range sys_range. If it is invalid, exit and report an error.

[0124] 4) Temporary cache level memory is only used within the function that requests the memory and cannot be used for cross-function calls via memory address.

[0125] 5) Record the allocated memory in the memory allocation record table, and initialize the allocated memory before using it.

[0126] Thus, this invention, through a standardized application process, performs capacity checks and address verification before memory allocation, preventing memory overflow and unauthorized access risks at the source. Simultaneously, complete application records provide a data foundation for subsequent precise lifecycle-based management, achieving controllability and traceability of the memory application process.

[0127] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0128] The following are device embodiments of the present invention. For details not described in detail, please refer to the corresponding method embodiments described above.

[0129] Figure 4 A schematic diagram of a memory management device for an electricity meter according to an embodiment of the present invention is shown. The device 400 includes a communication module 401 and a processing module 402.

[0130] The communication module 401 is used to detect whether the execution program of the electricity meter needs to release memory.

[0131] The processing module 402 is configured to, when the execution program of the electricity meter determines that memory needs to be released, query a preset memory request record table based on the execution program, retrieve and determine the set of memory records to be released related to the execution program; for each record in the set of memory records to be released, associate and determine the memory release program for each record according to the memory data model type of each record; based on the memory release program of each record, release the memory corresponding to each record in sequence from the inside to the outside of the nesting hierarchy; if the memory corresponding to a record is successfully released, delete the record in the memory request record table.

[0132] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device 500 includes: a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501. When the processor 501 executes the computer program 503, it implements the steps in the above-described method embodiments. Alternatively, when the processor 501 executes the computer program 503, it implements the functions of each module / unit in the above-described device embodiments.

[0133] For example, the computer program 503 may be divided into one or more modules / units, which are stored in the memory 502 and executed by the processor 501 to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 503 in the electronic device 500.

[0134] The processor 501 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0135] The memory 502 can be an internal storage unit of the electronic device 500, such as a hard disk or memory of the electronic device 500. The memory 502 can also be an external storage device of the electronic device 500, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the electronic device 500. Furthermore, the memory 502 can include both internal and external storage units of the electronic device 500. The memory 502 is used to store the computer program and other programs and data required by the terminal. The memory 502 can also be used to temporarily store data that has been output or will be output.

[0136] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for managing the memory of an electricity meter, characterized in that, include: When the execution program of the electricity meter determines that memory needs to be released, it queries a preset memory request record table based on the execution program, retrieves and determines the set of memory records to be released related to the execution program. For each record in the set of records to be released, the memory release procedure for each record is associated and determined based on the memory data model type of each record; The memory release procedure based on each record releases the memory corresponding to each record sequentially from the inside out according to the nesting hierarchy, including: Step 1: Receive the target to be released, which is a memory request record or a nested data model member; Step 2: Parse the memory data model corresponding to the target to be released and determine the data type of the first member of the target to be released; Step 3: If the data type of the member is a nested type, then the member is used as the target to be released, and Steps 1 to 4 are repeated; Step 4: If the data type of the member is a non-nested type, then the memory block pointed to by the member is released directly; Step 5: Parse the next member of the current model and repeat Steps 3 to 5 until all members of the current model have been processed; Step 6: Release the memory block occupied by the current model itself. If the memory corresponding to a record is successfully released, then that record is deleted from the memory allocation record table; Before the step of querying a preset memory request record table and retrieving and determining the set of memory records to be released related to the execution program when the execution program determines that memory needs to be released, the method further includes: creating and initializing a memory request record table when the energy meter starts up. Each record in the memory request record table is used to store key information of a successful memory request. The key information includes: memory lifecycle level, memory data model type, memory starting address, and memory length. The memory lifecycle level includes system level, functional module level, and temporary cache level. Before the execution program of the electricity meter determines that memory needs to be released, and queries a preset memory request record table based on the execution program to retrieve and determine the set of memory records to be released related to the execution program, the process further includes: establishing a type-program mapping table based on the type identifiers of various memory data models and pre-built memory release functions; constructing the recursive release logic of the memory release function to obtain the memory release program; the recursive release logic includes steps a and b: a. obtaining the data type of the first member of the memory data model to be released; b. determining the data type of the member; if it is a nested memory data model type, then the member is used as a new target to be released, and step a is executed recursively; if it is a non-nested type, then the memory pointed to by the member is released directly; c. obtaining the next member of the memory data model to be released, repeating step b, until all members of the current model have been processed; d. releasing the memory occupied by the memory data model to be released itself.

2. The electricity meter memory management method according to claim 1, characterized in that, Before the step of querying a preset memory request record table and retrieving and determining the set of memory records to be released related to the execution program when the execution program determines that memory needs to be released, the method further includes: Get the memory requirement of the currently executing program; Query the memory allocation record table and calculate the total length of allocated memory for each record in the memory allocation record table; Determine whether the sum of the total length of allocated memory and the length of memory requirement exceeds the system's preset memory capacity threshold; If the memory limit is exceeded, the current memory request will be terminated and an error message will be returned; if the limit is not exceeded, a contiguous memory space of the required size will be requested from the system. If the allocation of contiguous memory space is successful, then verify whether the starting address of the contiguous memory space is valid; If the address is valid, the memory data model type and memory lifecycle level corresponding to this memory request will be determined based on the current program's functional modules and data structures. A new memory allocation record is generated based on the memory lifecycle level, memory data model type, starting address of contiguous memory space, and memory length. Add the new memory request record to the memory request record table.

3. The electricity meter memory management method according to claim 1, characterized in that, When the execution program of the electricity meter determines that memory needs to be released, it queries a preset memory request record table based on the execution program, retrieves and determines a set of memory records to be released related to the execution program, including: The current memory release trigger type is determined based on the current execution state of the executor; the memory release trigger type includes: function exit, functional module completion, or system restart; Based on the current memory release trigger type, the target record corresponding to the executing program is determined in the memory allocation record table through the association module; Determine whether the target record is a nested data type; If the target record is a nested data type, then identify multiple subordinate records that have a parent-child or subordinate relationship with the nested data model of the target record; The target record and multiple subordinate records are used to determine the set of memory records to be released.

4. The electricity meter memory management method according to claim 3, characterized in that, When the execution program of the electricity meter determines that memory needs to be released, it queries a preset memory request record table based on the execution program, retrieves and determines the set of memory records to be released related to the execution program, and further includes: When the memory release trigger type is function exit, the temporary memory record belonging to the currently exiting function is determined through the associated module in the memory allocation record table; When the memory release trigger type is "when the function module has finished executing", query the records at the function module level and determine the memory data model associated with the executed function module based on the associated modules. When the memory release trigger type is system restart, filter records with a lifecycle level of system level; When the memory release trigger type is program abnormal exit, filter the memory allocation records related to the program that triggered the exception.

5. The electricity meter memory management method according to claim 1, characterized in that, For each record in the set of memory records to be released, the memory release procedure for each record is associated and determined based on the memory data model type of each record, including: Based on the memory data model type of each record, query the pre-defined type-program mapping table to determine the memory release procedure for each record.

6. The electricity meter memory management method according to claim 1, characterized in that, If the memory corresponding to a record is successfully released, then that record is deleted from the memory allocation record table, including: After each memory block pointed to by a memory allocation record or corresponding to a nested member is released, the corresponding record entry is immediately searched and deleted from the memory allocation record table using the starting address of the memory block as the search key.

7. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor being used to invoke and run the computer program stored in the memory to perform the method as described in any one of claims 1 to 6.

Images