A hardware device management system based on a resource sovereignty model and a control method thereof

Abstract

The application provides a hardware device management system based on a resource sovereignty model and a control method thereof, and belongs to the technical field of embedded systems; the application constructs a device type track data structure, each device type track contains an instance occupation bitmap and a plurality of device instance slots, the device instance slot contains an interrupt service function pointer field, an owner identification field and a user context field; a processor takes a function pointer as an owner identification, executes occupation operation, release operation and ownership query operation through combination verification of a bit and the owner identification field, supports anonymous and named occupation; in response to a hardware interrupt, a device instance slot is directly positioned through a device type and an instance index, and an interrupt service function is called; the application realizes explicit management of a hardware peripheral occupation state and a life cycle in a lightweight embedded environment without an operating system, eliminates resource conflicts caused by multi-module concurrent access, and solves the contradiction between interrupt request uniqueness and software layered design.

Description

Technical Field

[0001] This invention relates to the field of embedded system technology, and in particular to a hardware device management system and control method based on a resource sovereignty model. Background Technology

[0002] In embedded systems, software business logic typically requires various hardware peripherals to interact with the outside world or perform physical control functions. Common hardware peripherals include serial communication interfaces (such as UART, SPI, and I2C), timer modules, DMA modules, and ADC modules. These hardware peripherals are managed centrally by the processor's internal controller and their functions are accessible to the software through register interfaces.

[0003] Due to size and space constraints in embedded systems, the number of pins available on a central processing unit (CPU) chip is limited. A single pin often needs to support multiple peripheral functions, or the same peripheral can be mapped to multiple optional pin combinations. In actual product development, the same product line typically needs to adapt to different hardware platforms, with differences mainly in chip type and package type. When the hardware topology changes, the mapping relationships between software business functions and peripherals, and between peripherals and specific physical pins, all need to be adjusted synchronously. Existing technologies typically use macro definitions for adaptation, requiring re-verification of the correctness of all related functional modules with each physical interface adjustment, resulting in a large workload and a high risk of introducing difficult-to-diagnose errors.

[0004] More critically, in the existing architecture, the usage relationships of physical resources lack an explicit management mechanism; their "ownership" is implicitly determined by software configuration and runtime status. When multiple software modules access the same physical peripheral at different stages of operation, function switching may be achieved by directly configuring or reinitializing the peripheral. This operation relies on the developer's manual control over the execution order. In multi-threaded or concurrent task systems, due to the uncertainty of execution timing, hardware-level failures such as accidental overwriting of peripheral configurations, data transmission and reception errors, or even system deadlock may occur. This problem is particularly prominent for critical shared resources such as DMA, significantly increasing the technical difficulty of system debugging and maintenance.

[0005] Furthermore, IRQs (Interrupt Requests) in embedded systems have a uniqueness requirement, meaning each interrupt number can only correspond to one interrupt service routine entry point. However, the principle of layered software design requires decoupling business logic from the underlying hardware, making the separation of interrupt management in the underlying hardware from business logic difficult. One existing approach is to directly write the interrupt service routine in the business module, but this can lead to compilation conflicts when multiple modules share the same interrupt entry point. Another approach is to set dispatch logic in the IRQ, calling different user interrupt service functions based on the runtime context. However, this approach only achieves interrupt entry point reuse and does not solve the problem of unified management of peripheral resources; peripheral initialization configuration and state consistency still rely on manual maintenance.

[0006] To address the aforementioned issues, some existing technologies attempt to solve them from different angles. For example, Hardware Abstraction Layer (HAL) technology masks the differences in registers between different chips by adding an abstraction layer between business logic and registers. However, this method only abstracts the hardware access interface and does not manage the usage relationships and lifecycle of hardware resources. RTOS-provided synchronization mechanisms such as mutexes and semaphores can handle resource access conflicts in concurrent environments, but they only synchronize the access process and do not involve unified management of resource configuration states and ownership. When multiple tasks time-share the same UART and configure it with different baud rates, the system cannot automatically detect configuration conflicts, which may lead to communication failures. The Linux device driver model provides complete device lifecycle management, but it depends on a complete operating system environment, incurs significant resource overhead, and is difficult to directly apply to resource-constrained or high-real-time embedded systems. Static configuration schemes require all resources to be determined at compile time and do not allow dynamic changes at runtime, resulting in insufficient flexibility.

[0007] In summary, existing technologies either focus on interface abstraction, or on synchronous control of concurrent access, or rely on heavy operating systems. As a result, in bare metal or high real-time systems, the dynamic management of hardware resources still depends on the experience of developers for manual maintenance, making it difficult to guarantee system reliability and maintainability. Summary of the Invention

[0008] To address the aforementioned technical problems, this invention provides a technique for uniformly describing, explicitly managing, and controlling the ownership and lifecycle of physical hardware peripherals in a lightweight embedded environment. It aims to solve existing embedded systems where hardware topology changes necessitate manual maintenance of peripheral mapping relationships, and the lack of explicit resource ownership management mechanisms leads to unexpected register overwriting and data corruption during concurrent access by multiple modules. Furthermore, it addresses the contradiction between the uniqueness of hardware interrupt requests and layered software design, and the inability of existing resource management schemes to uniformly and dynamically manage the occupancy status and lifecycle of hardware peripherals in bare-metal or high-real-time environments, either by controlling the access process or relying on heavy operating systems.

[0009] To achieve the above objectives, this application proposes a hardware device management system based on a resource sovereignty model, comprising: The processor and memory, wherein the memory stores a data structure for at least one device type track, each device type track corresponding to a type of hardware peripheral, including an instance occupancy bitmap and multiple device instance slots; each bit in the instance occupancy bitmap is used to indicate the occupancy status of the corresponding hardware peripheral instance; each device instance slot includes an interrupt service function pointer field, an owner identifier field and a user context field; The processor is configured to: In response to a hardware peripheral's request to occupy or release, an occupation or release operation is performed based on the bit in the instance's occupation bitmap and the owner identifier field, using a function pointer as the owner identifier. In response to an ownership query request, the resource status is returned based on the bits in the instance occupancy bitmap and the owner identifier field. The resource status includes unowned resources, anonymous owned resources, named resources with the same owner, and named resources with different owners. In response to a hardware interrupt, the hardware status register is read to obtain the interrupt source identifier. The corresponding device instance slot is located directly according to the device type and instance index associated with the interrupt source. The interrupt service function is called through the interrupt service function pointer in the device instance slot, and the interrupt source identifier and the user context field are passed to the interrupt service function.

[0010] As a further solution, each bit in the instance occupancy bitmap corresponds one-to-one with the index of the plurality of device instance slots. A bit value of 1 indicates that the hardware peripheral instance has been occupied, and a bit value of 0 indicates that the hardware peripheral instance is idle.

[0011] As a further solution, the processor determines ownership by comparing the function pointer address stored in the owner identifier field with the function pointer address passed in by the requester.

[0012] As a further solution, when the processor performs an occupancy operation, it is configured as follows: Read the device instance slot corresponding to the hardware peripheral instance specified by the requester, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap; If the bit indicates that the space is free, then the bit is set to 1, and the owner identifier field is set to the function pointer passed in by the requester to achieve named occupancy, or set to a null pointer to achieve anonymous occupancy; If the bit indication is occupied and the owner identifier field is a null pointer, then overwriting and updating the owner identifier field upon request is allowed, or the null pointer can be retained. If the bit indicates that the bit is occupied and the owner identifier field is not empty, and the owner identifier field is the same as the function pointer passed by the requester, then the occupied status is returned or the occupation is considered successful. If the bit indicates that the bit is already occupied and the owner identifier field is not empty, and the owner identifier field is different from the function pointer passed in by the requester, then the occupancy request is rejected.

[0013] As a further solution, when the processor performs a release operation, it is configured to: Read the device instance slot corresponding to the hardware peripheral instance specified by the requester, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap; If the bit indicates that it is already occupied, and the owner identifier field is a null pointer, or the owner identifier field is the same as the function pointer passed in by the requester, then the bit is cleared and the owner identifier field is set to a null pointer; otherwise, the release is refused.

[0014] As a further solution, when the owner identifier field of a device instance slot is a null pointer, but the corresponding bit of the device instance slot in the instance occupancy bitmap is 1, the corresponding hardware peripheral instance is in an anonymous occupancy state; in the anonymous occupancy state, the processor accepts the requester's occupancy or release operation of the current hardware peripheral instance.

[0015] On the other hand, the present invention also provides a control method for embedded system hardware peripherals, applied in a hardware device management system based on a resource sovereignty model as described in any of the preceding claims, the control method comprising: The processor receives a request to occupy a hardware peripheral instance specified by the requester, the request carrying an owner identifier in the form of a function pointer; The processor reads the device instance slot corresponding to the hardware peripheral instance, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap; When the bit indicates that the device is free, the processor sets the bit to 1 and sets the owner identifier field to the function pointer or null pointer carried in the occupancy request to complete the named or anonymous occupancy. When the bit indication is occupied and the owner identifier field is a null pointer, the processor allows overwriting and updating or maintaining the owner identifier field accordingly; When the bit indicates that the device is occupied and the owner identifier field is not empty and is the same as the function pointer carried in the occupancy request, the processor returns the occupied status or considers the occupancy successful. The processor rejects the occupancy request when the bit indicates that the occupancy is already occupied and the owner identifier field is not empty and is different from the function pointer carried in the occupancy request; In response to a hardware interrupt, the processor reads the hardware status register to obtain the interrupt source identifier, determines the device type and instance index based on the interrupt source, directly locates the corresponding device instance slot, reads the interrupt service function pointer and user context field in the device instance slot, and calls the interrupt service function with the interrupt source identifier and the user context field as parameters.

[0016] As a further solution, it also includes: The processor receives a release request for the hardware peripheral instance specified by the requester; When the device instance slot corresponding to the hardware peripheral instance is occupied as indicated by a bit in the instance occupancy bitmap, and the owner identifier field is a null pointer or the same as the function pointer carried in the release request, the processor clears the bit and sets the owner identifier field to a null pointer; otherwise, the release request is rejected.

[0017] As a further solution, it also includes: The processor receives a request to query ownership of a hardware peripheral instance specified by the requester; When the device instance slot corresponding to the hardware peripheral instance is not occupied as indicated by the bit in the instance occupancy bitmap, the unowned resource state is returned. When the bit indication is occupied and the owner identifier field is a null pointer, the anonymous owned resource status is returned; When the bit indication is occupied and the owner identifier field is not empty, and is the same as the function pointer carried in the ownership query request, return the named same-owner resource status; When the bit indication is occupied and the owner identifier field is not empty, and is different from the function pointer carried in the ownership query request, the named non-owner resource status is returned.

[0018] As a further solution, when the owner identifier field of a device instance slot is a null pointer and the corresponding bit of the device instance slot in the instance occupancy bitmap is 1, the hardware peripheral instance is in an anonymous occupancy state; in the anonymous occupancy state, the processor accepts and executes occupancy or release requests initiated by the requester.

[0019] Compared with related technologies, the hardware device management system and control method based on the resource sovereignty model provided by this invention have the following advantages: 1. This invention transforms implicit hardware peripheral usage relationships into explicitly queryable data structures by introducing an owner identifier field and an instance occupancy bitmap. It establishes unified resource lifecycle management rules through occupancy, release, and ownership query operations. Furthermore, it differentiates between anonymous and named occupancy strategies. Anonymous occupancy supports flexible reuse and rapid overwriting, while named occupancy provides strict ownership protection, achieving a balance between system flexibility and critical resource security. This avoids issues such as accidental register overwriting or data corruption caused by concurrent access from multiple modules.

[0020] 2. This invention uses function pointers as owner identifiers and determines ownership by comparing pointer addresses. The function pointer address is globally uniquely determined during the compilation and linking stage, eliminating the need for runtime allocation, string comparison, hash calculation, or table lookup processes. The determination complexity is constant time, minimizing runtime overhead while ensuring the deterministic nature of the determination result. This makes it suitable for resource-constrained embedded system environments with stringent real-time requirements.

[0021] 3. This invention registers and manages interrupt service functions through the interrupt service function pointer field and user context field in the device instance slot. In the physical interrupt entry function, the device instance slot is directly located and the corresponding interrupt service function is called using a two-dimensional index structure of "device type + instance index." The entire distribution process is completed in constant time. Therefore, the physical interrupt entry point is completely decoupled from the business interrupt service program, allowing multiple software modules to dynamically reuse the same interrupt source, effectively resolving the technical contradiction between the uniqueness of interrupt requests and the layered design of software.

[0022] 4. This invention can realize the occupancy status management, ownership determination and interrupt distribution control of hardware peripherals without relying on the task scheduling, device tree or driver framework provided by the real-time operating system. It has low system overhead and low porting cost, and makes up for the shortcomings of the existing Linux driver model and RTOS mechanism in lightweight embedded scenarios. Attached Figure Description

[0023] 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.

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

[0025] Figure 1 A schematic diagram of a hardware device management system based on a resource sovereignty model is provided for this invention. Figure 2 This invention provides a schematic diagram of the steps involved in controlling an embedded system hardware peripheral. 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

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0027] In embedded systems, software business logic typically needs to interact with the outside world or perform physical control functions through various hardware peripherals.

[0028] Common hardware peripherals include, but are not limited to: Serial communication interfaces (such as UART, SPI, I2C, etc.) are used for data transmission between devices. The timer module is used to generate control signals or perform time measurements. DMA modules are used for data transfer between peripherals and memory. ADC module, used to acquire external analog signals The aforementioned hardware peripherals are typically managed by the processor's internal controller and their functions are made accessible to software through the register interface.

[0029] In practical applications, these hardware resources often need to be shared by multiple software modules, and different business functions may access the same physical interface at different times or at different stages of operation.

[0030] In embedded systems, due to size and space constraints, the number of pins that a central processing unit (CPU) chip can provide is usually limited. To meet diverse application requirements, a single pin often needs to support multiple peripheral functions, or the same peripheral can be mapped to multiple optional pin combinations.

[0031] In actual product development, the same product line typically needs to accommodate models at different price points or with different standards. The differences between models mainly lie in the hardware platform (such as chip model, package type, or temperature rating), while the upper-layer software business logic often remains consistent. However, to adapt to different hardware topologies, different models usually need to maintain their own hardware mapping relationships, including but not limited to: Mapping relationship between software business functions and peripherals Mapping relationship between peripherals and specific physical pins When the hardware topology changes, the above mapping relationship often needs to be adjusted synchronously, which increases the software maintenance cost.

[0032] For example, in one type of circuit board, UART1 might be mapped to PB8 / PB9 pins; while in another type of circuit board, due to different pin resource usage, only PC6 / PC7 are available, corresponding to the UART2 peripheral. Therefore, the existing software needs to be modified at least as follows during the migration process: Adjust the mapping between the business module and UART1 to UART2. Adjust the pin mapping between UART1 and PB8 / PB9 to UART2 and PC6 / PC7. The above adaptation process is usually achieved through compile-time configuration (such as macro definitions). Since the hardware mapping relationship is determined after the circuit design is completed, this method is feasible to a certain extent in the early stages of a project.

[0033] However, as the number of product functional modules continues to increase and the software system gradually expands to the entire product line, the complexity of maintaining the mapping relationship increases significantly. Each adjustment to the physical interface requires verification of the correctness of all related functional modules, which is not only labor-intensive but also prone to introducing errors that are difficult to eliminate.

[0034] More importantly, in existing architectures, the usage relationships of physical resources typically lack explicit management, with their "ownership" implicitly determined by software configuration and runtime status. When resource allocation conflicts occur, problems are often only indirectly discovered through functional anomalies, making it difficult to quickly pinpoint the source of the conflict. This issue is particularly pronounced for critical shared resources such as DMA, significantly increasing the difficulty of system debugging and maintenance.

[0035] I. The contradiction between IRQ uniqueness and the principle of software layering An IRQ (Interrupt Request) is a hardware interrupt request, typically initiated by hardware or a peripheral device, used to interrupt the CPU's current task. When the CPU receives an interrupt request, it looks up the interrupt vector table based on the interrupt number to jump to the corresponding interrupt handler function. The entry addresses of these handler functions are fixed in the interrupt vector table and are provided by the chip manufacturer.

[0036] In software engineering, the uniqueness of IRQs is crucial. Each IRQ typically corresponds to a unique Interrupt Service Routine (ISR). To prevent interrupt service routine conflicts or erroneous responses, each interrupt number in the interrupt vector table must match a unique name. Therefore, IRQs with the same name cannot exist throughout the entire project; otherwise, interrupt handling conflicts will occur, affecting the stability and reliability of the system.

[0037] In embedded software engineering, a layered design is typically employed, dividing the system into multiple layers, each responsible for different functional modules. This design helps improve module reusability, reduce coupling, and thus enhance development efficiency and system maintainability. Each layer can be developed independently, allowing for adaptation to underlying peripherals on different hardware platforms.

[0038] However, the uniqueness of low-level peripheral IRQs inherently conflicts with layered design. This is because IRQs typically interact directly with the underlying hardware, while layered design requires business logic to be decoupled from the underlying hardware as much as possible. This makes separating interrupt management of the underlying hardware from business logic difficult, inevitably requiring the business logic to be centrally processed within IRQs, thus impacting the independence and modular development of the underlying code.

[0039] To overcome this contradiction, various solutions have been proposed in recent years, such as adopting finer-grained interrupt management mechanisms and introducing hardware-software co-design. These methods help to maximize the independence of business logic and the flexibility of underlying code while ensuring system performance.

[0040] These methods can be categorized as follows: 1) Integrate IRQs into business modules: To address the issue of IRQ uniqueness, many embedded developers typically adopt a simple and direct approach in the early stages of a project: integrating the IRQ design into the business module. Especially in the early stages of a project, when development cycles are short and functional requirements are concentrated, this method allows for rapid implementation of basic functional testing, avoiding the initial development pressure caused by complex layered designs.

[0041] For example: *@file:protocol.c *@briefdataparse * Parse the received data and process the specific protocol content. voidparse(constuint8_t*data,size_tdata_size){ / / (Data parsing logic omitted) } *@briefUSART1GlobalIRQ * To handle interruptions in USART1 data reception, directly call the business logic processing function. void USART1_IRQHandler(void){ parse(USART1->DR,1); / / Read data from the USART1 data register and parse it } In the code above, USART1_IRQHandler handles USART1 interrupt requests directly within the business logic. In small projects or testing phases, this direct interrupt handling method can complete the task quickly. However, if multiple protocol stacks or modules need to use the same IRQ entry point, compilation conflicts will occur, especially when multiple interrupt handling functions exist within the same project.

[0042] While designing IRQs directly within business modules allows for rapid functionality implementation, this approach has significant limitations. In large projects, when multiple protocol stacks or peripheral modules need to share the same interrupt entry point, compilation conflicts can occur even if their lifecycles differ. Furthermore, to avoid conflicts, developers often need to configure macros in the compiler, which not only increases code complexity but also requires developers to be familiar with and maintain these configurations. Although this approach circumvents the issue of IRQ uniqueness, it offers no real benefit to long-term project maintenance, feature expansion, or performance improvements; instead, it increases code coupling and maintenance difficulty.

[0043] In summary, while directly embedding IRQ design into business modules is simple and fast, its drawbacks include a lack of flexibility and scalability. This approach fails to meet the demands of complex, multi-functional modules and introduces significant technical debt, increasing system complexity. Therefore, it is suitable for small projects or prototyping phases, but large projects require more reasonable interruption management and layered design.

[0044] 2) Business modules provide ISRs, which are then called within IRQs. An Interrupt Service Routine (ISR) is a function that handles a specific interrupt source. When a peripheral device generates an interrupt request, the CPU jumps to and executes the corresponding ISR based on the interrupt vector table. ISRs are used to perform operations such as data reading, status updates, or event responses. ISRs typically run in a high-priority context and have high requirements for execution time and real-time performance.

[0045] Design scheduling logic in IRQ to call different user ISRs based on the context during program execution.

[0046] For example: *@file:stack_a.c *@briefDatareceiveISR voidstack_a_rx_isr(constuint8_t*data,size_tdata_size){ / / (Data parsing logic omitted) } *@file:stack_b.c *@briefDatareceiveISR voidstack_b_rx_isr(constuint8_t*data,size_tdata_size){ / / (Data parsing logic omitted) } *@file:uart.c *@briefUSART1GlobalIRQ * To handle interruptions in USART1 data reception, directly call the business logic processing function. void USART1_IRQHandler(void){ if( / *condition A* / )stack_a_rx_isr(USART1->DR,1); if( / *condition B* / )stack_b_rx_isr(USART1->DR,1); } This method achieves the reuse of interrupt entry points by distributing calls to the ISR interfaces of different business modules in the IRQ, enabling multiple business modules to share the same physical interface.

[0047] While this method allows a single physical interface to be shared by different users, it only achieves decoupling at the interrupt distribution level, lacking a unified management mechanism for the use of the physical interface. The resource usage relationships between different business modules are typically implicitly determined by the program execution flow, lacking explicit ownership definitions and state awareness. In this situation, when multiple business modules access the same physical interface at different runtime stages, function switching may be achieved through direct configuration or reinitialization of the peripheral. This approach relies on manual control of the execution order by the developer and requires ensuring the idempotency of related operations.

[0048] The above method can be implemented in a single-threaded execution environment, but in a multi-threaded or concurrent task system, due to the uncertainty of the execution timing, the resource usage relationship is difficult to predefine, which may lead to resource conflicts and unpredictable system behavior.

[0049] In a multi-threaded concurrent environment, due to the lack of a unified resource management mechanism, business modules have difficulty perceiving and coordinating the occupancy status of physical interfaces, which may lead to resource conflicts or uncertain system behavior.

[0050] Therefore, to address the challenges posed by the diversity of physical interfaces, the industry currently employs the following technologies: 1) Hardware Abstraction Layer This approach essentially adds a "hardware abstraction" layer in the middle of the natural hierarchical structure of "business logic -> registers / peripherals", making it a three-layer structure of "business logic -> hardware abstraction -> registers / peripherals". A typical example is STMicroelectronics' STM32 HAL (Hardware Abstraction Layer) library.

[0051] The original intention of this design was to mask the differences between the registers of different chip models, so that business logic could be developed independently without paying attention to hardware details, thereby improving the portability of software programs.

[0052] However, this method only abstracts the hardware access interface and does not manage the usage relationships and lifecycle of hardware resources. 2) Driver registration and ISR distribution This method essentially distributes interrupt handling logic, but does not introduce arbitration or ownership management mechanisms for resource access.

[0053] This method, mentioned above, involves adding a dispatcher to the IRQ, allowing different business logics to reuse the same interrupt source. For example, it enables different protocol stacks to share the same serial port for communication. Issues such as hardware resource lifecycle and configuration consistency also require manual maintenance. In high-concurrency environments where the program execution flow is uncertain by the compiler, manually maintaining the hardware resource lifecycle is virtually impossible.

[0054] 3) RTOS resource management RTOS (Real-Time Operation System) is a general term for real-time operating systems, with FreeRTOS being a typical example. Real-time operating systems typically provide mechanisms such as mutexes, semaphores, and queues to address resource conflicts in high-concurrency environments and ensure the uniqueness of resource access permissions.

[0055] However, this type of mechanism only controls the access process synchronously and does not involve the unified management of resource configuration status and ownership. Therefore, the lifecycle of hardware resources still needs to be manually maintained.

[0056] For example: take(UART_mutex); / / Lock the resource UART_Init(115200); / / Initialize resources These two lines of code first obtain the right to use the UART, and then configure the baud rate. This allows the UART to be reused in a time-sharing manner between different business logics, but it cannot answer questions such as "Is the UART configuration correct?"

[0057] 4) Linux / Driver Model The Linux device manager provides a complete device tree and mature device lifecycle management methods. However, this type of model depends on a complete operating system environment, incurs significant resource overhead, and is difficult to apply directly to resource-constrained or real-time-critical embedded systems.

[0058] 5) Static configuration This approach can be seen as a proactive trade-off made in pursuit of software reliability, with typical examples being ArutoSAR and various configuration generation tools. This method requires all resources to be configured at compile time, disallowing dynamic changes in hardware resource configurations at runtime. Each time the hardware mapping changes, the relevant functional modules need to be re-verified, making it difficult to guarantee that configuration adjustments won't introduce potential errors.

[0059] In summary, existing technologies either focus on interface abstraction, concurrent access control, or rely on heavy operating systems or static configuration mechanisms, but none of them have a mechanism for uniformly describing, managing, and controlling the ownership and lifecycle of physical resources in a lightweight embedded environment.

[0060] Example 1 Please see Figure 1 To address the aforementioned technical problems, this embodiment provides a hardware device management system based on a resource sovereignty model, comprising: The processor and memory, wherein the memory stores a data structure for at least one device type track, each device type track corresponding to a type of hardware peripheral, including an instance occupancy bitmap and multiple device instance slots; each bit in the instance occupancy bitmap is used to indicate the occupancy status of the corresponding hardware peripheral instance; each device instance slot includes an interrupt service function pointer field, an owner identifier field and a user context field; The processor is configured to: In response to a hardware peripheral's request to occupy or release, an occupation or release operation is performed based on the bit in the instance's occupation bitmap and the owner identifier field, using a function pointer as the owner identifier. In response to an ownership query request, the resource status is returned based on the bits in the instance occupancy bitmap and the owner identifier field. The resource status includes unowned resources, anonymous owned resources, named resources with the same owner, and named resources with different owners. In response to a hardware interrupt, the hardware status register is read to obtain the interrupt source identifier. The corresponding device instance slot is located directly according to the device type and instance index associated with the interrupt source. The interrupt service function is called through the interrupt service function pointer in the device instance slot, and the interrupt source identifier and the user context field are passed to the interrupt service function.

[0061] It should be noted that this embodiment uses specific data structures and processor configurations to achieve explicit and unified management of hardware peripheral resources in a lightweight embedded environment.

[0062] The processor constructs at least one "device type track" data structure in memory. Each device type track corresponds to a type of hardware peripheral (such as timer or serial port) and contains an "instance occupancy bitmap" and multiple "device instance slots." Each device instance slot represents a specific hardware peripheral instance, integrating an interrupt service function pointer field, an owner identifier field, and a user context field. Each bit in the instance occupancy bitmap uniquely corresponds to a device instance slot, used to mark whether the hardware peripheral instance is currently occupied. This two-dimensional index structure abstracts dispersed hardware resources into a unified addressable management unit.

[0063] The processor is configured to respond to three types of core operations in order to manage and utilize the aforementioned data structures.

[0064] First, in response to an acquisition or release request, the processor uses a function pointer as the owner identifier and performs resource acquisition or release by reading and modifying the bits of the corresponding device instance slot and the owner identifier field.

[0065] Second, in response to an ownership query request, the processor returns four resource statuses based on the combination of bits and the owner identifier field: unowned, anonymously owned, named with the same owner, or named with a different owner.

[0066] Third, in response to a hardware interrupt, the processor obtains the interrupt source identifier by reading the hardware status register, and directly locates the corresponding device instance slot based on the device type and instance index associated with the interrupt source. Then, it calls the interrupt service function registered in that slot, passing in the interrupt source identifier and user context field, thereby completing the decoupling and distribution from the hardware interrupt to the business processing logic in a constant time.

[0067] Furthermore, each bit in the instance occupancy bitmap corresponds one-to-one with the index of the plurality of device instance slots. A bit value of 1 indicates that the hardware peripheral instance has been occupied, and a bit value of 0 indicates that the hardware peripheral instance is idle.

[0068] Specifically, in this embodiment, each bit in the instance occupancy bitmap has a one-to-one correspondence with the index of multiple device instance slots.

[0069] Specifically, the bitmap is a binary expansion of an integer variable, where the least significant bit corresponds to the device instance slot with index 0, the next least significant bit corresponds to the device instance slot with index 1, and so on. Through this direct bit index mapping, the processor can determine the occupancy status of any hardware peripheral instance without traversing or searching; it only needs to read the value of the corresponding bit in the bitmap based on the instance index.

[0070] Therefore, when a bit is 1, it indicates that the corresponding hardware peripheral instance is currently occupied; when the bit is 0, it indicates that the hardware peripheral instance is idle and can be acquired by a new requester. This binary state representation allows the occupancy determination operation to be reduced to a single bit test instruction, completed in constant time, meeting the real-time and deterministic requirements of embedded systems.

[0071] Furthermore, when determining ownership, the processor compares whether the function pointer address stored in the owner identifier field is the same as the function pointer address passed in by the requester.

[0072] Specifically, this embodiment achieves this by comparing the function pointer address stored in the owner identifier field of the device instance slot with the function pointer address provided by the requester. The owner identifier is a function pointer, which is written to the device instance slot when the resource is named and used as the unique identity credential of the resource owner. When any subsequent operation requires verification of whether the requester is the legitimate owner of the resource, the processor directly retrieves the pointer address stored in the slot and compares it with the pointer address provided by the requester. If both pointers point to the same function, they are considered to be of the same owner; otherwise, they are considered to be of different owners.

[0073] Since the address of a function pointer is determined during the compilation and linking phase and is globally unique, it avoids naming conflicts or duplicate allocation problems that may arise from string or numeric identifiers. Furthermore, address comparison is an atomic operation of the processor, with a computational complexity of constant time. It does not involve string traversal, hash calculations, or table lookups, minimizing runtime overhead while ensuring deterministic judgment results. This makes it particularly suitable for resource-constrained embedded system environments with stringent real-time requirements.

[0074] Furthermore, when the processor performs an occupancy operation, it is configured as follows: Read the device instance slot corresponding to the hardware peripheral instance specified by the requester, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap; If the bit indicates that the space is free, then the bit is set to 1, and the owner identifier field is set to the function pointer passed in by the requester to achieve named occupancy, or set to a null pointer to achieve anonymous occupancy; If the bit indication is occupied and the owner identifier field is a null pointer, then overwriting and updating the owner identifier field upon request is allowed, or the null pointer can be retained. If the bit indicates that the bit is occupied and the owner identifier field is not empty, and the owner identifier field is the same as the function pointer passed by the requester, then the occupied status is returned or the occupation is considered successful. If the bit indicates that the bit is already occupied and the owner identifier field is not empty, and the owner identifier field is different from the function pointer passed in by the requester, then the occupancy request is rejected.

[0075] Specifically, when the processor receives a occupancy request, it first reads the device instance slot corresponding to the hardware peripheral instance specified by the requester, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap, to obtain the current occupancy status of the instance.

[0076] Subsequently, the processor performs differentiated processing in four cases based on the combination of bit values ​​and owner identifier field values: Through the above four-way branch processing logic, the occupancy operation realizes differentiated management and control of idle resources, anonymous occupancy resources and named occupancy resources on the basis of a unified data structure: it allows flexible reuse and overwriting of anonymous resources, while implementing strict ownership protection for named resources to prevent resource encroachment conflicts between different software modules.

[0077] Furthermore, when the processor performs a release operation, it is configured to: Read the device instance slot corresponding to the hardware peripheral instance specified by the requester, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap; If the bit indicates that it is already occupied, and the owner identifier field is a null pointer, or the owner identifier field is the same as the function pointer passed in by the requester, then the bit is cleared and the owner identifier field is set to a null pointer; otherwise, the release is refused.

[0078] Specifically, when the processor receives a release request, it first reads the device instance slot corresponding to the hardware peripheral instance specified by the requester, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap.

[0079] Subsequently, the processor performs a judgment based on the reading result: if the bit indicates that it is occupied and the owner identifier field is a null pointer, it indicates that the instance is currently in an anonymous occupation state. Since anonymous occupation does not have resource protection capabilities, the processor allows the release, clears the bit, and sets the owner identifier field to a null pointer, so that the instance returns to an ownerless state. If the bit indication is already occupied, and the owner identifier field is the same as the function pointer passed by the requester, indicating that the requester is the named owner of the instance, the processor will also perform a cleanup operation, clearing the bit and setting the owner identifier field to null. In all other cases besides the two mentioned above, including when the bit indication is free, or when the bit indication is occupied but the owner identifier field is different from the function pointer passed by the requester, the processor will refuse the release request.

[0080] This embodiment's release operation is based on a dual-mode ownership strategy of anonymous and named ownership: anonymously held resources remain open and can be released by any requester for rapid reclamation; named resources are strictly protected and can only be released by the legitimate owner to prevent resource status chaos caused by accidental operation or malicious tampering by other software modules. Through this case-by-case release mechanism, the system maintains the exclusivity and stability of critical resources while ensuring the flexibility of resource use.

[0081] Furthermore, when the owner identifier field of a device instance slot is a null pointer, but the corresponding bit of the device instance slot in the instance occupancy bitmap is 1, the corresponding hardware peripheral instance is in an anonymous occupancy state; in the anonymous occupancy state, the processor accepts the requester's occupancy or release operation for the current hardware peripheral instance.

[0082] Specifically, this embodiment defines the constituent elements of the anonymous occupancy state: when the owner identifier field of any device instance slot is a null pointer, but the corresponding bit in the instance occupancy bitmap of that device instance slot is 1, the hardware peripheral instance corresponding to that device instance slot is in an anonymous occupancy state. This state is different from the ownerless state (bit is 0 and the owner identifier field is a null pointer) and the named owner state (bit is 1 and the owner identifier field stores a valid function pointer). Its essential characteristic is that the resource has been occupied, but the occupant does not have an identifiable owner identity.

[0083] Given the absence of an owner in the anonymous occupancy state, this embodiment handles this state as follows: In the anonymous occupancy state, the processor accepts any requester's request to occupy or release the hardware peripheral instance. Therefore, any requester can either acquire an anonymously occupied instance and convert it to a named, owned state, or directly release an anonymously occupied instance, restoring it to an ownerless state. This design provides maximum flexibility in temporary scenarios where resource protection is not required, complementing the strict protection mechanism in the named occupancy state, and together forming the technical basis of the dual-mode ownership strategy.

[0084] Example 2 Please see Figure 2 This embodiment also provides a control method for embedded system hardware peripherals, applied in a hardware device management system based on a resource sovereignty model as described in any of the above embodiments 1. The control method includes: The processor receives a request to occupy a hardware peripheral instance specified by the requester, the request carrying an owner identifier in the form of a function pointer; The processor reads the device instance slot corresponding to the hardware peripheral instance, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap; When the bit indicates that the device is free, the processor sets the bit to 1 and sets the owner identifier field to the function pointer or null pointer carried in the occupancy request to complete the named or anonymous occupancy. When the bit indication is occupied and the owner identifier field is a null pointer, the processor allows overwriting and updating or maintaining the owner identifier field accordingly; When the bit indicates that the device is occupied and the owner identifier field is not empty and is the same as the function pointer carried in the occupancy request, the processor returns the occupied status or considers the occupancy successful. The processor rejects the occupancy request when the bit indicates that the occupancy is already occupied and the owner identifier field is not empty and is different from the function pointer carried in the occupancy request; In response to a hardware interrupt, the processor reads the hardware status register to obtain the interrupt source identifier, determines the device type and instance index based on the interrupt source, directly locates the corresponding device instance slot, reads the interrupt service function pointer and user context field in the device instance slot, and calls the interrupt service function with the interrupt source identifier and the user context field as parameters.

[0085] It should be noted that this embodiment is applied to an embedded device that includes a processor and memory and stores device type track data structure, and is a methodological limitation of the workflow described in Embodiment 1.

[0086] This embodiment first covers the hardware peripheral occupancy handling process. When the processor receives an occupancy request for a hardware peripheral instance specified by the requester, the request carries an owner identifier in the form of a function pointer.

[0087] The processor reads the bits and owner identifier field of the device instance slot corresponding to the instance in the instance occupancy bitmap, and processes them according to the combination of their values: if the bit indicates that it is free, it is set to 1 and the named or anonymous occupancy is completed according to whether the pointer passed by the requester is null; if the bit indicates that it is occupied but the owner identifier field is a null pointer, it is allowed to overwrite and update or keep the owner identifier field accordingly; if it is occupied and the owner identifier field is the same as the pointer of the requester, it returns the occupied status or is regarded as successful; if it is occupied and the owner identifier field is a different non-null pointer, the occupancy request is rejected.

[0088] This method also covers the hardware interrupt response and processing flow. When a hardware peripheral generates an interrupt, the processor reads the hardware status register to obtain the interrupt source identifier, determines the device type and instance index based on the interrupt source, directly locates the corresponding device instance slot, reads the interrupt service function pointer and user context field in the slot, and calls the interrupt service function with the interrupt source identifier and user context field as parameters.

[0089] This embodiment achieves unified management of the hardware peripheral occupancy status and decouples the distribution of physical interrupt requests to service interruption programs during the method's runtime through the two parallel processing flows described above.

[0090] Furthermore, it also includes: The processor receives a release request for the hardware peripheral instance specified by the requester; When the device instance slot corresponding to the hardware peripheral instance is occupied as indicated by a bit in the instance occupancy bitmap, and the owner identifier field is a null pointer or the same as the function pointer carried in the release request, the processor clears the bit and sets the owner identifier field to a null pointer; otherwise, the release request is rejected.

[0091] Specifically, when the processor receives a release request for a hardware peripheral instance specified by the requester, the request carries an owner identifier in the form of a function pointer. The processor first reads the bits of the device instance slot corresponding to the hardware peripheral instance in the instance occupancy bitmap and the owner identifier field to obtain the current occupancy status and owner identity information.

[0092] Subsequently, the processor performs a judgment based on the read result: if the bit indicates that it is occupied and the owner identifier field is a null pointer, it indicates that the instance is in an anonymously occupied state. Since anonymous occupation has no protection, the processor accepts the release request; if the bit indicates that it is occupied and the owner identifier field is the same as the function pointer carried in the release request, it indicates that the requester is the legitimate named owner of the instance, and the processor also accepts the release request. In both of the above cases, the processor performs the same operation—clearing the bit (setting it to 0) and setting the owner identifier field to a null pointer, restoring the hardware peripheral instance to an ownerless state.

[0093] In other cases, where the bit indicates free (the instance is not occupied and does not need to be released), or the bit indicates occupied but the owner identifier field is a non-null pointer and different from the function pointer passed in by the requester (the instance is occupied by another named owner), the processor rejects the release request. This release process design ensures the named owner's exclusive control over the resource, prevents non-owners from accidentally or maliciously releasing critical resources occupied by others, while retaining the flexibility of anonymous resource occupation, thus achieving a balance between protection and openness in the system.

[0094] Furthermore, it also includes: The processor receives a request to query ownership of a hardware peripheral instance specified by the requester; When the device instance slot corresponding to the hardware peripheral instance is not occupied as indicated by the bit in the instance occupancy bitmap, the unowned resource state is returned. When the bit indication is occupied and the owner identifier field is a null pointer, the anonymous owned resource status is returned; When the bit indication is occupied and the owner identifier field is not empty, and is the same as the function pointer carried in the ownership query request, return the named same-owner resource status; When the bit indication is occupied and the owner identifier field is not empty, and is different from the function pointer carried in the ownership query request, the named non-owner resource status is returned.

[0095] Specifically, when the processor receives a request to query ownership of a hardware peripheral instance specified by the requester, the request carries an owner identifier in the form of a function pointer as the query credential.

[0096] The processor reads the bits of the device instance slot corresponding to the hardware peripheral instance in the instance occupancy bitmap and the owner identifier field, and returns one of four distinct resource states based on the combination of the two values. Through this ownership query operation, any software module in the system can obtain the occupancy status and ownership information of any hardware peripheral instance in real time during runtime.

[0097] This embodiment transforms the resource usage relationships that were originally implicit in the program execution flow into a data structure state that can be explicitly queried. This allows resource conflict issues to be directly detected and located during runtime, without relying on developer experience or post-event debugging to infer resource occupancy, significantly improving the observability and maintainability of the system.

[0098] Furthermore, when the owner identifier field of a device instance slot is a null pointer and the corresponding bit of the device instance slot in the instance occupancy bitmap is 1, the hardware peripheral instance is in an anonymous occupancy state; in the anonymous occupancy state, the occupancy or release request initiated by the requester is accepted and executed by the processor.

[0099] Specifically, this embodiment specifies the constituent elements of the anonymous occupancy state: when the owner identifier field of a device instance slot is a null pointer and the corresponding bit of the device instance slot in the instance occupancy bitmap is 1, the hardware peripheral instance corresponding to the device instance slot is in the anonymous occupancy state.

[0100] This state differs from the unowned state (bit 0) and the named owned state (bit 1 and owner identifier field stores a valid function pointer). Its essential characteristic is that the resource has been occupied, but the occupant has not provided identifiable owner credentials, so the system cannot trace the occupant of the resource.

[0101] Given the absence of owner identity in anonymous occupancy, this embodiment specifies the operating rules for this state: In anonymous occupancy, any request from a party to occupy or release the hardware peripheral instance is accepted and executed by the processor. This means that resources in anonymous occupancy have no protection mechanism; any party can acquire the resource by overwriting it through an occupancy operation or restore it to an unclaimed state through a release operation.

[0102] Therefore, the design of this embodiment provides technical support for temporary and flexible use scenarios that do not require strict ownership protection, complementing the protection mechanism under named occupancy status, and together achieving a balance between the system's flexibility in resource use and the security of critical resources.

[0103] Example 3 This embodiment provides a hardware device manager for an embedded system. The manager runs in an embedded device that includes a processor and memory as described in Embodiment 1, and executes the control method described in Embodiment 2. The processor may be an embedded microprocessor such as an ARM Cortex-M series or a RISC-V series, and the memory may be on-chip flash memory or static random access memory.

[0104] This embodiment abstracts physical hardware resources into a two-dimensional structure: the first dimension is the device category, with each device category corresponding to a device type track; the second dimension is the device instance, with each device instance corresponding to a device instance slot. Through this two-dimensional index structure, the processor can directly locate the complete description information of the target hardware peripheral instance in constant time using the device type and instance index.

[0105] The memory stores at least one device type track data structure. Each device type track corresponds to a class of hardware peripherals, such as a Universal Asynchronous Receiver / Transmitter track, a Timer track, a Direct Memory Access Controller track, etc. Each device type track contains an instance occupancy bitmap and multiple device instance slots. One device instance slot corresponds to a specific hardware peripheral instance; for example, device instance slot 0 in the Timer track corresponds to Timer TIM1, and device instance slot 1 corresponds to Timer TIM2.

[0106] The instance occupancy bitmap is an integer variable, essentially a bitmap data structure. Each bit in the instance occupancy bitmap corresponds one-to-one with the index of a device instance slot. When a bit has a value of 1, it indicates that the hardware peripheral instance corresponding to that bit is occupied; when a bit has a value of 0, it indicates that the hardware peripheral instance corresponding to that bit is in an idle state.

[0107] Each device instance slot contains three fields: an interrupt service function pointer field, an owner identifier field, and a user context field. The interrupt service function pointer field stores the entry address of the interrupt service function corresponding to this hardware peripheral instance. The owner identifier field stores the function pointer address of the owner occupying this hardware peripheral instance; when this field is null, it indicates that there is no named owner. The user context field is an untyped pointer used to store the business context information bound to this hardware peripheral instance, and is passed in when the interrupt service function is called.

[0108] The relationship between device type tracks, instance occupancy bitmaps, and device instance slots is as follows: Each device type track contains one instance occupancy bitmap and multiple device instance slots. Each bit in the instance occupancy bitmap corresponds one-to-one with the index of the device instance slot, used to mark the occupancy status of the hardware peripheral instance described by that slot. The device instance slot further contains an interrupt service function pointer field, an owner identifier field, and a user context field, used to fully describe the interrupt handling entry point, owner identity, and user context information of a single hardware peripheral instance.

[0109] In one specific implementation, the device type track is defined using a C language structure as follows: struct DEV_CLASS_ORBIT { DEV_INS_SLOTSlots

[32] ; uint32_tOccupiedMap; }; The Slots array stores multiple device instance slots. The array length of 32 is for illustrative purposes only and can be adjusted according to the actual number of hardware peripheral instances. OccupiedMap is an instance occupancy bitmap, which is a 32-bit unsigned integer, with each bit corresponding to an index in the Slots array.

[0110] The structure definition of the device instance slot is as follows: struct DEV_INS_SLOT { DEV_ISRHandler; DEV_OWNER_IDOwner; void*UsrCTX; }; Here, Handler is a pointer to an interrupt service routine, and its type DEV_ISR is defined as: typedef void (*DEV_ISR)(uint32_t _src, void *_usr_ctx); The function pointed to by this function pointer accepts two parameters: _src is the interrupt source identifier, which describes the specific interrupt event type; _usr_ctx is the value of the UsrCTX field.

[0111] Owner is the owner identifier, and its type DEV_OWNER_ID is defined as follows: typedef const char* (*DEV_OWNER_ID)(void); This type is a function pointer type, which points to a function with no parameters and returns a constant string pointer. It should be noted that the return value (string) of the DEV_OWNER_ID type function is only used for human-readable display during logging or debugging. When performing ownership determination, the processor only compares the function pointer address itself, does not call the function, and does not depend on the content of the returned string.

[0112] Ownership Identifier and Ownership Determination Mechanism: This embodiment uses a function pointer as the owner identifier, rather than a string, handle, or numeric identifier. When determining ownership, the processor compares the function pointer address stored in the owner identifier field of the device instance slot with the function pointer address passed in by the requester.

[0113] The determination mechanism has the following technical features: the owner's identity is determined at compile time, without the need for runtime allocation or maintenance; ownership determination is completed by comparing pointer addresses, with a computational complexity of constant time; it does not rely on dynamic memory management or string processing mechanisms, thus reducing the resource overhead during system runtime.

[0114] In a specific application scenario, the first and second software modules each define a function of type DEV_OWNER_ID, returning the name string of their respective modules. When the first software module requests to occupy a hardware peripheral instance, it passes its function pointer as the owner identifier, and the processor stores this pointer in the owner identifier field of the corresponding device instance slot. Subsequently, when the second software module attempts to occupy or release the instance, the processor compares its passed function pointer with the pointer stored in the owner identifier field. Since the two point to different functions, their addresses are necessarily different, thus determining that the second software module is an outsider and rejecting its operation request.

[0115] The specific implementation of lifecycle management operations: In this embodiment, each hardware peripheral instance has three states during its lifecycle: no master resource state, that is, the corresponding bit in the instance's occupied bitmap is 0, and the owner identifier field of the device instance slot is a null pointer; anonymous master resource state, that is, the corresponding bit is 1 and the owner identifier field is a null pointer; named master resource state, that is, the corresponding bit is 1 and the owner identifier field stores a valid function pointer.

[0116] The transition between different states is triggered by an occupy or release operation: an unowned resource can be converted into an anonymous owned resource through anonymous acquisition, or into a named owned resource through named acquisition; an anonymous owned resource can be converted into an unowned resource by any requester through a release operation, or can be converted into a named owned resource by a named requester through an occupy operation; a named owned resource can only be converted into an unowned resource by the owner himself through a release operation.

[0117] Occupancy Operation: When the processor receives an occupancy request for a hardware peripheral, the request carries the identifier of the hardware peripheral instance specified by the requester (i.e., device type and instance index) and the owner identifier in the form of a function pointer. Specifically, the processor executes the following steps: First, the processor reads the device instance slot corresponding to the hardware peripheral instance specified by the requester, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap.

[0118] Then, based on the combination of values ​​for the bit and the owner identifier field, the following processing is performed respectively: Scenario 1: If the bit indicates free (bit value is 0), the processor sets the bit to 1. If the function pointer passed by the requester is a non-null pointer, the pointer is assigned to the owner identifier field to achieve named occupancy; if the function pointer passed by the requester is a null pointer, the owner identifier field is kept null to achieve anonymous occupancy.

[0119] Scenario 2: If the bit indication is occupied (bit value is 1) and the owner identifier field is a null pointer, it indicates that the hardware peripheral instance is currently in an anonymous occupied state. Due to the characteristics of anonymous occupied state (lack of resource protection), the processor allows overwriting. If the requester passes a null pointer, it indicates that the instance is occupied anonymously, and the instance continues to maintain its anonymous occupied state; if the requester passes a non-null pointer, it indicates that a named requester has overwritten the original anonymous occupied state, and the instance is converted to a named owned resource state.

[0120] Scenario 3: If the bit indicates that the instance is occupied and the owner identifier field is not empty, and this owner identifier field is the same as the function pointer passed in by the requester, it indicates that the requester is the current named owner of the instance. The processor can either return an occupied status to indicate to the caller that the instance has been occupied twice, or it can directly consider the instance to have been occupied successfully (idempotent processing). The specific processing method can be determined by the system configuration: for scenarios requiring strict uniqueness checks, an error message can be returned; for scenarios that allow repeated calls, idempotent processing can be used to simplify the caller's logic.

[0121] Scenario 4: If the bit indication is already occupied and the owner identifier field is not empty, and this owner identifier field is different from the function pointer passed in by the requester, it indicates that the instance has already been occupied by another named owner. The processor rejects the occupancy request.

[0122] Release operation: When the processor receives a release request for a hardware peripheral, the request also carries the identifier of the hardware peripheral instance specified by the requester and an owner identifier in the form of a function pointer. The processor performs the following steps: First, the processor reads the device instance slot corresponding to the hardware peripheral instance specified by the requester, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap.

[0123] If the bit indicates that the device is already occupied, and the owner identifier field is a null pointer (anonymous occupation), or the owner identifier field is the same as the function pointer passed in by the requester (named owner), then the processor clears the bit (sets it to 0), sets the owner identifier field to a null pointer, and the hardware peripheral instance returns to an ownerless state. Otherwise, the processor rejects the release request.

[0124] Through the above release rules, named owners can only release their own resources, while anonymously held resources can be released by any requester. This ensures the protection of named resources while also taking into account the flexibility of anonymous resources.

[0125] Ownership query operation: When the processor receives an ownership query request for a hardware peripheral instance specified by the requester, it reads the bits of the device instance slot corresponding to the instance in the instance occupancy bitmap and the owner identifier field, and returns one of the following four states: When the bit indicates that it is not occupied (bit value is 0), return to the unowned resource status; When the bit indicator is occupied (bit value is 1) and the owner identifier field is a null pointer, return the anonymous owned resource status; If the bit indication is occupied, the owner identifier field is not empty, and it is the same as the function pointer carried in the query request, return the named master resource status; If the bit indication is occupied, the owner identifier field is not empty, and it is different from the function pointer carried in the query request, return the named non-owner resource status.

[0126] Through this query operation, any software module in the system can obtain the occupancy status and ownership information of hardware peripheral instances in real time during runtime, enabling resource conflict issues to be directly detected and located.

[0127] Anonymous Occupancy Status Description: When the owner identifier field of any device instance slot is a null pointer, but the corresponding bit of the device instance slot in the instance occupancy bitmap is 1, the hardware peripheral instance corresponding to the device instance slot is in an anonymous occupancy status.

[0128] Anonymous occupancy has the following characteristics: Because the owner identifier field is a null pointer, there is no identifiable owner identity, and therefore no resource protection capabilities. In anonymous occupancy, the processor accepts any requester's attempt to acquire or release the hardware peripheral instance. This means that any requester can overwrite an anonymously occupied instance or release it, restoring it to an ownerless state.

[0129] Anonymous occupancy is suitable for temporary scenarios that do not require exclusive use or stable protection, while named occupancy is suitable for critical functional modules that need to ensure resource exclusivity and traceability.

[0130] Interrupt dispatch mechanism implementation: In this embodiment, the binding relationship between interrupt service functions and hardware peripheral instances is implemented through the interrupt service function pointer field and user context field in the device instance slot.

[0131] Once a software module successfully occupies a hardware peripheral instance, either named or anonymously, it can write a custom interrupt service function pointer to the interrupt service function pointer field of the corresponding device instance slot, and write the business context pointer related to the interrupt handling to the user context field. This binding process decouples the physical interrupt request from the business interrupt service routine.

[0132] When a hardware peripheral generates an interrupt event, the central processing unit (CPU) responds to the interrupt and jumps to the fixed interrupt request entry function. This entry function executes the following process: The first step is to read the hardware status register to obtain the interrupt source identifier. The interrupt source identifier describes the specific interrupt event type, such as a timer update event, a compare-match event, or a capture event. Then, the corresponding interrupt flag in the status register is cleared to prevent repeated interrupt entries.

[0133] The second step is to determine the device type and instance index based on the hardware peripheral associated with the interrupt request entry point. For example, the TIM1_UP_TIM10_IRQHandler interrupt entry function is associated with timer TIM1 (instance index 1) and timer TIM10 (instance index 10), and the device type is timer track.

[0134] The third step involves invoking a unified interrupt dispatch function, passing in the device type, instance index, and interrupt source identifier. Internally, the dispatch function locates the corresponding device type track based on the device type and directly accesses the corresponding device instance slot via the instance index. If the corresponding bit in the instance occupancy bitmap is 0, it indicates that the hardware peripheral instance is not currently occupied by any module and no interrupt service function has been registered; the dispatch function returns directly without executing any interrupt service function call. If the corresponding bit is 1, the interrupt service function pointer and user context field in the device instance slot are read, and the interrupt service function is called with the interrupt source identifier and user context field as parameters.

[0135] The following example uses a timer interrupt to illustrate the specific implementation code of the interrupt entry function: void TIM1_UP_TIM10_IRQHandler(void) { uint32_t sr; sr = TIM1->SR; if (sr != 0) { TIM1->SR&= ~sr; __open_uni_broker_isr_dispatch(UNI_DEV_TIM, UNI_DEV_INST1, sr); } #if !defined(NO_TIM2_TIM3_TIM4_TIM10) sr = TIM10->SR; if (sr != 0) { TIM10->SR&= ~sr; __open_uni_broker_isr_dispatch(UNI_DEV_TIM, UNI_DEV_INST10, sr); } #endif } The `__open_uni_broker_isr_dispatch` function is the interrupt dispatch function. It locates the device type track based on the passed device type (UNI_DEV_TIM) and directly accesses the corresponding device instance slot based on the instance index (UNI_DEV_INST1 or UNI_DEV_INST10). If the bit indicates that the slot is occupied, it reads the `Handler` and `UsrCTX` pointers and executes `Handler(sr, UsrCTX)` to complete the interrupt service routine call; if the bit indicates that the slot is free, it returns directly.

[0136] In the above process, from the triggering of a hardware interrupt to the invocation of the user interrupt service function, the processor directly locates the device instance slot through a two-dimensional index structure of "device type + instance index". The entire distribution process can be completed in constant time, which meets the strict requirements of embedded systems for the real-time response of interrupts.

[0137] In summary, as can be seen from the above specific implementation methods, this embodiment has the following technical advantages: First, by introducing an owner identifier field and an instance occupancy bitmap into the resource model, the resource usage relationship that was originally implicit in the program execution flow is transformed into an explicit data structure representation, and the occupancy status and ownership information of hardware peripheral instances can be queried in real time at any given moment.

[0138] Second, it uses function pointers as owner identifiers and achieves constant-time ownership determination by comparing pointer addresses. It does not require string comparison or dynamic memory allocation, has low system overhead, and is suitable for resource-constrained embedded environments.

[0139] Third, by using unified management rules for occupancy and release operations, and combining a dual-mode strategy of anonymous and named occupancy states, the protection of critical resources and the flexibility of non-critical resources are balanced, avoiding potential register overwriting or data corruption issues that may occur when multiple modules concurrently access the same hardware peripheral instance.

[0140] Fourth, by registering interrupt service functions and user contexts in the device instance slots and calling them through a unified dispatch mechanism in the interrupt entry function, the physical interrupt request and the business interrupt service program are completely decoupled, resolving the contradiction between the uniqueness of interrupt requests and the layered design of software.

[0141] Fifth, the entire system does not rely on any operating system's task scheduling, device tree, or driver framework, and can be deployed on bare-metal systems or resource-constrained high real-time embedded platforms.

[0142] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A hardware device management system based on a resource sovereignty model, characterized in that, include: The processor and memory, wherein the memory stores a data structure for at least one device type track, each device type track corresponding to a type of hardware peripheral, including an instance occupancy bitmap and multiple device instance slots; each bit in the instance occupancy bitmap is used to indicate the occupancy status of the corresponding hardware peripheral instance; each device instance slot includes an interrupt service function pointer field, an owner identifier field and a user context field; The processor is configured to: In response to a hardware peripheral's request to occupy or release, an occupation or release operation is performed based on the bit in the instance's occupation bitmap and the owner identifier field, using a function pointer as the owner identifier. In response to an ownership query request, the resource status is returned based on the bits in the instance occupancy bitmap and the owner identifier field. The resource status includes unowned resources, anonymous owned resources, named resources with the same owner, and named resources with different owners. In response to a hardware interrupt, the hardware status register is read to obtain the interrupt source identifier. The corresponding device instance slot is located directly according to the device type and instance index associated with the interrupt source. The interrupt service function is called through the interrupt service function pointer in the device instance slot, and the interrupt source identifier and the user context field are passed to the interrupt service function.

2. The hardware device management system based on a resource sovereignty model according to claim 1, characterized in that, Each bit in the instance occupancy bitmap corresponds one-to-one with the index of the plurality of device instance slots. A bit value of 1 indicates that the hardware peripheral instance has been occupied, and a bit value of 0 indicates that the hardware peripheral instance is idle.

3. A hardware device management system based on a resource sovereignty model according to claim 1, characterized in that, When determining ownership, the processor compares the function pointer address stored in the owner identifier field with the function pointer address passed in by the requester.

4. A hardware device management system based on a resource sovereignty model according to claim 2, characterized in that, When the processor performs an occupancy operation, it is configured as follows: Read the device instance slot corresponding to the hardware peripheral instance specified by the requester, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap; If the bit indicates that the space is free, then the bit is set to 1, and the owner identifier field is set to the function pointer passed in by the requester to achieve named occupancy, or set to a null pointer to achieve anonymous occupancy; If the bit indication is occupied and the owner identifier field is a null pointer, then overwriting and updating the owner identifier field upon request is allowed, or the null pointer can be retained. If the bit indicates that the bit is occupied and the owner identifier field is not empty, and the owner identifier field is the same as the function pointer passed by the requester, then the occupied status is returned or the occupation is considered successful. If the bit indicates that the bit is already occupied and the owner identifier field is not empty, and the owner identifier field is different from the function pointer passed in by the requester, then the occupancy request is rejected.

5. A hardware device management system based on a resource sovereignty model according to claim 1, characterized in that, When the processor performs a release operation, it is configured to: Read the device instance slot corresponding to the hardware peripheral instance specified by the requester, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap; If the bit indicates that it is already occupied, and the owner identifier field is a null pointer, or the owner identifier field is the same as the function pointer passed in by the requester, then the bit is cleared and the owner identifier field is set to a null pointer; otherwise, the release is refused.

6. A hardware device management system based on a resource sovereignty model according to claim 2, characterized in that, When the owner identifier field of a device instance slot is a null pointer, but the corresponding bit of the device instance slot in the instance occupancy bitmap is 1, the corresponding hardware peripheral instance is in an anonymous occupancy state; in the anonymous occupancy state, the processor accepts the requester's occupancy or release operation of the current hardware peripheral instance.

7. A control method for embedded system hardware peripherals, applied in a hardware device management system based on a resource sovereignty model as described in any one of claims 1 to 6, characterized in that, The control method includes: The processor receives a request to occupy a hardware peripheral instance specified by the requester, the request carrying an owner identifier in the form of a function pointer; The processor reads the device instance slot corresponding to the hardware peripheral instance, as well as the corresponding bit and owner identifier field of the device instance slot in the instance occupancy bitmap; When the bit indicates that the device is free, the processor sets the bit to 1 and sets the owner identifier field to the function pointer or null pointer carried in the occupancy request to complete the named or anonymous occupancy. When the bit indication is occupied and the owner identifier field is a null pointer, the processor allows overwriting and updating or maintaining the owner identifier field accordingly; When the bit indicates that the device is occupied and the owner identifier field is not empty and is the same as the function pointer carried in the occupancy request, the processor returns the occupied status or considers the occupancy successful. The processor rejects the occupancy request when the bit indicates that the occupancy is already occupied and the owner identifier field is not empty and is different from the function pointer carried in the occupancy request; In response to a hardware interrupt, the processor reads the hardware status register to obtain the interrupt source identifier, determines the device type and instance index based on the interrupt source, directly locates the corresponding device instance slot, reads the interrupt service function pointer and user context field in the device instance slot, and calls the interrupt service function with the interrupt source identifier and the user context field as parameters.

8. The control method for embedded system hardware peripherals according to claim 7, characterized in that, Also includes: The processor receives a release request for the hardware peripheral instance specified by the requester; When the device instance slot corresponding to the hardware peripheral instance is occupied as indicated by a bit in the instance occupancy bitmap, and the owner identifier field is a null pointer or the same as the function pointer carried in the release request, the processor clears the bit and sets the owner identifier field to a null pointer; otherwise, the release request is rejected.

9. The control method for embedded system hardware peripherals according to claim 7, characterized in that, Also includes: The processor receives a request to query ownership of a hardware peripheral instance specified by the requester; When the device instance slot corresponding to the hardware peripheral instance is not occupied as indicated by the bit in the instance occupancy bitmap, the unowned resource state is returned. When the bit indication is occupied and the owner identifier field is a null pointer, the anonymous owned resource status is returned; When the bit indication is occupied and the owner identifier field is not empty, and is the same as the function pointer carried in the ownership query request, return the named same-owner resource status; When the bit indication is occupied and the owner identifier field is not empty, and is different from the function pointer carried in the ownership query request, the named non-owner resource status is returned.

10. The control method for embedded system hardware peripherals according to claim 7, characterized in that, When the owner identifier field of a device instance slot is a null pointer and the corresponding bit of the device instance slot in the instance occupancy bitmap is 1, the hardware peripheral instance is in an anonymous occupancy state. In anonymous occupancy, all occupancy or release requests initiated by the requester are accepted and executed by the processor.

Images