Data storage method and device, micro control unit and storage medium

Abstract

This application relates to the field of automotive electronics technology, specifically to a data storage method, apparatus, microcontroller unit, and storage medium. The data storage method is applied to a microcontroller unit, which includes a first processing core, a second processing core, and a shared storage area connected to both cores. The first processing core runs application software components, and the second processing core runs a non-volatile memory driver module. The method includes: when the application software component needs to write data, it modifies a target flag bit in the shared storage area; a storage management middleware monitors whether the target flag bit has changed; when the target flag bit changes, the storage management middleware obtains the target data to be written from the application software component and calls the non-volatile memory driver module to write the target data to the non-volatile memory. This application can reduce the CPU load during data storage.

Description

Technical Field

[0001] This application relates to the field of automotive electronics technology, specifically to a data storage method, device, microcontroller unit, and storage medium. Background Technology

[0002] With the development of software-defined vehicles, the functions of in-vehicle microcontroller units (MCUs) are becoming increasingly complex, and multi-core architecture has become the mainstream.

[0003] The vehicle-mounted microcontroller unit is equipped with application software components and a non-volatile memory driver module. The application software components typically call the non-volatile memory driver module (i.e., the NVM driver module) periodically to periodically store data to be written to the non-volatile memory (NVM).

[0004] However, in multi-core MCUs, application software components and NVM driver modules often run on different processing cores. In this situation, when the software application needs to store data, it needs to call the NVM driver interface across cores. This leads to frequent inter-core communication and data copying, significantly increasing the CPU load. Summary of the Invention

[0005] In view of the above, embodiments of this application provide a data storage method, apparatus, microcontroller unit, and storage medium to reduce CPU load during data storage.

[0006] In a first aspect, embodiments of this application provide a data storage method applied to a microcontroller unit. The microcontroller unit includes at least a first processing core and a second processing core. The first processing core runs application software components, and the second processing core runs a non-volatile memory driver module. The microcontroller unit also includes a shared storage area connected to the first processing core and the second processing core. The data storage method includes: When the application software component needs to write data, it modifies the target flag bit in the shared storage area. The target flag is monitored for changes using a pre-defined storage management middleware. When the target flag changes, the target data to be written is obtained from the application software component through the storage management middleware. The storage management middleware calls the non-volatile storage driver module to write the target data into the non-volatile memory.

[0007] In this embodiment, a target flag is configured in the shared storage area. By changing the target flag, the application software component can write data without directly calling the NVM driver across cores. The storage management middleware writes data according to the change of the target flag, avoiding periodic data writing and effectively filtering invalid data in the intermediate process. This can significantly reduce the number of writes to the NVM, thereby protecting the lifespan of the NVM and reducing CPU load.

[0008] In some embodiments, modifying the target flag bit in the shared storage area via the application software component includes: If the target flag bit has not reached the maximum value, the target flag bit in the shared storage area is incremented by the application software component; If the target flag reaches the maximum value, the application software component updates the target flag in the shared storage area to the minimum value.

[0009] In some embodiments, the non-volatile memory is configured with at least one non-volatile memory block; before invoking the non-volatile memory driver module through the memory management middleware to write the target data into the non-volatile memory, the data storage method further includes: Obtain the configuration requirement table of the non-volatile memory, the configuration requirement table including the configuration parameters of the non-volatile memory block; Based on the configuration requirements table, a storage block configuration file conforming to the automotive open system architecture standard is generated. Configure the non-volatile storage block based on the storage block configuration file; The step of writing the target data into the non-volatile memory includes: The target data is written into the target non-volatile storage block in the at least one non-volatile storage block.

[0010] In some embodiments, the non-volatile memory is configured with at least one non-volatile memory block. The non-volatile memory block stores structure variables, each structure variable including multiple member variables, and each member variable corresponding to a data storage requirement of the application software component.

[0011] In some embodiments, the target data is stored in a target non-volatile memory block within the at least one non-volatile memory block; Before the target flag in the shared storage area is changed via the application software component, the following steps are included: When the target non-volatile memory block stores the structure variable, the target flag bit corresponding to the target member variable is searched among the multiple flag bits in the shared memory area; Each member variable corresponds to a flag bit, and the target member variable is the member variable in the structure variable used to represent the target data.

[0012] In some embodiments, before changing the target flag bit in the shared storage area via the application software component, the method further includes: Obtain the data storage requirements for each item; The data storage requirements are grouped based on a preset storage grouping strategy; The storage grouping strategy includes: grouping according to the application software components to which the data storage requirements belong, grouping according to the data writing method, and / or grouping according to the data writing frequency; The structure variable is created based on the data storage requirements of the same group.

[0013] In some embodiments, the application software component and the storage management middleware exchange data through a sender-receiver interface; the storage management middleware and the non-volatile storage driver module communicate through a client-server interface.

[0014] Secondly, embodiments of this application provide a data storage device applied to a microcontroller unit, the microcontroller unit including at least a first processing core and a second processing core, the first processing core running application software components, and the second processing core running a non-volatile memory driver module; the microcontroller unit further includes a shared storage area connected to the first processing core and the second processing core, the data storage device comprising: The flag update module is used to change the target flag in the shared storage area by the application software component when the application software component needs to write data. The flag monitoring module is used to monitor whether the target flag has changed through a preset storage management middleware; The data reading module is used to obtain the target data to be written from the application software component through the storage management middleware when the target flag bit changes. The data writing module is used to call the non-volatile storage driver module through the storage management middleware to write the target data into the non-volatile memory.

[0015] Thirdly, embodiments of this application provide a microcontroller unit, which includes a processor and a memory. The memory is used to store instructions, and the processor is used to call the instructions in the memory to cause the microcontroller unit to execute the above-described data storage method.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data storage method described in any of the first aspects above.

[0017] Understandably, the data storage device, microcontroller unit, and storage medium provided above correspond to the data storage method of the first aspect above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of the corresponding data storage method provided above, and will not be repeated here. Attached Figure Description

[0018] Figure 1 This is a flowchart of the steps of a data storage method provided according to an embodiment of this application.

[0019] Figure 2 This is a schematic diagram illustrating the interaction between an application software component, a storage management middleware, and a non-volatile storage driver module according to an embodiment of this application.

[0020] Figure 3 This is a flowchart of the steps for configuring NVM according to an embodiment of this application.

[0021] Figure 4 This is a schematic diagram of an NVM configuration scenario provided according to an embodiment of this application.

[0022] Figure 5 This is a flowchart illustrating the steps of merging storage requirements according to an embodiment of this application.

[0023] Figure 6 This is a schematic diagram of a scenario for creating a structure according to an embodiment of this application.

[0024] Figure 7 This is a schematic diagram of the structure of a data storage device provided according to an embodiment of this application.

[0025] Figure 8 This is a schematic diagram of the structure of a microcontroller unit provided according to an embodiment of this application. Detailed Implementation

[0026] To better understand the above-mentioned objectives, features, and advantages of this application, the application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0027] The following description sets forth many specific details to provide a full understanding of this application. The described embodiments are only some, not all, of the embodiments of this application.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein in the specification of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application.

[0029] It should be further noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0030] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and drawings of this application are used to distinguish similar objects, not to describe a specific order or sequence.

[0031] 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 the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0032] The technical terms used in the embodiments of this application are described below.

[0033] Software-defined vehicle (SDV) refers to a vehicle whose core functions, user experience, and product value are no longer determined solely by the onboard hardware itself, but are achieved through the upgrade, iteration, and customized configuration of the onboard software. The vehicle's intelligent control, interactive experience, performance optimization, and other functions can be updated remotely through software upgrades.

[0034] Centralized electronic and electrical architecture refers to the integration of the computing and control capabilities of multiple functional modules of a vehicle into a high-performance core microcontroller unit (MCU), thereby enabling centralized management and coordinated scheduling of vehicle data and computing power.

[0035] A multi-core microcontroller unit (MCU) refers to an automotive MCU that integrates multiple computing cores (CPU cores). It can simultaneously and in parallel process computing tasks for multiple automotive functions, such as intelligent driving, vehicle-to-machine interaction, and vehicle control. When the application layer module and the non-volatile memory driver module run on different computing cores of the multi-core MCU, they need to interact across cores.

[0036] The Automotive Open System Architecture (AUTOSAR) is a universal standard architecture for the automotive electronics software industry. It was jointly developed by global automakers, component manufacturers, and software companies. Its core is to establish standardized, layered, and modular automotive software design specifications to enable compatibility, reuse, and collaborative operation of automotive software modules developed by different companies.

[0037] Non-volatile memory (NVM) retains its data even after power loss, allowing for long-term storage of data generated during vehicle operation, such as vehicle configuration parameters, driving mode settings, fault codes, and seat position data. It serves as the carrier for in-vehicle data storage. NVM includes flash memory and electrically erasable programmable read-only memory (EEPROM).

[0038] A non-volatile memory block (NVM block) refers to the management unit of non-volatile memory. When configuring non-volatile memory, low-level development engineers divide the physical storage space of non-volatile memory into multiple independent storage blocks. Each storage block corresponds to the specific data storage requirements of a type or application layer module and is the core operation object of the low-level non-volatile memory configuration work. In traditional development models, this storage block needs to be manually configured one by one by low-level engineers according to application layer requirements.

[0039] The non-volatile memory module refers to the low-level software module developed based on AUTOSAR for managing non-volatile memory. It belongs to the low-level (basic software layer) of the vehicle software. It can receive the storage requirements of the application layer, realize the reading, writing, erasing, and backup of data in the non-volatile memory, and provide the data reading and writing interaction interface for the application layer. It is the software module that connects the application layer and the non-volatile memory.

[0040] The application layer refers to one of the vehicle software layers based on the AUTOSAR architecture. Corresponding to the lower layer (basic software layer), it is responsible for the development and implementation of specific vehicle functions, such as air conditioning control, seat adjustment, intelligent driving algorithms, and vehicle-machine interaction modules. The application layer is developed by application layer engineers, primarily to implement specific vehicle functions and to call the functions of the lower-level NVM modules through specific interfaces to complete data read and write operations.

[0041] This application provides a data storage method, apparatus, microcontroller unit, and computer-readable storage medium.

[0042] This data storage method is applied to a microcontroller unit, which includes at least a first processing core and a second processing core. The first processing core runs application software components, and the second processing core runs a non-volatile memory driver module. The microcontroller unit also includes a shared memory area connected to the first processing core and the second processing core. The data storage method includes: When the application software component needs to write data, it modifies the target flag bit in the shared storage area. The target flag is monitored for changes using a pre-defined storage management middleware. When the target flag changes, the target data to be written is obtained from the application software component through the storage management middleware. The storage management middleware calls the non-volatile storage driver module to write the target data into the non-volatile memory.

[0043] In this embodiment, a target flag is configured in the shared storage area. By changing the target flag, the application software component can write data without directly calling the NVM driver across cores. The storage management middleware writes data according to the change of the target flag, avoiding periodic data writing and effectively filtering invalid data in the intermediate process. This can significantly reduce the number of writes to the NVM, thereby protecting the lifespan of the NVM and reducing CPU load.

[0044] The microcontroller unit is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, processors, microprogrammed control units (MCUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0045] Figure 1 This is a flowchart illustrating the steps of an embodiment of the data storage method of this application. Depending on different requirements, the order of the steps in the flowchart can be changed, and some steps can be omitted.

[0046] See Figure 1 As shown, the data storage method may include the following steps.

[0047] Step 101: When the application software component needs to write data, the target flag bit in the shared storage area is changed by the application software component.

[0048] In this embodiment, the application software component runs on the first processing core. When it determines that it needs to persistently store certain data (such as the final position of a car window when it stops moving), it indirectly expresses its storage intention by manipulating the target flag bit located in the shared storage area.

[0049] Each data item that needs to be stored has a corresponding flag in the shared storage area. This flag can be a variable of type uint8, and its initial value can be 0. When an application software component needs to trigger storage, it performs an atomic operation on the target flag to make the change.

[0050] In some embodiments, the modification operation of the target flag bit includes the following two cases: if the target flag bit has not reached the maximum value of the flag bit, the target flag bit in the shared storage area is incremented by the application software component; if the target flag bit reaches the maximum value of the flag bit, the target flag bit in the shared storage area is updated to the minimum value of the flag bit by the application software component.

[0051] For example, refer to Figure 2 As shown, if the current value of the target flag has not reached the maximum value (e.g., 255), the value of the target flag is incremented by 1 through an atomic increment operation. For example, from N to N+1.

[0052] If the current value of the target flag has reached 255 (i.e., the maximum value of the flag), it is updated to 0 (i.e., the minimum value of the flag) through atomic operations to achieve loop counting. Here, it can be updated to 0 by adding 1.

[0053] Understandably, the data type of the target flag can be a binary integer with a preset number of bits (such as uint8). When the application software component needs to write data, it can increment the target flag in the shared storage area by 1 to achieve a cyclic count of the target flag without resetting it.

[0054] The embodiments of this application employ atomic operations to ensure data consistency and operational security in multi-core concurrent access scenarios.

[0055] In addition, using cyclic counting allows the target flag to be used continuously without being reset, greatly simplifying state management.

[0056] Step 102: Monitor whether the target flag has changed through the preset storage management middleware.

[0057] The storage management middleware can run on a second processing core to manage NVM storage operations. The storage management middleware can continuously poll all flags in the shared storage region at configurable intervals (e.g., every 10 milliseconds).

[0058] The storage management middleware can maintain a local cache of the last value for each flag.

[0059] Step 103: When the target flag changes, the target data to be written is obtained from the application software component through the storage management middleware.

[0060] When the storage management middleware detects that the current value of a certain flag (i.e., the target flag) is inconsistent with the local cache value, it determines that the flag has changed, indicating that the corresponding data item has a new storage requirement.

[0061] In this scenario, the storage management middleware can send requests to the application software components running on the first processing core through a predefined interface to obtain the latest target data to be stored.

[0062] The embodiments of this application can change cross-core data transmission from active push to on-demand retrieval.

[0063] Taking the position of the car window as an example, even if the position data is constantly changing during the process of the car window rising, the middleware cannot detect the change of the flag bit because the flag bit is not changed (the application component will only change the flag bit when the car window stops). Therefore, no cross-core data transmission will be triggered. When the car window stops and the application component performs an increment operation on the flag bit, the middleware will detect the change and initiate a data read, thereby avoiding the position data being repeatedly written to NVM in the middle process.

[0064] Step 104: Call the non-volatile memory driver module through the storage management middleware to write the target data into the non-volatile memory.

[0065] After the storage management middleware obtains the target data, it calls the service interface provided by the non-volatile storage driver module to write the data into the non-volatile storage. After the writing is completed, the middleware updates the value of the flag bit in the local cache to the current value in preparation for the next detection.

[0066] In some embodiments, the application software component and the storage management middleware can use a sender-receiver interface for data transfer. For example, in step 130 above, when the middleware needs to obtain target data from the application component, the application component acts as the data sender, and the middleware acts as the data receiver.

[0067] The above communication mode is suitable for data producer-consumer scenarios. Application components only need to provide data and do not need to wait for the processing results of the middleware, thus achieving asynchronous decoupling.

[0068] The storage management middleware and the non-volatile storage driver module can communicate via a client-server interface. For example, in step S240, the middleware, acting as a client, initiates a function call, and the non-volatile storage driver module, acting as a server, performs the actual write operation and can return the execution status. This mode is suitable for operation scenarios that require reliable execution and the possibility of returning a status.

[0069] By using the above method, this application embodiment transforms high-frequency cross-core data copying into lightweight local flag bit atomic operations, significantly reducing CPU load. By using the flag bit mechanism to delegate the storage triggering right to the application layer, the write is triggered only when storage is needed (such as when the car window stops), avoiding invalid storage of intermediate data, thereby protecting the NVM lifespan and reducing CPU load.

[0070] Based on the above embodiments, this application also provides an NVM configuration method to solve the problems of low efficiency and error-proneness in manual NVM configuration.

[0071] Specifically, in traditional AUTOSAR-based development, engineers need to perform tedious manual configurations using software tools such as Vector DaVinciConfigurator and EB tresos Studio. Engineers must create and set dozens of properties for each NVM Block individually in a graphical interface, a process highly prone to errors.

[0072] Especially when the number of NVM Blocks reaches hundreds or thousands, manual configuration becomes extremely inefficient. Furthermore, the Davinci tool itself is prone to lag due to its architecture, often requiring several seconds to click on a configuration, further deteriorating the development experience. When the NVM requirements table (often maintained in Excel) changes, manually synchronizing the configuration becomes even more difficult, easily leading to configuration drift.

[0073] In view of the above, embodiments of this application also provide an NVM configuration process. (See reference...) Figure 3 Before step 104, the data storage method of this embodiment may further include the following steps: Step 301: Obtain the configuration requirements table for non-volatile memory, which includes the configuration parameters of non-volatile memory blocks.

[0074] In the application embodiment, a set of structured Excel requirement templates can be defined. This template specifies various parameters for each non-volatile memory block (NVM block).

[0075] refer to Figure 4 As shown, this template can include, but is not limited to: Block name, data length, data type, CRC check method, associated RAM and ROM blocks, power-on read strategy (ReadAll), and power-off write strategy (WriteAll). Developers only need to fill in this Excel spreadsheet according to project requirements.

[0076] Step 302: Generate a storage block configuration file that conforms to the automotive open system architecture standard based on the configuration requirements table.

[0077] The storage block configuration file can be an ARXML file.

[0078] After reading the above Excel requirements table, the automated configuration tool can execute the following automated build process: The first step is reading and parsing: using Python's pandas or openpyxl library, accurately parse each row of the Excel file to build a list of configuration objects in memory.

[0079] The second step is the intelligent construction of the ARXML object model: following the AUTOSAR specification, a complete configuration object tree is dynamically constructed in memory.

[0080] For example, create a corresponding NvMBlockDescriptor for each requirement and populate basic attributes; parse the Data Type field in Excel, automatically establish data type mapping, and generate the corresponding SW-BASE-TYPE or APPLICATION-DATA-TYPE definition; based on the Ram Block and Rom Block fields, automatically generate the complete definition of the corresponding RAM image block and ROM default value block, and establish the association relationship with the main block; automatically convert Boolean values ​​or enumeration values ​​(such as ReadAll=TRUE) in Excel into configuration items corresponding to the AUTOSAR specification.

[0081] The third step involves generating a configuration file conforming to the AUTOSAR XML Schema format, i.e., the storage block configuration file, based on the constructed memory object tree. This file contains a complete configuration object tree for all NVM Blocks, with a clear hierarchy and complete reference relationships.

[0082] Step 303: Configure non-volatile storage blocks based on the storage block configuration file.

[0083] For example, continue to refer to Figure 4 As shown, the ARXML file generated in the previous step can be imported into mainstream software configuration tools (such as Vector DaVinci Configurator or EB tresos Studio) with one click. The tool automatically parses the ARXML file and automatically creates all NVM Blocks and their associated objects in the configuration interface, with all attributes automatically populated at once.

[0084] Based on this, the step of writing the target data into the non-volatile memory in step 104 above may include: writing the target data into the target non-volatile memory block in at least one non-volatile memory block configured through the above process, wherein each data has its corresponding target memory block, and the correspondence has been defined in the configuration process.

[0085] Through the above-described automated configuration scheme, the embodiments of this application can effectively shorten the NVM configuration cycle, facilitate timely synchronization of NVM requirements and underlying configurations, and significantly improve development efficiency and configuration quality.

[0086] In large-scale automotive MCU software, various functional modules will generate numerous NVM storage requirements. If each requirement is to create an independent NVM block, it will lead to problems such as a large number of blocks, severe storage fragmentation, and prolonged system startup time.

[0087] Therefore, in a further embodiment of this application, the non-volatile memory block can also organize data in the form of a structure. The structure variable can include multiple member variables, each of which represents a data storage requirement of the application software component, thereby reducing the number of NVM blocks.

[0088] Furthermore, each member variable in the structure can be assigned an independent flag.

[0089] For example, the non-volatile memory is configured with at least one non-volatile memory block, which can store structure variables. Each structure variable includes multiple member variables, and each member variable represents a data storage requirement of the application software component.

[0090] For example, the multiple storage requirements of the window control module can be combined and defined as the following structure type: typedef struct { uint32_t window_position; / / Requires storage for the window position; uint16_t window_speed; / / Requires storage for the speed of the car window; uint8_t window_state; / / Requires storage of the window state; } NvMBlock_Window_Type; Among them, window_position, window_speed, and window_state are the three member variables of the structure, which correspond to the three independent data storage requirements of the window control module.

[0091] In some embodiments, a number of flag bits may be stored in the shared storage area, and these flag bits have a one-to-one correspondence with a number of member variables in the structure variable.

[0092] For example, three independent flags are assigned to the three member variables of the NvMBlock_Window_Type structure: Flag_A corresponds to the window_position member; Flag_B corresponds to the window_speed member; and Flag_C corresponds to the window_state member.

[0093] Therefore, before step 101 above, when the application software component needs to write specific data (such as window position data), the application software component can determine which target non-volatile storage block the data is stored in; then, determine which target member variable in the structure corresponding to the data; next, search for the target flag bit corresponding to the target member variable among multiple flag bits in the shared storage area, so that the storage management middleware can accurately know the data member that needs to be changed.

[0094] Please combine Figure 5 As shown in the figure, a storage requirement merging method is proposed for an embodiment of the application.

[0095] Step 501: Obtain the data storage requirements for each item.

[0096] For example, raw NVM storage requirements from different application software components can be collected. Each requirement can be defined as a tuple containing the following information: the application software component (such as window control, seat memory, and lighting control), data length, write method, estimated write frequency, and data identifier.

[0097] Step 502: Group the data storage requirements according to the preset storage grouping strategy.

[0098] Storage grouping strategies may include, but are not limited to, grouping by application software components to which data storage needs belong, grouping by data writing method, and grouping by data writing frequency.

[0099] Furthermore, a hierarchical grouping strategy can be adopted, as follows: The first level involves grouping data according to the application software components to which the data storage requirements belong. For example, requirements belonging to the same application software functional module (such as the window control module) are first grouped into a candidate set. This level of grouping ensures the logical aggregation of data.

[0100] The second level is grouped according to the data writing method.

[0101] Within the same application software component, data writing methods can include immediate write, power-down write, and both compatibility mode.

[0102] Immediate write refers to data that needs to be written to non-volatile memory immediately after a change, such as critical security parameters and real-time mode status.

[0103] Power-off write refers to the process of writing data back only before the system goes into hibernation or is powered off, such as non-critical configurations and historical records.

[0104] The compatibility mode supports both methods simultaneously.

[0105] This level can isolate data with different real-time requirements, avoiding the blocking of the power-off write process by high-frequency immediate write operations due to merging.

[0106] The third level is grouped according to the frequency of data writing.

[0107] Within the same write method group, fine aggregation is performed based on the estimated write frequency.

[0108] For example, high-frequency writing: merges data that is written frequently and is short in length. Strictly control the total length of high-frequency write blocks to reduce frequent erasures and writes to the same Flash physical area, thus extending media lifespan.

[0109] Low-frequency writes: Data that is written less frequently is merged into larger blocks to improve storage space utilization and reduce the total number of blocks.

[0110] This level grouping achieves wear leveling.

[0111] The fourth level is cross-module grouping. After completing the first three levels of grouping, residual small blocks with the same storage attributes (similar write methods and frequency levels) and complementary lifecycles or access scenarios from different application software components can be grouped across modules to further compress the total number of blocks.

[0112] Step 503: Create a structure variable based on the data storage requirements of the same group.

[0113] After the above four-level grouping strategy, the originally scattered N storage requirements are aggregated into M physical NVMBlocks (M is much smaller than N). Each merged block will be presented in the code as a structure, and the multiple member variables of the structure correspond to the data storage requirements that were merged in.

[0114] For example, if the three high-frequency immediate write requests (4 bytes, 2 bytes, and 1 byte) of the window module are determined to belong to the same group using the above grouping strategy, then the following structure variable will be created: typedef struct { uint32_t demand_1; / / Original requirement 1: 4 bytes, high-frequency immediate write; uint16_t demand_2; / / Original demand 2: 2 bytes, high-frequency immediate write; uint8_t demand_3; / / Original demand 3: 1 byte, high-frequency immediate write; } HighFreq_type.

[0115] In some embodiments of this application, after the structure variable, the configuration requirement table of the non-volatile memory can be obtained based on the structure variable to perform automated NVM configuration.

[0116] refer to Figure 6 As shown, compared to creating an NVM Block for each data storage requirement, the embodiments of this application can merge multiple data storage requirements to form a structure, thereby creating an NVM block. This merges a large amount of short data into a continuous large block, significantly reducing internal Flash fragmentation, improving Data Flash space utilization, and also greatly reducing the total number of NVMBlocks. This reduces the initialization verification overhead of the NVM module at startup and the data write-back overhead during hibernation, shortening system startup and hibernation time.

[0117] Furthermore, this application embodiment controls the length of high-frequency write blocks by isolating and aggregating according to write frequency, avoiding excessive wear in local Flash areas, achieving global wear leveling, and extending NVM lifespan; by isolating according to write mode, it ensures that the real-time performance of immediate write operations is not affected by the blocking of power-down write operations.

[0118] Based on the same idea as the data storage method in the above embodiments, this application also provides a data storage device that can be used to execute the above data storage method. For ease of explanation, the structural schematic diagram of the data storage device embodiment only shows the parts related to the embodiments of this application. Those skilled in the art will understand that the illustrated structure does not constitute a limitation on the device, and may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0119] like Figure 7 As shown, the data storage device includes a flag update module 701, a flag monitoring module 702, a data reading module 704, and a data writing module 705. In some embodiments, the above modules can be programmable software instructions stored in memory and executable by a processor. It is understood that in other embodiments, the above modules can also be program instructions or firmware embedded in the processor.

[0120] The flag update module 701 is used to change the target flag in the shared storage area through the application software component when the application software component needs to write data. The flag monitoring module 702 is used to monitor whether the target flag has changed 703 through a preset storage management middleware; The data reading module 704 is used to obtain the target data to be written from the application software component through the storage management middleware when the target flag bit changes. The data writing module 705 is used to call the non-volatile memory driver module through the storage management middleware to write the target data into the non-volatile memory.

[0121] Figure 8 This is a schematic diagram of an embodiment of the microcontroller unit of this application.

[0122] The microcontroller unit 100 includes a memory 20, a processor 30, and a computer program 40 stored in the memory 20 and executable on the processor 30. When the processor 30 executes the computer program 40, it implements the steps described in the data storage method embodiments above, for example... Figure 1 Steps 101 to 104 are shown.

[0123] For example, the computer program 40 can also be divided into one or more modules / units, which are stored in the memory 20 and executed by the processor 30. The one or more modules / units can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program 40 in the microcontroller unit 100.

[0124] Those skilled in the art will understand that the schematic diagram is merely an example of the microcontroller 100 and does not constitute a limitation on the microcontroller 100. It may include more or fewer components than shown, or combine certain components, or different components. For example, the microcontroller 100 may also include input / output devices, network access devices, buses, etc.

[0125] Processor 30 can 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. The general-purpose processor can be a microprocessor, a single-chip microcomputer, or any conventional processor.

[0126] The memory 20 can be used to store computer programs 40 and / or modules / units. The processor 30 implements various functions of the microcontroller 100 by running or executing the computer programs and / or modules / units stored in the memory 20 and by calling data stored in the memory 20. The memory 20 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the microcontroller 100 (such as audio data), etc. In addition, the memory 20 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other non-volatile solid-state storage device.

[0127] If the modules / units integrated in the microcontroller unit 100 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately added to or subtracted from the content as required by the legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium may not include electrical carrier signals and telecommunication signals.

[0128] In the several embodiments provided in this application, it should be understood that the disclosed microcontroller unit and method can be implemented in other ways. For example, the microcontroller unit embodiments described above are merely illustrative; for instance, the division of the unit is only a logical functional division, and other division methods may be used in actual implementation.

[0129] Furthermore, the functional units in the various embodiments of this application can be integrated into the same processing unit, or each unit can exist physically separately, or two or more units can be integrated into the same unit. The integrated units described above can be implemented in hardware or in the form of hardware plus software functional modules.

[0130] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and not restrictive in all respects. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or microcontrollers recited in the microcontroller claims may also be implemented by the same unit or microcontroller through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any particular order.

[0131] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application.

Claims

1. A data storage method applied to a microcontroller unit, characterized in that, The microcontroller unit includes at least a first processing core and a second processing core, wherein the first processing core runs application software components and the second processing core runs a non-volatile memory driver module; The microcontroller unit further includes a shared storage area connected to the first processing core and the second processing core, and the data storage method includes: When the application software component needs to write data, it modifies the target flag bit in the shared storage area. The target flag is monitored for changes using a pre-defined storage management middleware. When the target flag changes, the target data to be written is obtained from the application software component through the storage management middleware. The storage management middleware calls the non-volatile storage driver module to write the target data into the non-volatile memory.

2. The data storage method according to claim 1, characterized in that, The step of modifying the target flag bit in the shared storage area through the application software component includes: If the target flag bit has not reached the maximum value, the target flag bit in the shared storage area is incremented by the application software component; If the target flag reaches the maximum value, the application software component updates the target flag in the shared storage area to the minimum value.

3. The data storage method according to claim 1, characterized in that, The non-volatile memory is configured with at least one non-volatile memory block; Before invoking the non-volatile memory driver module through the storage management middleware to write the target data into the non-volatile memory, the data storage method further includes: Obtain the configuration requirement table of the non-volatile memory, the configuration requirement table including the configuration parameters of the non-volatile memory block; Based on the configuration requirements table, a storage block configuration file conforming to the automotive open system architecture standard is generated. Configure the non-volatile storage block based on the storage block configuration file; The step of writing the target data into the non-volatile memory includes: The target data is written into the target non-volatile storage block in the at least one non-volatile storage block.

4. The data storage method according to claim 1, characterized in that, The non-volatile memory is configured with at least one non-volatile memory block; the non-volatile memory block stores structure variables, the structure variables including multiple member variables, each member variable corresponding to a data storage requirement of the application software component.

5. The data storage method according to claim 4, characterized in that, The target data is stored in the target non-volatile memory block within the at least one non-volatile memory block; Before the target flag in the shared storage area is changed via the application software component, the following steps are included: When the target non-volatile memory block stores the structure variable, the target flag bit corresponding to the target member variable is searched among the multiple flag bits in the shared memory area; Each member variable corresponds to a flag bit, and the target member variable is the member variable in the structure variable used to represent the target data.

6. The data storage method according to claim 4, characterized in that, Before the target flag in the shared storage area is changed through the application software component, the method further includes: Obtain the data storage requirements for each item; The data storage requirements are grouped based on a preset storage grouping strategy; The storage grouping strategy includes: grouping according to the application software components to which the data storage requirements belong, grouping according to the data writing method, and / or grouping according to the data writing frequency; The structure variable is created based on the data storage requirements of the same group.

7. The data storage method according to any one of claims 1 to 6, characterized in that, The application software components and the storage management middleware exchange data through a sender-receiver interface; the storage management middleware and the non-volatile storage driver module communicate through a client-server interface.

8. A data storage device applied to a microcontroller unit, characterized in that, The microcontroller unit includes at least a first processing core and a second processing core, wherein the first processing core runs application software components and the second processing core runs a non-volatile memory driver module; The microcontroller unit further includes a shared storage area connected to the first processing core and the second processing core, and the data storage device includes: The flag update module is used to change the target flag in the shared storage area by the application software component when the application software component needs to write data. The flag monitoring module is used to monitor whether the target flag has changed through a preset storage management middleware; The data reading module is used to obtain the target data to be written from the application software component through the storage management middleware when the target flag bit changes. The data writing module is used to call the non-volatile storage driver module through the storage management middleware to write the target data into the non-volatile memory.

9. A microcontroller unit, the microcontroller unit comprising a processor and a memory, characterized in that, The memory is used to store instructions, and the processor is used to call the instructions in the memory, causing the microcontroller to execute the data storage method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on a microcontroller unit, cause the microcontroller unit to perform the data storage method as described in any one of claims 1 to 7.

Images