Data access method and device, single-chip microcomputer, storage medium and program product

Abstract

This application discloses a data access method, apparatus, microcontroller, storage medium, and program product, relating to the field of embedded software architecture technology and applied to microcontrollers. The method includes: during runtime, acquiring multiple static contracts for each business module and performing consistency checks on each static contract; after all consistency checks on each static contract pass, allocating corresponding storage space in a static storage pool for the shared data items declared by each business module, and using the index of the storage space as the access index for each shared data item; based on the access permissions of each shared data item, selecting a target operation table matching the access permissions from multiple preset operation tables for each business module; when calling the access function in the target operation table, using the access index as the input parameter of the access function to access the shared data item in the storage space corresponding to the access index. This application solves the technical problems of poor data consistency and low reliability.

Description

Technical Field

[0001] This application relates to the field of embedded software architecture technology, and in particular to data access methods, data access devices, microcontrollers, storage media and computer program products. Background Technology

[0002] In the scenario of multi-service module collaboration in embedded real-time systems, each service module is usually integrated into the same microcontroller as an independent plug-in. Data exchange and collaborative work are completed through a shared memory area. However, when different service modules access the same data item in the shared memory area, there is a lack of unified agreement on information such as the field layout, number of bytes occupied, effective value range, and allowed access context type (task context or interrupt context) of the data item. Each service module can only rely on its own private internal agreement to read and write the data item in the shared memory area.

[0003] In this collaborative model, when a business module modifies the field arrangement or length of a specific data item published in the shared memory area due to changes in requirements or version upgrades, other business modules that depend on that specific data item still access the location where that specific data item is stored according to the original internal conventions. This difference cannot be detected during compilation and linking. It will only cause out-of-bounds read / write, field misalignment, or silent data corruption under specific running paths or data triggering conditions in actual operation. Moreover, the fault triggering point is far behind the code change point, making it extremely difficult to locate and reproduce the problem.

[0004] Meanwhile, because the access point for all shared data items is centralized into a single general-purpose read / write interface, the interrupt service routine corresponding to the interrupt context and the task executor corresponding to the task context are forced to share the same access point. This causes the interrupt service routine to be unable to distinguish which access paths are only allowed to be operated by the task executor and which access operations involve large blocks of non-atomic data. The task executor also cannot predict whether its current access to a data item might conflict with the interrupt service routine. As the number of integrated business modules increases, the data contention and state inconsistency problems caused by the task executor and interrupt service routine sharing the same interface to access shared data continue to intensify, making it difficult to guarantee system reliability. Summary of the Invention

[0005] The main purpose of this application is to provide a data access method, a data access device, a microcontroller, a storage medium, and a computer program product, which aims to solve the technical problems of poor data consistency and low reliability in existing multi-business module collaboration scenarios.

[0006] To achieve the above objectives, this application proposes a data access method applied to a microcontroller, the data access method comprising: During the operation of the microcontroller, multiple static contracts of each business module are obtained, and consistency verification is performed on each static contract; wherein, the static contract includes the shared data items declared by the business module and the access permissions of the shared data items; After the consistency verification of each static contract passes, the corresponding storage space is allocated in the static storage pool for the shared data items declared by each business module, and the index of the storage space is used as the access index of each shared data item; wherein, the static storage pool is the storage space pre-allocated during the compilation of the microcontroller; Based on the access permissions of each shared data item, a target operation table matching the access permissions is selected from a plurality of preset operation tables for each business module; When calling the access function in the target operation table, the access index is used as the input parameter of the access function to access the shared data item in the storage space corresponding to the access index.

[0007] In one embodiment, prior to the step of obtaining multiple static contracts submitted by each business module, the method includes: During the compilation phase of the microcontroller, a static contract for the business module is constructed based on the description information of the business module and the description information of the shared data items declared by the business module. The description information of the business module includes the plug-in identifier of the business module and the number of shared data items declared; the description information of the shared data items includes the logical key name, data type, byte length, and access permissions of the shared data items.

[0008] In one embodiment, if the plugin identifier is not empty and the identifier length of the plugin identifier does not exceed the preset naming length limit, the following verification is performed on each shared data item in the static contract according to the number of shared data items: Verify whether the logical key name exceeds the preset naming length limit; Verify whether the data type of the shared data item and the actual byte length occupied by the data item in the microcontroller are consistent with the byte length of the shared data item in the static contract; Verify whether the byte length of the shared data item exceeds the preset maximum length limit; Verify whether the access permissions of the shared data items are within the preset legal permission range; Verify whether the logical key name of the shared data item is declared by only one business module in the role of provider.

[0009] In one embodiment, the step of performing consistency verification on each of the static contracts includes: If any check fails, the consistency check of the static contract is deemed to have failed, and storage space is refused to be allocated for the shared data items in the static contract, thereby preventing access to the shared data items through the access functions in the target operation table.

[0010] In one embodiment, prior to the step of obtaining multiple static contracts submitted by each business module, the method further includes: During the compilation phase of the microcontroller, the various access functions in the microcontroller are classified into different operation tables according to the running context type, access operation type, and functional role when each business module accesses data, resulting in multiple preset operation tables; wherein, the multiple operation tables include a task read operation table, a task write operation table, an interrupt read operation table, an interrupt write operation table, and a handle resolution operation table.

[0011] In one embodiment, before the step of allocating corresponding storage space in the static storage pool for the shared data items declared by each of the business modules after the consistency verification of each of the static contracts has passed, the method includes: Calculate the total number of bytes of storage space required for all shared data items in the plurality of static contracts, and compare the total number of bytes of storage space with the available space of the static storage pool; When the total number of bytes in the storage space is less than or equal to the available space, the step of allocating corresponding storage space in the static storage pool for the shared data items declared by each of the business modules is executed. When the total number of bytes in the storage space exceeds the available space, the executed storage space allocation operation is revoked, and the static storage pool is rolled back to its initial state.

[0012] Furthermore, to achieve the above objectives, this application also proposes a data access device for use with a microcontroller, the data access device comprising: The acquisition module is used to acquire multiple static contracts of each business module during the runtime of the microcontroller and perform consistency verification on each static contract; wherein, the static contract includes the shared data items declared by the business module and the access permissions of the shared data items; The allocation module is used to allocate corresponding storage space in the static storage pool for the shared data items declared by each of the business modules after the consistency verification of each of the static contracts has passed, and to use the index of the storage space as the access index of each of the shared data items; wherein, the static storage pool is the storage space pre-allocated during the compilation of the microcontroller; The selection module is used to select a target operation table that matches the access permissions of each of the shared data items from a plurality of preset operation tables for each of the business modules. The access module is used to access the shared data item in the storage space corresponding to the access index by using the access index as the input parameter of the access function when calling the access function in the target operation table.

[0013] In addition, to achieve the above objectives, this application also proposes a microcontroller, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data access method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the data access method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the data access method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application involves each business module submitting static contracts to the data center within the microcontroller during runtime. This ensures that information such as the field layout, byte count, and access permissions of shared data items are permanently embedded in the microcontroller in a unified contract format. Subsequently, consistency checks are performed on each submitted static contract to ensure that the descriptions of the declared shared data items by each business module conform to preset constraints in terms of type, size, and permissions. This switches the access of shared data items by each business module from relying on its own private internal conventions to a standardized access path under the constraints of a unified contract. When any business module modifies the layout or length of its declared shared data items, the inconsistency between this modification and the original static contract is exposed during the runtime verification phase, without waiting for a specific runtime path or data triggering conditions, completely eliminating the problem of fault trigger points lagging far behind change points.

[0017] Furthermore, after all static contract consistency checks pass, this application allocates storage space for each shared data item in the static storage pool pre-allocated during compilation, and uses the index of the allocated storage space as the access index; during runtime, the corresponding storage space can be directly located and data read and write can be completed through this access index. The entire process does not require dynamic memory allocation and release, thus eliminating the risk of response delay caused by the uncertainty of dynamic allocation.

[0018] Simultaneously, based on the access permissions declared in each static contract, a target operation table corresponding to the access permissions of each business module is matched from multiple preset operation tables. The task execution program and the interrupt service routine each obtain an independent operation entry point adapted to their context type, no longer sharing a single general read / write interface. The business module can access the corresponding data item in the static storage pool in constant time by calling the access function in the target operation table and using the access index as the input parameter. Since the operation table has isolated the task-accessible items and interrupt-accessible items at the interface level, the task execution program can only access the data path governed by the task operation table, and the interrupt service routine can only call the limited subset provided by the interrupt operation table. The risk of data contention and state fragmentation does not accumulate with the increase in the number of integrated business modules.

[0019] In summary, this application solves the technical problems of poor data consistency and difficulty in fault location caused by the lack of a unified contract description for shared data items in existing multi-business module collaboration scenarios, as well as the technical problem of low reliability caused by tasks and interruptions sharing a single access point. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a first flowchart illustrating an embodiment of the data access method of this application; Figure 2 This is a second flowchart illustrating an embodiment of the data access method of this application; Figure 3 A simplified schematic diagram provided for one embodiment of the data access method of this application; Figure 4 This is a schematic diagram of the module structure of the data access device of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the data access method of this application.

[0023] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0024] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0025] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0026] The full English and Chinese names of the abbreviations appearing in this application are as follows: API stands for Application Programming Interface. AI, Artificial Intelligence; ARM, Advanced RISC Machine; ARXML, AUTOSAR XML, AUTOSAR Extensible Markup Language; AUTOSAR, AUTomotive Open System Architecture; AXI, Advanced eXtensible Interface; BMS stands for Battery Management System. CAN stands for Controller Area Network. CLI, Command Line Interface; Cortex-M, Cortex-M (Microcontroller), Cortex-M microcontroller series; D-Cache, Data Cache; DDS, Data Distribution Service; IDL, Interface Definition Language; ISR, Interrupt Service Routine; MCU stands for Microcontroller Unit, or microcontroller. ROS, Robot Operating System; RTDB, Real-Time Database; RTE, Run-Time Environment; RTOS stands for Real-Time Operating System. SCADA, Supervisory Control and Data Acquisition; SRAM, Static Random-Access Memory; UDS, Unified Diagnostic Services; Flash memory.

[0027] In resource-constrained embedded products, various business modules need to share data and exchange operational status efficiently. Existing typical solutions include: global variables and extern declarations, classic blackboard architecture derived from artificial intelligence systems, ARXML configuration and runtime environment RTE that relies on external toolchains and AUTOSAR, DDS and ROS publish-subscribe middleware that are transparent to the network, message streaming processing based on RTOS queues, and RTDB tag data management used in industrial SCADA systems.

[0028] However, the above solutions have the following problems: the global variable solution cannot pass any consistency constraint information to dependent parties when the data structure changes; the classic blackboard architecture originates from artificial intelligence systems and has not been tailored for embedded resource-constrained scenarios; although AUTOSAR RTE solidifies the contract through the toolchain at compile time, it relies on complex ARXML configuration and code generators, which has a large resource overhead for small embedded products, and the contract information is no longer retained at runtime; middleware such as DDS and ROS are based on the network publish-subscribe paradigm, and their resource consumption far exceeds the tolerance of MCU-type devices; RTOS queues are based on message stream processing and lack a unified data view; industrial RTDBs usually rely on dynamic allocation at runtime.

[0029] Therefore, this application proposes an embedded data access scheme that separates the access paths of task and interrupt contexts by having each business module submit a static contract and perform consistency verification during runtime, and matching the corresponding operation table according to the access permissions declared in the contract. This scheme can solve the problems of lack of unified agreement between business modules, other business modules still accessing data according to the old agreement after data structure changes, resulting in misalignment, overwriting, and damage, and making it difficult to locate faults; and the problem that the task execution program and the interrupt service program share the same general interface, which leads to the risk of data competition and state tearing that increases with the number of modules.

[0030] It should be noted that the execution entity in this embodiment can be a microcontroller, such as the GD32H737IMT6, STM32H753, GD32F30x, or other microcontrollers based on the ARM Cortex-M series processors; it can also be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone; or an embedded device, industrial controller, or IoT terminal capable of implementing the above functions. The following description uses a microcontroller as an example to illustrate this embodiment and the subsequent embodiments.

[0031] Based on this, embodiments of this application provide a data access method applied to a microcontroller, as shown below. Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the data access method of this application.

[0032] In one feasible embodiment, the application scenarios of the technical solution of this application can be: resource-constrained MCU products such as industrial DC charging piles (e.g., GD32H737IMT6 platform), new energy vehicle controllers (e.g., STM32H753 platform), and outdoor power monitoring terminals (e.g., GD32F30x platform).

[0033] In this embodiment, the data access method includes steps S1 to S4: Step S1: During the operation of the microcontroller, multiple static contracts of each business module are obtained, and consistency verification is performed on each static contract; wherein, the static contract includes the shared data items declared by the business module and the access permissions of the shared data items; It should be noted that after the microcontroller completes hardware reset and basic peripheral initialization, it enters the contract registration phase of the business modules. At this time, the microcontroller's data center (a basic service layer running within the microcontroller) needs to collect data declarations from various business modules (also called plug-ins). These data declarations are stored in the read-only segment of the microcontroller's Flash memory in the form of static contracts (also called contracts), which inform the data center "which data items this business module needs to share" and "what access methods (task read / write, interrupt read / write, etc.) are allowed for these data items." After the registration phase is completed, each business module will access the shared data during the runtime phase through the handles and operation tables obtained in the registration phase.

[0034] Optionally, the business module is an independent software unit in an embedded product (the microcontroller is the core processor chip of the embedded product, and the business module is a software program unit burned and running on the microcontroller chip) that performs a specific function, such as a security plane module, a data plane module, a control plane module, a command line interface module, etc.

[0035] Optionally, a static contract shall include at least the following fields: plugin identifier, contract version number, plugin identifiers of other business modules it depends on, number of shared data items, and description information of the shared data items themselves.

[0036] Optionally, the static contract is a data structure that is fixed in the read-only data segment of the microcontroller's Flash memory. Each business module constructs its own independent static contract during compilation and submits it to the data center in the microcontroller through the contract registration entry in the microcontroller during runtime. The static contract can be in the form of a C language structure constant modified by const.

[0037] Optionally, a shared data item is a data object that a business module expects to register with the data center so that it can be accessed by other business modules. It can be a numerical scalar (such as temperature value, voltage value, status code), a structure (such as charging parameter set, fault record), or a reference type (such as a handle reference to another data item).

[0038] Optionally, access permissions are enumeration constraints describing the contexts in which shared data items are allowed to be accessed and in what ways. Specifically, they include: task-state (also called task executor) read permissions, task-state write permissions, interrupt service routine read permissions, interrupt service routine write permissions, and combinations thereof. They also include functional roles (provider, consumer, converter) to declare the role of this business module in accessing the shared data item. The data center needs to ensure that only business modules holding the corresponding permissions can access the shared data item in the appropriate context.

[0039] Optionally, consistency verification is a process in which the data center, upon receiving a static contract, checks each field in the static contract to see if it meets preset rules. For example, the verification rules may include at least one of the following: identifier validity verification, type and size consistency verification, etc.

[0040] Understandably, this step, by storing the static contract in a read-only segment of Flash and performing consistency checks at runtime, ensures that each business module is rigorously reviewed during the initialization phase. This allows inconsistencies in data declarations to be exposed early in the development phase, while also avoiding reliance on external toolchains and configuration file generators.

[0041] Step S2: After the consistency verification of each static contract passes, allocate corresponding storage space in the static storage pool for the shared data items declared by each business module, and use the index of the storage space as the access index of each shared data item; wherein, the static storage pool is the storage space pre-allocated during the compilation of the microcontroller. It should be noted that after the static contract passes all the verification items, the data center in the microcontroller needs to allocate actual data storage space for each shared data item declared in the static contract, and return the location information of the storage space to the business module in the form of an index for direct use in subsequent access.

[0042] Optionally, the static storage pool is a contiguous memory region pre-allocated as a static array during the microcontroller compilation phase. Its total number of bytes is constrained by a compile-time constant upper limit, and it does not call any runtime dynamic memory allocation interfaces. This static storage pool is used to hold the actual data content of all registered shared data items.

[0043] Optionally, the storage space is a contiguous byte range partitioned on demand from the static storage pool, used to store the actual data value of a shared data item. The data center in the microcontroller allocates space of the appropriate size from the free area of ​​the storage pool according to the data type and byte length declared in the shared data item descriptor, and associates and binds this space with the logical key name, access permissions, and other information of the shared data item.

[0044] Optionally, the index is an internal array index assigned by the data center in the microcontroller to each successfully registered shared data item. It can be an integer value, used to locate the spatial position of the shared data item in the static storage pool and its associated metadata information in constant time. The index is returned to the business module in the form of a handle.

[0045] Optionally, the access index is the business-level representation of the aforementioned index. All subsequent access operations of the business module to the shared data item must provide this access index as an input parameter. The data center in the microcontroller can directly dereference the actual storage address and metadata of the shared data item through this access index without traversing queries or string comparisons.

[0046] Optionally, when allocating storage space, the data center in the microcontroller also needs to verify whether the remaining free space is sufficient to accommodate the total number of bytes required for all shared data items in the current static contract. If the space is insufficient, the entire registration of this static contract is rolled back, the allocated space is released, the data center in the microcontroller is restored to its state before registration, and a resource shortage error code is returned.

[0047] Understandably, this step eliminates the uncertainty of runtime dynamic allocation through a fully static storage pool design and indexed access handles, ensuring complete predictability of memory behavior. At the same time, the handle-based access path is a constant-time index reference, which is significantly better than string key lookup, avoiding the overhead and cache jitter caused by hashing or traversal, making it suitable for resource-constrained MCU environments.

[0048] Step S3: Based on the access permissions of each shared data item, select a target operation table that matches the access permissions for each business module from a set of preset operation tables; It should be noted that the access point exposed by the data center in the microcontroller is not a single general application programming interface, but rather divided into multiple independent operation tables. After each business module completes contract registration and obtains the access index, it needs to select the target operation table that matches its actual access requirements from these operation tables based on the access permissions of the shared data items it has declared. This allows it to subsequently read and write shared data items through the access functions provided in these operation tables.

[0049] Optionally, the operation table is a collection of related access functions exposed to the business module in the form of constant structure pointers. Each operation table focuses on a specific type of access responsibility. All operation tables are provided externally through a unified aggregate structure, and the business module can reference only the operation tables it actually uses as needed, thereby achieving minimal dependency.

[0050] Optionally, the pre-defined operation tables include at least the following: a task read operation table, providing access functions for reading scalar, structure, or reference type data items in a task context; a task write operation table, providing access functions for writing scalar, structure, or reference type data items in a task context; an interrupt read operation table, providing access functions for reading restricted scalar subsets in an interrupt service routine context; an interrupt write operation table, providing access functions for writing restricted scalar subsets in an interrupt service routine context; a lifecycle operation table, providing entry points for data center boot startup, shutdown, and reset lifecycle management, for use by the platform boot layer; a contract operation table, providing entry points for contract registration, deregistration, and querying, for use by business module initialization phases; a handle operation table, providing entry points for parsing logical key name strings into access indexes, and for retrieving logical key names from handles, for use during the initialization phase; a subscription operation table, providing entry points for data item change subscriptions and callback deregistration, for use by the monitoring and diagnostic module; and a diagnostic operation table, providing entry points for reading diagnostic counters and exporting statistical snapshots, for use by the command-line interface and health self-check module.

[0051] Optionally, the target operation table is one or more operation tables selected by the business module from the aforementioned multiple operation tables based on its declared access permissions. For example, a command-line interface module that only needs to read temperature data has access permissions that only include task-mode read permissions; therefore, the data center in the microcontroller selects the task read operation table as the target operation table for it. This command-line interface module will not introduce symbolic references to unrelated operation tables such as interrupt read, interrupt write, or subscription. As another example, a control module that needs to write configuration parameters has access permissions that include task-mode read and write permissions; therefore, the target operation table includes both the task read operation table and the task write operation table.

[0052] Understandably, this step, through the strict grouping design of the operation table, enables the scope of business module dependencies to be accurately identified at the static analysis level; the entry points of different access contexts are physically isolated, and the interrupt service routine can only use the restricted interrupt operation table and cannot misuse the task-state operation table, thereby strengthening access control and scalability at the architectural level.

[0053] Step S4: When calling the access function in the target operation table, the access index is used as the input parameter of the access function to access the shared data item in the storage space corresponding to the access index.

[0054] It should be noted that after the business module holds the access index and selects the target operation table, it can actually read or modify the value of the shared data item at runtime by calling the access function provided in the target operation table. Each access operation uses the access index as an input parameter, and the data center in the microcontroller quickly locates the storage space based on this and completes the data read / write after performing a validity check.

[0055] Optionally, access functions are interface methods with fixed function signatures defined in the target operation table. Different operation tables provide different combinations of read and write functions. For example, the task read operation table provides functions such as "read scalar value by index", "read structure content by index", and "read by index reference"; the task write operation table provides functions such as "write scalar value by index" and "write structure content by index". Each access function accepts the access index as its first input parameter, indicating the target data item to be operated on.

[0056] Optionally, when a business module calls the access function, the data center in the microcontroller, based on the passed access index, directly locates the corresponding data item record in the internal metadata table using that access index as the array index. This allows it to obtain the starting address, data length, actual type, and access permissions declared during registration for the shared data item in the static storage pool. Subsequently, the data center in the microcontroller verifies whether the current calling context (e.g., whether it is currently in task mode or interrupt service routine mode) matches the allowed access permissions for the shared data item. If the verification passes, the actual data read or write operation is performed; if the verification fails, the access is rejected and an error code is returned.

[0057] Optionally, the access index can be passed as an input parameter to the access function via pointer passing or value passing. For example, during the initialization phase, the business module resolves the logical key name "BMS voltage" to access index 0x03 and caches it in a local variable. When the task read operation table is called at runtime, this access index 0x03 is passed as an actual parameter. The data center in the microcontroller immediately locates the storage space with the specific offset in the storage pool, reads the voltage value, and returns it to the caller. The entire process does not involve string parsing, hash calculation, or linked list traversal, and has a time complexity of O(1).

[0058] Optionally, for monitoring modules that have subscribed to data item changes, when a write access function successfully modifies the value of a shared data item, the data center in the microcontroller will automatically iterate through the subscriber list corresponding to that shared data item, call the callback functions registered by each subscriber in sequence, and notify the subscribers of the change event and the new data value. This notification process is performed synchronously after the write operation is completed and shares the same access index with the business read / write path.

[0059] Understandably, this step, by using the handle-based index (i.e., the access index) as the input parameter of the access function, compresses the runtime data access path into a single index dereference plus permission verification. This approach has low overhead and exhibits predictable and reproducible execution characteristics each time it runs, making it suitable for scenarios sensitive to task cycles and interrupt response times. Simultaneously, the permission verification and notification subscription mechanisms provide additional security and observability on the main access path without significantly impacting access performance.

[0060] This embodiment provides a data access method that enables a business module in a resource-constrained MCU to declare data requirements to the data center in the MCU using a built-in static contract. After strict consistency verification and fully static resource allocation during runtime, a handle-based access index with constant time is obtained, and secure and efficient access to shared data items is completed in the correct context according to the operation table.

[0061] Specifically, each business module submits a static contract to the data center within the microcontroller during runtime, thus solidifying information such as the field layout, byte count, and access permissions of shared data items within the microcontroller in a unified contract format. Then, a consistency check is performed on each submitted static contract to ensure that the descriptions of the declared shared data items by each business module conform to preset constraints in terms of type, size, and permissions. This switches the access of shared data items by each business module from relying on its own private internal conventions to a standardized access path under the constraints of a unified contract. When any business module modifies the layout or length of its declared shared data items, the inconsistency between this modification and the original static contract is exposed during the runtime check phase, without waiting for a specific runtime path or data triggering conditions, completely eliminating the problem of the fault trigger point lagging far behind the change point. Furthermore, after all static contract consistency checks pass, this application allocates storage space for each shared data item in a pre-allocated static storage pool during compilation, using the index of the allocated storage space as the access index. During runtime, data reading and writing can be directly located using only this access index, eliminating the need for dynamic memory allocation and deallocation, thus preventing response latency risks caused by the uncertainty of dynamic allocation. Simultaneously, based on the access permissions declared in each static contract, multiple preset operation tables are used to match the target operation table corresponding to the access permissions of each business module. The task execution program and interrupt service routine each obtain an independent operation entry point adapted to their context type, no longer sharing a single general read / write interface. The business module calls the access function in the target operation table, using the access index as input parameter, to complete access to the corresponding data item in the static storage pool within a constant time. Since the operation table isolates task-accessible items from interrupt-accessible items at the interface level, the task execution program can only access the data path governed by the task operation table, and the interrupt service routine can only call a limited subset provided by the interrupt operation table. Therefore, the risks of data contention and state fragmentation do not accumulate with the increase in the number of integrated business modules. In summary, this application solves the technical problems of poor data consistency and difficulty in fault location caused by the lack of a unified contract description for shared data items in existing multi-business module collaboration scenarios, as well as the technical problem of low reliability caused by tasks and interruptions sharing a single access point.

[0062] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, before step S1, which involves obtaining multiple static contracts submitted by each business module, the following is included: During the compilation phase of the microcontroller, a static contract for the business module is constructed based on the description information of the business module and the description information of the shared data items declared by the business module. The description information of the business module includes the plug-in identifier of the business module and the number of shared data items declared; the description information of the shared data items includes the logical key name, data type, byte length, and access permissions of the shared data items.

[0063] It should be noted that during the compilation phase of the microcontroller program, based on the description information of the business module and the description information of the shared data items declared by the business module, a static contract in constant form is constructed for each business module. This static contract is fixed in the read-only data segment of the Flash memory for use during runtime registration.

[0064] Optionally, the description information of the business module includes a plugin identifier and the number of declared shared data items; wherein, the plugin identifier is a unique name of the business module in string form, used to distinguish different business modules in the data center; the number of declared shared data items is the total number of data items that the module expects to register with the data center, used to determine the length of the data item descriptor array in the static contract at compile time.

[0065] Optionally, the description information of the shared data item includes the logical key name, data type, byte length, and access permissions; wherein, the logical key name is a unique identifier of the shared data item in global scope in string form, such as "BMS_Voltage"; the data type declares the specific type of the shared data item, such as uint16_t, float, or a user-defined structure type; the byte length is the number of bytes actually occupied by the data type in the target microcontroller, such as 2 bytes for uint16_t; the access permissions declare the information of what context and how the shared data item is allowed to be accessed, specifically including task-mode read, task-mode write, interrupt service routine read, interrupt service routine write, and combinations thereof.

[0066] Optionally, during compilation, by writing a static contract structure variable modified by const, the above description information can be filled into the corresponding fields. The compiler will then allocate the static contract structure variable to a read-only area to ensure that it cannot be modified at runtime.

[0067] Understandably, this build step is completed during compilation, does not consume runtime resources, and all contract information is determined when the firmware is burned, providing a read-only reference benchmark for subsequent runtime consistency verification.

[0068] In one feasible implementation, if the plugin identifier is not empty and the identifier length of the plugin identifier does not exceed the preset naming length limit, the following verification is performed on each shared data item in the static contract according to the number of shared data items: Verify whether the logical key name exceeds the preset naming length limit; Verify whether the data type of the shared data item and the actual byte length occupied by the data item in the microcontroller are consistent with the byte length of the shared data item in the static contract; Verify whether the byte length of the shared data item exceeds the preset maximum length limit; Verify whether the access permissions of the shared data items are within the preset legal permission range; Verify whether the logical key name of the shared data item is declared by only one business module in the role of provider.

[0069] It should be noted that after the microcontroller completes its boot and basic initialization, it enters the contract registration phase during runtime. The data center sequentially receives constant pointers to the static contract objects of each business module, thereby obtaining all contract information from each business module. This acquisition process involves reading the pre-built contract structure from Flash memory and does not involve any dynamic memory allocation or data copying.

[0070] Optionally, after receiving the static contract, the data center does not directly allocate resources, but first performs a consistency check on each field in the static contract, and only after all the check items pass is the static contract considered valid.

[0071] Specifically, first check whether the plugin identifier is not empty, and whether the string length of the plugin identifier does not exceed the preset naming length limit (this limit is a compile-time constant, such as 32 bytes), in order to prevent empty identifiers or excessively long identifiers from causing subsequent string operations to go out of bounds.

[0072] Subsequently, based on the number of shared data items declared in the contract, the following checks are performed on each item: The logical key name is checked to ensure that it is not empty and that its string length does not exceed the preset naming length limit. This ensures that each data item has a valid and length-controlled global name. When the name is empty, a placeholder can be used, and the string length of the placeholder will be calculated. Verify whether the data type declared in the static contract for the shared data item and the actual byte length occupied on the target microcontroller platform are consistent with the byte length field explicitly filled in the contract. For example, if the data type is uint32_t (unsigned 32-bit integer), it usually occupies 4 bytes on the Cortex-M platform. Then the byte length in the contract must be 4. Otherwise, it means that the description information does not match the actual type, which is a development error. Verify whether the byte length of the shared data item does not exceed the preset maximum length limit (e.g., 256 bytes). This limit is used to constrain the size of a single structure or reference type data item to prevent excessively large structures from crowding out limited data pool resources. Verify whether the access permission enumeration value of the shared data item is within the preset legal permission range. For example, only predefined task read, task write, interrupt read, interrupt write and their legal combinations are allowed. If an illegal enumeration value is passed, the verification will fail. Verify whether the logical key name was declared by a business module as a provider. That is, the data center maintains a mapping table between registered logical key names and provider plugin identifiers. If a logical key name in the current contract already exists in the mapping table and the provider role of the logical key name has been declared by another business module, then duplicate provider declarations of the logical key name will be rejected, thereby ensuring that each shared data item has a unique source definer in the global scope.

[0073] All of the above checks are executed sequentially by the data center during runtime. If any check fails, the contract is deemed invalid. All of the above checks can be considered as consistency checks on static contracts.

[0074] In one feasible implementation, after step S2, the step of performing consistency verification on each of the static contracts includes: If any check fails, the consistency check of the static contract is deemed to have failed, and storage space is refused to be allocated for the shared data items in the static contract, thereby preventing access to the shared data items through the access functions in the target operation table.

[0075] It should be noted that if any of the above checks fails, the consistency check of the current static contract is deemed to have failed. In this case, storage space will not be allocated for any shared data items of the current static contract, and no valid access index will be returned to the business module.

[0076] Among them, any failure of the validation includes at least: the plugin identifier is empty or the length exceeds the limit, the plugin identifier string pointer in the static contract is empty (NULL), or its actual length (excluding the terminator) exceeds the maximum naming length limit preset at compile time (e.g., 32 bytes), which leads to the risk of out-of-bounds operation in subsequent string operations.

[0077] The logical key name is empty or exceeds the length limit. The logical key name pointer of the current shared data item is empty, or its length exceeds the naming length limit, so it cannot be securely stored and compared as a globally unique identifier.

[0078] The actual number of bytes occupied by the data type is inconsistent with the declared number of bytes. The number of bytes actually occupied by the shared data item on the target microcontroller (determined by the compiler according to the data type, for example, uint32_t is 4 bytes) is not equal to the value of the byte length field filled in the contract. This indicates that the size was mistakenly filled in when constructing the contract, which may lead to a length mismatch during subsequent memory copying.

[0079] If the length of a data item exceeds the preset maximum length limit, or if the length of the data item declared in the contract (regardless of whether it is consistent with the type) exceeds the maximum allowed size of a single data item defined at compile time (e.g., 256 bytes), it means that the data item (especially a structure or reference type) is too large and may occupy limited data pool resources.

[0080] Access permissions are not within the legal scope. The access permissions declared for the currently shared data item (such as a combination of task read / write and interrupt read-only) do not belong to the predefined set of legal enumeration values, or the role enumeration (provider, consumer, converter) is an illegal value, which cannot be recognized and authorized by the data center. For example, a shared data item may be declared as a reference type (i.e., a handle pointing to other data items), but its access permissions allow read and write operations in the interrupt service routine context. However, it is strictly stipulated that reference types can only be accessed in task mode to avoid the uncertainty caused by indirect modification in the interrupt context.

[0081] The same logical key name has already been declared by another provider: The data center maintains a mapping relationship between logical key names and the plug-in identifiers of currently registered business modules. If a logical key name in the current static contract already exists in this mapping table, and the provider role of that logical key name has been registered by another business module, then the current contract's attempt to declare the same logical key name again as a provider violates the "unique provider constraint".

[0082] At the same time, all temporary states that may have occurred during this registration attempt (such as recorded plugin identifier query traces) will be rolled back, restoring the microcontroller to the state before the start of this registration, and returning an error code that indicates the specific type of failed verification item (such as "key name too long", "type size mismatch", "duplicate provider", etc.).

[0083] Since storage space has not been allocated, business modules are unable to read or write shared data items in the static contract through any access functions in the operation table, thus preventing potential memory out-of-bounds issues, type confusion, or uncontrolled access permissions caused by inconsistent data descriptions at runtime.

[0084] Understandably, this rejection policy ensures that the resource status of the data center remains consistent with the set of verified contracts, avoiding intermediate states of partial allocation and partial failure, and enhancing reliability and the determinism of the overall status.

[0085] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Furthermore, before step S1, which involves obtaining multiple static contracts submitted by each business module, the following method is also included: During the compilation phase of the microcontroller, the various access functions in the microcontroller are classified into different operation tables according to the running context type, access operation type, and functional role when each business module accesses data, resulting in multiple preset operation tables; wherein, the multiple operation tables include a task read operation table, a task write operation table, an interrupt read operation table, an interrupt write operation table, and a handle resolution operation table.

[0086] It should be noted that the classification and categorization of operation tables is completed during compilation. When writing code, functions that implement different access functions are placed into the corresponding operation table structures according to predefined classification rules. Each operation table is a collection of function pointers organized in the form of constant pointers. The whole table is allocated in the read-only data segment of Flash and cannot be modified at runtime.

[0087] Optionally, the runtime context type is the CPU execution environment in which the access function is called, including at least the task context (i.e., the context directly called by the RTOS task function, or by adding a task executor) and the interrupt context (i.e., the context triggered by the interrupt service routine). Different contexts have different requirements for the real-time performance and security of data access. For example, blocking operations are not allowed in the interrupt context, and it is not advisable to access structure variables whose byte size exceeds the data width (usually 4 or 8 bytes) that can be atomically operated on by a single load / store instruction of the microcontroller. Therefore, they need to be isolated during classification.

[0088] Optionally, the access operation type refers to the specific type of operation performed on the shared data item, including at least read and write operations; the read operation is used to obtain the current value of the shared data item from the storage space, and the write operation is used to write the new value to the storage space and trigger the subsequent subscription notification mechanism.

[0089] Optionally, the functional role is defined by the responsibilities undertaken by the operation table. It can be a converter, consumer, or producer. For example, it can be a function to convert logical key names to access indexes for use by business modules during the initialization phase, a subscription management function for use by the monitoring and diagnostic module, or a lifecycle management function for use by the platform bootstrapping layer. Different functional roles serve the system requirements at different stages, and classification makes it easier for business modules to reference them as needed.

[0090] Optionally, the multiple operation tables include at least a task read operation table (task_read), which includes all access functions that perform read operations in the task context, such as functions for reading scalar values ​​by access index, reading structure content, and dereferencing reads, for use by ordinary business tasks; a task write operation table (task_write), which includes all access functions that perform write operations in the task context, such as functions for writing scalar values ​​by access index and writing structure content, for use by configuration and control business tasks; and an interrupt read operation table (isr_read), which includes all functions that perform read operations during interrupt service. The program context includes access functions that perform read operations, but only allow reading of scalar data items, not providing access points for reading structures or reference types, to meet the strict execution time requirements of the interrupt context; the interrupt write operation table isr_write, which includes all access functions that perform write operations in the interrupt service routine context, and is also only open to scalar data items, used to update sensor sampling values ​​or status flags in the interrupt; the handle resolution operation table handle, which includes conversion functions from logical key name strings to access indices and auxiliary functions for looking up logical key names from access indices.

[0091] Optionally, during the operation of the microcontroller, each of the operation tables is selected as the target operation table that matches the access permission of each of the shared data items.

[0092] Optionally, in addition to the operation tables mentioned above, multiple operation tables may also include a lifecycle operation table (which includes system-level management functions such as booting, shutdown, and reset), a contract operation table (which includes management functions such as contract registration, cancellation, and query), a subscribe operation table (which includes functions such as data change subscription and callback cancellation), and a diagnostic operation table (which includes functions such as diagnostic counter reading and statistical snapshot export), forming a nine-way operation table set.

[0093] Understandably, this compile-time classification and grouping step physically isolates access functions into different operation table structures according to three dimensions: runtime context, operation type, and functional role, during the code writing phase. This ensures that the access points exposed by the data center are clearly grouped at compile time. Runtime business modules can only reference their assigned target operation table and cannot call other access functions not included in the target operation table. This achieves separation of responsibilities, minimal dependencies, and scalability at the architectural level, while avoiding the uncertainty and overhead caused by runtime dynamic lookups or conditional branches.

[0094] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, before step S2, the step of allocating corresponding storage space in the static storage pool for the shared data items declared by each of the business modules after the consistency verification of each of the static contracts has passed, includes: Step A21: Calculate the total number of bytes of storage space required for all shared data items in the plurality of static contracts, and compare the total number of bytes of storage space with the available space of the static storage pool; It should be noted that after the data center confirms that the currently submitted static contract has passed all consistency checks, before entering the resource allocation phase, the storage space of all shared data items declared in the contract must first be calculated.

[0095] Optionally, the description information of each shared data item in the current static contract is traversed, its byte length field is read, and the byte lengths of all shared data items in the current static contract are summed to obtain the total number of bytes of storage space required by the current static contract. If this registration is a single contract registration (i.e., each registration entry call processes only one static contract), then the total number of bytes of storage space is the sum of the sizes of all shared data items in the contract; if this registration is a batch contract submission, then the sizes of the shared data items of all contracts to be registered need to be merged and summed.

[0096] Optionally, the available space of the static storage pool is the number of free bytes that are not currently occupied by registered data items. The data center maintains an allocated byte offset pointer or a remaining byte counter to track the storage pool's occupancy in real time. After calculating the total number of bytes of storage space, the data center compares it with the available space to determine whether the new demand is within the capacity of the remaining storage.

[0097] Understandably, this comparison step is performed before the storage pool is actually allocated, or it can be checked while allocating, which can detect insufficient space and roll back in time.

[0098] Step A22: When the total number of bytes in the storage space is less than or equal to the available space, perform the step of allocating corresponding storage space in the static storage pool for the shared data items declared by each of the business modules. It should be noted that if the comparison result of step A21 shows that the total number of bytes in the storage space is less than or equal to the available space, it indicates that the remaining capacity of the static storage pool is sufficient to accommodate the actual data content of all shared data items in the current static contract. In this case, the data center approves the resource allocation request and enters the actual partitioning and binding process of the storage space.

[0099] Optionally, the data center, following the declaration order of shared data items in the contract, sequentially allocates a contiguous memory range equal in byte length to each data item from the current free starting address of the static storage pool. Each range serves as the storage space for the corresponding data item. Simultaneously, the data center assigns an access index to each data item. This index records the starting offset and length information of the data item within the storage pool, and associates this index with metadata such as the data item's logical key name, type, and access permissions, storing it in an internal management table. Subsequently, the data center updates the available space counter (subtracting the total number of allocated bytes) and returns the actual starting address of the storage space and the access index to the business module for subsequent data read / write operations via access functions in the target operation table.

[0100] Understandably, since the pre-comparison has confirmed that there is sufficient space, the allocation process can be completed within a constant amount of time, and there will be no abnormal situation of failure in the middle of the allocation, thus ensuring the determinism and atomicity of resource allocation.

[0101] Step A23: When the total number of bytes in the storage space is greater than the available space, cancel the executed storage space allocation operation and roll back the static storage pool to its initial state.

[0102] It should be noted that if the comparison result of step A21 shows that the total number of bytes in the storage space is greater than the available space, it indicates that the remaining capacity of the static storage pool is insufficient to carry the actual data content of all shared data items in the current static contract. In this case, the data center will reject this registration request.

[0103] Optionally, canceling the executed storage space allocation operation is as follows: if some space allocation has been performed before the comparison (for example, some data items may have been allocated in a process without pre-check), the data center needs to release all the allocated storage space. Specifically, the allocated byte offset pointer or remaining byte counter is restored to the value before the start of this registration, and all access indexes and metadata entries recorded in the internal management table are removed.

[0104] Optionally, rolling back the static storage pool to its initial state means restoring the allocation state of the static storage pool to a consistent state before the registration operation was triggered. This ensures that regardless of whether the registration succeeds or fails, the occupancy of the static storage pool always strictly corresponds to the set of contracts that have passed verification and successfully registered, leaving no residual traces of any partial allocation. After completing the rollback, the data center returns a resource shortage error code to the business module, indicating to the caller that the current system capacity has reached its limit or that the scale of this contract declaration is too large.

[0105] Understandably, this step maintains strong consistency between the static storage pool state and the set of registered contracts through a complete rollback mechanism in case of failure, avoiding resource leaks or state asynchrony problems caused by partial allocation or partial failure, and making the system's resource management behavior completely deterministic and predictable.

[0106] In one feasible implementation, all resources required for data center operation are defined as static arrays, without calling any dynamic allocation APIs. The scale of the aforementioned resources is constrained by compile-time constant upper limits, and during the compilation phase, logical constraints between constants are automatically verified through static assertions (e.g., the number of shared data items that can be declared in a single static contract does not exceed the global maximum number of simultaneously existing shared data items, the maximum length of logical key names does not exceed the internal buffer size, etc.) to ensure that the upper limit configuration itself is consistent. Specifically, the compile-time constant upper limit constraints include: the global maximum number of simultaneously existing shared data items, the maximum number of shared data items that can be declared in a single static contract, the total number of bytes in the static storage pool used to carry the actual data content of each shared data item, the global maximum number of slots for subscription relationships, the upper limit on the number of subscribers that can be attached to a single shared data item, the maximum length of the logical key name string, the maximum length of the plugin identifier string, and the maximum number of bytes of a single shared data item.

[0107] In one feasible implementation, after the step of accessing the shared data item in the storage space corresponding to the access index by calling the access function in the target operation table and taking the access index as the input parameter of the access function, the method includes: In the shutdown or test state of the microcontroller, a lifecycle operation table is determined from a number of preset operation tables. By calling the reset function in the lifecycle operation table, a global reset operation is performed on each of the shared data items that have passed the consistency check and have been allocated storage space, releasing the storage space occupied by each of the shared data items and clearing the access index corresponding to each of the shared data items.

[0108] It should be noted that during operation, there are scenarios where it is necessary to restore the entire data center of the microcontroller to its initial state without data. For example, embedded products may need to execute multiple independent test cases in a loop when entering factory testing mode, or deterministic resource cleanup may be required during controlled shutdown to ensure a safe restart later. In these situations, the system enters a shutdown or test state. In both states, normal data read and write operations of the business modules are suspended or no longer initiated, and global-level resource reclamation operations can be performed.

[0109] Optionally, the shutdown state is the system operation phase in which the normal task scheduling of the microcontroller has stopped and all business tasks have been suspended or destroyed. For example, it is the final stage of the system executing a controlled shutdown process, or the moment when the runtime state needs to be cleaned up before the Bootloader (a startup program) jumps to the application.

[0110] Optionally, the test state is a special operating phase in which the microcontroller runs in factory test mode or unit test framework. In this phase, test cases need to repeatedly execute an independent registration-access-verification sequence. It is required that the data center is in a clean initial state at the beginning of each test and is not affected by residual data from the previous test.

[0111] Optionally, the lifecycle operation table can be determined from among multiple preset operation tables as follows: the aggregated operation table structure exposed by the data center includes a separate operation table group called the lifecycle operation table. When a global reset is required, its entry point is obtained by referencing a constant pointer to this operation table. The lifecycle operation table is one of the preset operation tables, which contains system-level management functions such as boot startup, normal shutdown, and forced reset, and is responsible for the overall lifecycle state transitions. This operation table is defined and allocated in the Flash read-only segment during compilation.

[0112] Optionally, the reset function is a specific interface method provided in the lifecycle operation table for performing global data cleanup. For example, when calling the reset function, the system does not pass any data item-specific parameters because its scope is all registered data items, not just a single data item. After the reset function is called, the following operations are performed sequentially: First, it iterates through all registered shared data item records in the data center's internal management table, unbinding each one from the storage space in the static storage pool; second, it restores the available space counter or allocated byte offset pointer of the static storage pool to its initial value (i.e., the value when the system has just finished booting and has not yet registered any contracts), logically releasing all previously allocated data item storage space so that subsequent new contract registrations can re-allocate from the beginning of the storage pool; third, it clears all access index records stored in the internal management table, invalidating all access indexes previously distributed to various business modules, and any subsequent attempts to use these invalidated indexes for data access will be rejected by the data center; finally, if there are registered subscription relationships, it also clears the callback function pointers in all subscription slots to ensure that there are no dangling callback references after the global reset. The entire reset process does not call any dynamic memory release interfaces because all resources are statically allocated arrays at compile time. The reset operation simply writes the status counter and management table contents back to their initial values.

[0113] Understandably, the global reset step in this shutdown or test state provides the ability to complete all cleanup in a deterministic single call through the reset function in the lifecycle operation table. This ensures that the static storage pool and management table can reliably recover to their initial consistent state between system shutdowns or test cycles, avoiding the tediousness and risk of omissions associated with manually cleaning up each data item one by one. At the same time, since the reset operation only involves assigning values ​​to state variables and resetting counters, without releasing dynamic memory, its execution time overhead is deterministic and controllable, making it suitable for embedded scenarios with requirements for shutdown delays or test turnaround times.

[0114] For example, to help understand the implementation flow of the data access method obtained by combining this embodiment with the above embodiments, please refer to... Figure 2 , specifically: During the runtime of the microcontroller, multiple business modules (such as business modules A, B, ... N) submit their static contracts, which were built during compilation, to the microcontroller's data center. Each static contract declares the shared data items required by the business module and their corresponding access permissions.

[0115] Upon receiving the static contract, the data center first performs a consistency check. The check items include, but are not limited to: whether the plug-in identifier and logical key name exceed the preset naming length limit; whether the actual byte length occupied by the data type of the shared data item in the microcontroller matches the byte length declared in the contract; whether the access permissions of the shared data item are within the preset legal range; and whether the logical key name is declared by only one business module as a "provider" (unique provider constraint). If any check fails, registration is directly rejected.

[0116] Once the consistency checks of the static contract pass, the data center allocates corresponding actual storage space for each shared data item declared by each business module in the static storage pool pre-allocated during compilation. Before allocation, the remaining space is compared; if the space is insufficient, a full rollback is triggered.

[0117] After successful allocation, the data center uses the array index of the allocated storage space in its internal management table as an access index (handle) and returns it to the corresponding business module. The business module then caches this access index locally.

[0118] Based on the specific access permissions declared in its static contract (e.g., whether it is task-mode read / write or interrupt-mode read / write), the business module selects the target operation table (such as task read operation table, task write operation table, interrupt read operation table, etc.) that matches its access permissions from multiple operation tables (nine-way operation tables) preset by the data center.

[0119] During runtime, the business module directly calls the access function provided in the target operation table and passes the previously cached access index as an input parameter to the access function.

[0120] Based on the incoming access index, the data center directly locates the corresponding storage space in the static storage pool in constant time, such as O(1), so that the business module can complete the final read or write operation on the shared data item.

[0121] Through the above process, this application abandons the traditional string key lookup and dynamic memory allocation, realizes predictable constant-time data access, and fundamentally solves the data consistency problem and task / interruption access conflict problem in the collaboration of multiple business modules through strong contract verification at runtime and separation of responsibilities of operation table.

[0122] For example, to help understand the implementation flow of the data access method obtained by combining this embodiment with the above embodiments, please refer to... Figure 3 , specifically: Figure 3 The image shows the timing interaction process after the business module submits a static contract to the microcontroller's data center: Submitting a static contract: During the startup initialization phase, the business module submits its static contract descriptor, which was constructed and fixed in the Flash read-only area during compilation, through the registration portal provided by the data center.

[0123] The data center performs runtime consistency checks: Upon receiving the static contract, the data center first performs a consistency check on the static contract. The check mainly includes: checking whether the string length of the plug-in identifier and logical key name exceeds the preset naming length limit; checking whether the actual byte length occupied by each shared data item on the microcontroller is consistent with the byte length declared in the contract; checking whether the access permissions (task read / write, interrupt read / write) of the shared data item are within the legal range; and verifying whether the logical key name of the shared data item is declared by only one business module as a "provider" (i.e., unique provider constraint).

[0124] Verification Result Return: After completing all the above verification items, the data center will send a "pass" or "fail" result back to the business module. If the verification fails, the registration will be rejected directly, preventing subsequent memory allocation and access operations.

[0125] Allocation and return upon successful verification: Provided that the consistency verification passes, the data center will calculate the total number of bytes required for all shared data items in the static contract and compare it with the current remaining available space in the static storage pool.

[0126] When the static storage pool has sufficient space (normal branch): The data center allocates actual storage space for each shared data item in the pre-allocated static storage pool, records the array index of the storage space as the access index (i.e., handle) of the shared data item, and returns the access index to the business module. After receiving the access index, the business module caches it in a local variable. Subsequently, during runtime, it only needs to use the access index to achieve low-level data access in constant time, such as O(1), without having to perform time-consuming string key comparisons.

[0127] Rollback and Error Reporting When Static Storage Pool Space is Insufficient (Exception Branch): If the total required bytes exceed the remaining available space in the static storage pool, the data center will trigger a rollback operation. During the rollback, the data center will undo any temporary state changes caused by this contract registration (such as attempted pre-allocations) to ensure that the static storage pool state remains strictly consistent with the set of successfully registered contracts. After a complete rollback, the data center returns an "insufficient resources" error code to the business module.

[0128] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the data access method of this application. Any simple variations based on this technical concept, such as the interaction and combination of various embodiments, are all within the protection scope of this application.

[0129] This application also provides a data access device, please refer to... Figure 4 Applied to microcontrollers, the data access device includes: The acquisition module 10 is used to acquire multiple static contracts of each business module during the operation of the microcontroller and to perform consistency verification on each static contract; wherein, the static contract includes the shared data items declared by the business module and the access permissions of the shared data items; The allocation module 20 is used to allocate corresponding storage space in the static storage pool for the shared data items declared by each business module after the consistency verification of each static contract has passed, and to use the index of the storage space as the access index of each shared data item; wherein, the static storage pool is the storage space pre-allocated during the compilation of the microcontroller; The selection module 30 is used to select a target operation table that matches the access permissions of each of the shared data items from a plurality of preset operation tables for each of the business modules. The access module 40 is used to access the shared data item in the storage space corresponding to the access index by using the access index as the input parameter of the access function when calling the access function in the target operation table.

[0130] The data access device provided in this application, employing the data access method described in the above embodiments, can solve the technical problems of poor data consistency and low reliability in existing multi-service module collaboration scenarios. Compared with the prior art, the beneficial effects of the data access device provided in this application are the same as those of the data access method provided in the above embodiments, and other technical features in the data access device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0131] This application provides a microcontroller, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the data access method described in the first embodiment above.

[0132] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a microcontroller suitable for implementing the embodiments of this application. The microcontroller in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The microcontroller shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0133] like Figure 5As shown, the microcontroller may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the microcontroller. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the microcontroller to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows microcontrollers with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0134] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0135] The microcontroller provided in this application, employing the data access method described in the above embodiments, can solve the technical problems of poor data consistency and low reliability in existing multi-service module collaboration scenarios. Compared with the prior art, the beneficial effects of the microcontroller provided in this application are the same as those of the data access method provided in the above embodiments, and other technical features of this microcontroller are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0136] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0137] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0138] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the data access method described in the above embodiments.

[0139] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0140] The aforementioned computer-readable storage medium may be included in the microcontroller; or it may exist independently and not be assembled into the microcontroller.

[0141] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0142] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0143] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0144] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described data access method. This addresses the technical problems of poor data consistency and low reliability in existing multi-service module collaboration scenarios. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the data access method provided in the above embodiments, and will not be elaborated upon here.

[0145] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data access method described above.

[0146] The computer program product provided in this application can solve the technical problems of poor data consistency and low reliability in existing multi-business module collaboration scenarios. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the data access method provided in the above embodiments, and will not be repeated here.

[0147] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A data access method, characterized in that, Applied to microcontrollers, the data access method includes: During the operation of the microcontroller, multiple static contracts of each business module are obtained, and consistency verification is performed on each static contract; wherein, the static contract includes the shared data items declared by the business module and the access permissions of the shared data items; After the consistency verification of each static contract passes, the corresponding storage space is allocated in the static storage pool for the shared data items declared by each business module, and the index of the storage space is used as the access index of each shared data item; wherein, the static storage pool is the storage space pre-allocated during the compilation of the microcontroller; Based on the access permissions of each shared data item, a target operation table matching the access permissions is selected from a plurality of preset operation tables for each business module; When calling the access function in the target operation table, the access index is used as the input parameter of the access function to access the shared data item in the storage space corresponding to the access index.

2. The method as described in claim 1, characterized in that, Before the step of obtaining multiple static contracts submitted by each business module, the following is included: During the compilation phase of the microcontroller, a static contract for the business module is constructed based on the description information of the business module and the description information of the shared data items declared by the business module. The description information of the business module includes the plug-in identifier of the business module and the number of shared data items declared; the description information of the shared data items includes the logical key name, data type, byte length, and access permissions of the shared data items.

3. The method as described in claim 2, characterized in that, If the plugin identifier is not empty and the identifier length of the plugin identifier does not exceed the preset naming length limit, perform the following checks on each shared data item in the static contract according to the number of shared data items: Verify whether the logical key name exceeds the preset naming length limit; Verify whether the data type of the shared data item and the actual byte length occupied by the data item in the microcontroller are consistent with the byte length of the shared data item in the static contract; Verify whether the byte length of the shared data item exceeds the preset maximum length limit; Verify whether the access permissions of the shared data items are within the preset legal permission range; Verify whether the logical key name of the shared data item is declared by only one business module in the role of provider.

4. The method as described in claim 3, characterized in that, Following the step of performing consistency verification on each of the static contracts, the following is included: If any check fails, the consistency check of the static contract is deemed to have failed, and storage space is refused to be allocated for the shared data items in the static contract, thereby preventing access to the shared data items through the access functions in the target operation table.

5. The method as described in claim 1, characterized in that, Before the step of obtaining multiple static contracts submitted by each business module, the method further includes: During the compilation phase of the microcontroller, the various access functions in the microcontroller are classified into different operation tables according to the running context type, access operation type, and functional role when each business module accesses data, resulting in multiple preset operation tables; wherein, the multiple operation tables include a task read operation table, a task write operation table, an interrupt read operation table, an interrupt write operation table, and a handle resolution operation table.

6. The method as described in claim 1, characterized in that, Before the step of allocating corresponding storage space in the static storage pool for the shared data items declared by each of the business modules after the consistency verification of each of the static contracts has passed, the following steps are included: Calculate the total number of bytes of storage space required for all shared data items in the plurality of static contracts, and compare the total number of bytes of storage space with the available space of the static storage pool; When the total number of bytes in the storage space is less than or equal to the available space, the step of allocating corresponding storage space in the static storage pool for the shared data items declared by each of the business modules is executed. When the total number of bytes in the storage space exceeds the available space, the executed storage space allocation operation is revoked, and the static storage pool is rolled back to its initial state.

7. A data access device, characterized in that, Applied to microcontrollers, the data access device includes: The acquisition module is used to acquire multiple static contracts of each business module during the runtime of the microcontroller and perform consistency verification on each static contract; wherein, the static contract includes the shared data items declared by the business module and the access permissions of the shared data items; The allocation module is used to allocate corresponding storage space in the static storage pool for the shared data items declared by each of the business modules after the consistency verification of each of the static contracts has passed, and to use the index of the storage space as the access index of each of the shared data items; wherein, the static storage pool is the storage space pre-allocated during the compilation of the microcontroller; The selection module is used to select a target operation table that matches the access permissions of each of the shared data items from a plurality of preset operation tables for each of the business modules. The access module is used to access the shared data item in the storage space corresponding to the access index by using the access index as the input parameter of the access function when calling the access function in the target operation table.

8. A microcontroller, characterized in that, The microcontroller includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data access method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the data access method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the data access method as described in any one of claims 1 to 6.

Images