Automated configuration method and apparatus, computer device, and storage medium

Abstract

The application discloses an automatic configuration method and device, computer equipment and a storage medium, which comprises the following steps: if a hot plug event is detected, a target peripheral device is confirmed according to the hot plug event, and a physical address space of the target peripheral device is scanned through a memory mapping interface to obtain register parameters of the target peripheral device; an original hardware description data set is generated based on the register parameters; the original hardware description data set is parsed to convert the original hardware description data set into a standardized descriptor; preset rules are configured for the standardized descriptor to obtain a compatibility enhanced descriptor; the compatibility enhanced descriptor is bound to the target peripheral device, and a driving instance matched with the compatibility enhanced descriptor is dynamically loaded through a hot patch mechanism to realize driving configuration of the target peripheral device. The application not only improves the compatibility of the driving, but also can automatically reconfigure the driving, so that the adaptation logic error can be avoided.

Description

Technical Field

[0001] This invention relates to the field of drive technology, and in particular to an automated configuration method, apparatus, computer device, and storage medium. Background Technology

[0002] In the field of computer systems and embedded devices, the ARM processor architecture, with its advantages of low power consumption, high performance, and low cost, occupies an important position in many scenarios such as mobile devices, the Internet of Things, industrial control, and automotive electronics. Meanwhile, Linux, with its open-source, stable, and highly customizable features, has become one of the preferred operating systems for the ARM processor architecture.

[0003] With the continuous development of technology, the functions of various peripherals are becoming increasingly rich, their performance is constantly improving, and their types and models are becoming more and more complex. Peripherals produced by different manufacturers have significant differences in hardware interfaces, register layouts, and electrical characteristics, resulting in poor driver compatibility and portability. In addition, during system operation, dynamic changes such as hot-plugging of peripherals may occur. At this time, the driver information may not be compatible with the newly inserted peripheral, which can easily lead to adaptation logic errors. Summary of the Invention

[0004] This invention provides an automated configuration method, apparatus, computer device, and storage medium, aiming to solve the problems of poor compatibility of current peripheral drivers and adaptation logic errors that occur during hot-plugging.

[0005] In a first aspect, embodiments of the present invention provide an automated configuration method, the method comprising: If a hot-plug event is detected, the target peripheral is identified based on the hot-plug time, and the physical address space of the target peripheral is scanned through the memory mapping interface to obtain the register parameters of the target peripheral. Generate the original hardware description dataset based on the register parameters; The original hardware description dataset is parsed to convert it into a standardized descriptor; Configure preset rules for the standardized descriptors to obtain compatibility-enhanced descriptors; The compatibility enhancement descriptor is bound to the target peripheral, and a driver instance matching the compatibility enhancement descriptor is dynamically loaded through a hot patching mechanism to configure the driver for the target peripheral.

[0006] Secondly, embodiments of the present invention also provide an automated configuration device, the device comprising: The first acquisition unit is used to, if a hot-plug event is detected, identify the target peripheral based on the hot-plug time, and scan the physical address space of the target peripheral through the memory mapping interface to obtain the register parameters of the target peripheral; The first generation unit is used to generate an original hardware description dataset based on the register parameters; The first parsing unit is used to parse the original hardware description dataset to convert the original hardware description dataset into a standardized descriptor; The first configuration unit is used to configure preset rules for the standardized descriptor to obtain a compatibility-enhanced descriptor; The first binding unit is used to bind the compatibility enhancement descriptor to the target peripheral and dynamically load a driver instance that matches the compatibility enhancement descriptor through a hot patching mechanism to implement driver configuration for the target peripheral.

[0007] Thirdly, embodiments of the present invention also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0008] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0009] This invention provides an automated configuration method, apparatus, computer device, and storage medium. The method includes: if a hot-plug event is detected, identifying a target peripheral based on the hot-plug time, and scanning the physical address space of the target peripheral through a memory-mapped interface to obtain the register parameters of the target peripheral; generating an original hardware description dataset based on the register parameters; parsing the original hardware description dataset to convert it into a standardized descriptor; configuring preset rules for the standardized descriptor to obtain a compatibility enhancement descriptor; binding the compatibility enhancement descriptor to the target peripheral and dynamically loading a driver instance matching the compatibility enhancement descriptor through a hot-patching mechanism to implement driver configuration for the target peripheral. This invention can generate an original hardware description dataset based on register parameters, and obtain standardized descriptors based on the original hardware description dataset to standardize the register parameters of different peripherals. Then, preset rules are configured for the standardized descriptors to obtain compatibility enhancement descriptors. The compatibility enhancement descriptors are then bound to the target peripherals, and driver instances are dynamically loaded through a hot patching mechanism to implement driver configuration for the target peripherals. This can generate a matching compatibility enhancement descriptor each time a peripheral is changed to adapt to different peripherals, which not only improves driver compatibility but also allows for automatic driver reconfiguration, avoiding adaptation logic errors. Attached Figure Description

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

[0011] Figure 1 This is a flowchart illustrating the automated configuration method provided in an embodiment of the present invention; Figure 2 This is a schematic block diagram of the automated configuration device provided in an embodiment of the present invention; Figure 3 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0012] 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, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] It should be understood that, when used in this specification and the appended claims, the terms “comprising” and “including” indicate the presence of the described features, integrals, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, operations, elements, components and / or collections thereof.

[0014] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0015] Please see Figure 1 , Figure 1 This is a flowchart illustrating the automated configuration method provided in an embodiment of the present invention. The automated configuration method of this invention can be applied to computer devices, such as laptops and desktop computers, for automated configuration of peripheral drivers. Figure 1 As shown, the method includes steps S110 to S150.

[0016] S110, if a hot-plug event is detected, the target peripheral is identified based on the hot-plug time, and the physical address space of the target peripheral is scanned through the memory mapping interface to obtain the register parameters of the target peripheral.

[0017] In this embodiment of the invention, when a peripheral device (such as a sensor or camera) is inserted or removed during system operation, the system will detect the hot-plug event through a hardware interrupt of the bus (such as I2C or USB); then identify the device identity (such as manufacturer ID or device model) through the bus protocol to confirm the target peripheral device; finally, scan the register space of the peripheral device through the memory mapping interface (which maps the physical register address of the peripheral device to the system virtual address for easy CPU access) to obtain the register parameters, such as the address, function, and read / write attributes of the register.

[0018] For example, when an I2C accelerometer (model ACC-300) is plugged into the development board's I2C interface: The system's I2C controller triggers a device access interrupt, informing the kernel that a new device has connected. The kernel reads the sensor's vendor ID register (returns 0x12) and device ID register (returns 0x34) via the I2C protocol and matches it with the ACC-300 accelerometer sensor; The system maps the sensor's physical register address (assigned by the I2C controller, such as 0x50000000-0x50000010) to the kernel virtual address, and obtains key parameters after scanning: Data register (0x50000004): Stores X / Y / Z axis acceleration data, read-only; Control register (0x50000008): Configures the sampling rate (e.g., 100Hz / 200Hz), readable and writable; Interrupt register (0x5000000C): Triggers a data ready interrupt, bound to system IRQ18 (falling edge triggered); No DMA functionality (no DMA configuration required).

[0019] Furthermore, a tiered probing strategy can be employed when scanning peripheral address spaces to balance performance and accuracy. First, a coarse-grained scan of the ARM memory-mapped I / O region is performed in 4KB units. Within each page frame, the system sends standardized read instructions to access register fields at fixed offset addresses. The validity of the read results determines whether the region maps to a recognizable peripheral. When a page frame region is detected as responding normally, the system immediately classifies it as a candidate peripheral space and enters a fine-grained probing phase, reading all register fields within that region address by address using a 1-byte granularity. The fine-grained mapping phase not only records the register addresses and their contents but also analyzes the spacing between fields, read / write behavior patterns, and register bit width characteristics to construct a complete register layout diagram. After completing the fine-grained scan, the system automatically extracts the peripheral's core identification information, including the vendor ID, hardware version number, and checksum calculated from all readable register values, generating a corresponding hardware fingerprint. This fingerprint serves as a unique identifier for the peripheral and can be compared with fingerprint entries in the device tree database to assist in driver matching and compatibility assessment. Taking a SoC platform with an embedded SPI controller as an example, the system first locates the page frame containing the SPI module in the peripheral address block at a 4KB granularity. Then, it switches to byte-level read mode to extract the contents of the control register, status register, and data buffer within the module, calculates the feature verification value, and combines it with the vendor ID and version number fields in the SPI module to form a complete fingerprint. This fingerprint ultimately serves as the input for subsequent semantic conversion and driver binding. This mechanism ensures the platform's highly robust identification capability for multiple types and versions of peripherals, providing accurate and stable hardware foundation information for subsequent device description and driver loading processes.

[0020] S120, Generate the original hardware description dataset based on the register parameters.

[0021] In this embodiment of the invention, register parameters are organized according to functional dimensions to form an original hardware description dataset. This is a preliminary record of hardware characteristics, including register information, interrupt information, bus information, etc.

[0022] For example, for the ACC-300 sensor, its original hardware description dataset is: Register list: Data register (address 0x50000004, read-only), control register (address 0x50000008, read-write, initial value "100Hz sampling rate"), interrupt register (address 0x5000000C, read-only). Interrupt information: Interrupt number IRQ18, trigger mode "falling edge", associated interrupt register; Bus information: I2C bus (bus number 2), device address (0x48), maximum transfer rate (400kHz).

[0023] S130, the original hardware description dataset is parsed to convert the original hardware description dataset into a standardized descriptor.

[0024] In this embodiment of the invention, the original hardware description dataset is formatted and converted into a Standardized Descriptor (SDD) conforming to the system kernel specification. The core of standardization is to unify field naming and clarify data structures (such as register ranges and interrupt formats), enabling the system (such as the kernel driver adaptation engine) to quickly parse the basic hardware attributes of the device without relying on differences in device type.

[0025] For example, a semantic translation layer can be set up. The raw hardware description dataset is input into this layer, which is middleware with embedded syntax recognition and context analysis capabilities. It is specifically designed to parse peripheral information and convert it into a device tree format recognizable by the Linux kernel. The semantic translation layer first parses the address mapping relationship and bit field definition of the peripheral registers. Using a rule engine, it identifies the read / write attributes, bit width, access method, and function identifier of the register fields, and generates node entries according to the device tree specification. Subsequently, the system extracts the clock source identifier associated with the peripheral, analyzes its required clock division parameters and possible supported dynamic frequency adjustment strategies, and constructs the clocks and clock-names fields that conform to the clock controller framework. For the power management part, the semantic translation layer identifies whether the peripheral supports low-power states, wake-up source functions, and voltage domain dependencies, and generates regulator or power-domain related fields to achieve automatic connection with the kernel power management subsystem. Taking a peripheral device with serial port controller functionality as an example, its original description information includes register address range, interrupt number, baud rate control register and its bit field definition, and the UART clock source and power domain information. After semantic conversion, the system generates a device node containing standard fields such as reg, interrupts, clocks, and power-domains, and outputs it in .dts format to ensure that the peripheral device can be correctly identified and bound during the Linux kernel initialization phase, thereby completing the automatic adaptation preparation work of the device driver.

[0026] For example, the ACC-300 Standard Descriptor (SDD) is recorded according to the kernel specification format: Device identifier: compatible="vendor,acc-300-i2c" (used to match the accelerometer driver in the system); Register range: reg=<0x500000000x10> (starting address + length, covering all registers); Interrupt information: interrupts=<180x02> (18 is the interrupt number, 0x02 indicates falling edge trigger); Bus parameters: i2c-address=H (I2C device address), i2c-max-frequency= <400000> (Maximum speed 400kHz).

[0027] S140, Configure preset rules for the standardized descriptor to obtain a compatibility-enhanced descriptor.

[0028] In this embodiment of the invention, based on the Standardized Descriptor (SDD), compatibility enhancement rules are added—pre-defined resolution logic (such as interrupt conversion and version number rules) is provided for possible hardware differences or conflicts (such as mismatched interrupt triggering methods or register version management requirements), forming a compatibility enhancement descriptor. This descriptor not only contains hardware attributes but also has a built-in adaptation scheme, which can directly guide the driver to be compatible with devices.

[0029] For example, for the ACC-300 sensor, the added rules include: Register transactional synchronization rules: The data register will be automatically updated as the sensor samples, and a 16-bit cyclic version number rule will be added (the version number will be incremented by 1 with each update, and will wrap around after full scale to avoid the driver reading old data). Interruption consistency correction rule: If the sensor driver in the system is preset to be triggered by the rising edge, but the sensor is actually triggered by the falling edge, add an edge inversion rule (convert the falling edge to the rising edge through a state machine to ensure driver response). Hot patch association rules: Record the location of the interrupt handling function in the driver, as well as the path of the adapter module used to inject version number verification and edge transition logic.

[0030] S150, the compatibility enhancement descriptor is bound to the target peripheral and a driver instance matching the compatibility enhancement descriptor is dynamically loaded through a hot patching mechanism to implement driver configuration for the target peripheral.

[0031] In this embodiment of the invention, a compatibility enhancement descriptor that records peripheral hardware attributes (such as register address and interrupt mode) and preset rules (such as interrupt conversion and DMA compensation) is associated with the unique identifier of the target peripheral (such as vendor ID + device ID) to ensure that the system can accurately locate which adaptation logic the peripheral needs.

[0032] Based on the compatibility identifier in the compatibility enhancement descriptor, the system automatically selects the driver (driver instance) that matches the peripheral function and loads the driver without restarting the system through hot patching technology. At the same time, hot patching dynamically injects the adaptation rules (such as version number verification and interrupt conversion logic) in the descriptor into the driver instance, enabling the driver to have the ability to be compatible with peripheral hardware differences.

[0033] After the driver instance is loaded and injected with the rules, it can perform operations such as register initialization, interrupt binding, and DMA configuration based on the information in the descriptor, and finally achieve normal driving of the target peripheral (such as data reading and writing, event response).

[0034] For example, the system reads the vendor ID register (value 0xAB) and device ID register (value 0xCD) of the ACC-300 via the I2C bus to obtain its unique hardware identifier; this identifier is then bound to a previously generated compatibility enhancement descriptor and stored in the kernel's peripheral-descriptor mapping table. The core content of the compatibility enhancement descriptor includes: Compatibility flag: compatible="vendor,acc-300-i2c" (used to match drivers); Interrupt conversion rule: irq_convert_type=falling_to_rising (falling edge to rising edge), including state machine parameters (such as pulse width 200ns); Register transactional synchronization rules: Data registers use 32-bit incrementing version numbers, and retry 3 times for conflicts (delay 1us). Hot patch information: Address of the driver interrupt handler function acc_irq_handler, and path to the adapter module acc_compat.ko.

[0035] The system reads the compatible field in the descriptor and matches the corresponding driver instance in the driver library; The hot patching mechanism is activated, dynamically loading the i2c_acc_driver and injecting the adaptation rules from the descriptor: Interrupt transition logic injection: Insert falling edge to rising edge state machine code into the driver's acc_irq_handler function—when the sensor outputs a falling edge pulse (raw interrupt), the state machine generates a 200ns rising edge virtual pulse to trigger the driver interrupt handling; Version number verification logic injection: In the function acc_read_data that reads the data register, insert the verification logic for reading the shadow page version number Vd and the physical register version number Vc, and execute the read only when Vd≥Vc, to avoid reading old data; Resource configuration adaptation: Automatically configure the driver's bus communication parameters (such as a transmission rate of 400kHz) based on the I2C address (0x48) and register range in the descriptor.

[0036] After implementing the driver configuration injection rules for ACC-300, the i2c_acc_driver instance performs the following operations: Register initialization: Write the configuration (sampling rate 100Hz, range ±16g) to the control register, based on the initial value parameters in the descriptor; Interrupt binding: Through the virtual interrupt routing layer, the converted rising edge pulse is associated with the driver's acc_irq_handler to ensure that the driver can respond when the sensor data is ready; Data read verification: Before each read of X / Y / Z axis data, a version number check is automatically performed, and data is only read if the status is consistent to avoid data errors.

[0037] The entire process requires no system restart, achieving plug-and-play functionality.

[0038] In some embodiments, such as this embodiment, the preset rules include the following: Controlled by a data write request to write data to a target peripheral, the target shadow register page is confirmed according to the data write request, and the target physical register corresponding to the target shadow register page is locked; Read the current version number of the target shadow register page, and obtain the target version number of the target physical register; If the current version number is greater than or equal to the target version number, then the data read / write request is executed; If the current version number is less than the target version number, the data write request is rejected.

[0039] In this embodiment of the invention, when the system receives a request to write data to a target peripheral (such as modifying sensor configuration or updating controller parameters), it first determines the target shadow register page corresponding to the request—the shadow register page is a cached copy of the peripheral's physical register in memory (used to reduce conflicts from direct hardware access and improve efficiency). Simultaneously, to prevent interference from other operations (such as peripheral self-modification or writing by other programs) during the writing process, the physical register is temporarily locked to ensure the atomicity (uninterruptible) of the writing process.

[0040] Both the shadow register page and the physical register record their data update status using version numbers (the version number automatically increments each time data is modified). The system needs to read two version numbers: the current version number of the target shadow register page (denoted as Vd): reflecting whether the data cached in the target shadow register page is based on the latest state of the physical register; and the target version number of the target physical register (denoted as Vc): reflecting the real-time state of the physical register (which may have been modified autonomously by peripherals, such as sensors adjusting parameters according to environmental changes).

[0041] If Vd ≥ Vc, it means that since the last synchronization of the target shadow register page to the present, the physical register has not been modified by the peripheral device (or has been modified and synchronized to the target shadow register page). The data in the target shadow register page is valid data based on the latest state of the physical register. At this time, it is safe to perform a write operation: write the new data in the target shadow register page to the physical register, and update the version numbers of both synchronously (to ensure that the subsequent states are consistent), and finally unlock the physical register.

[0042] If Vd < Vc, it means that the physical registers have been modified by the peripheral device since the last synchronization of the target shadow register page (e.g., sensors automatically adjust parameters due to low power mode), and the data in the target shadow register page is outdated. If a write operation is performed at this time, the old data will overwrite the latest state of the physical registers, causing device state inconsistency. Therefore, the write request is rejected, and the system is prompted to first synchronize the states of the target shadow register page and the physical registers (updating the latest state of Vc to the target shadow register page). Version number verification ensures that the written data is based on the latest state of the physical registers, avoiding the problem of old data overwriting the new state due to peripheral device modifications, and ensuring the consistency of hardware and software data.

[0043] For example, the high-temperature alarm threshold register of an industrial temperature sensor (model TEMP-500) is used to set the alarm trigger temperature (default 80℃). This register has a corresponding shadow register page (memory cache), and the two are synchronized through version numbers (initially both version numbers are 1). The sensor may autonomously adjust the threshold due to environmental changes (e.g., automatically dropping to 70℃ in low-temperature environments). In this case, the physical register version number will increment, but the target shadow register page may not be synchronized in time.

[0044] The system needs to modify the sensor's high-temperature alarm threshold from 80℃ to 85℃, and initiates a request to write to the alarm threshold register. The system identifies the target shadow register page corresponding to this request (memory address 0x80001000, caching alarm threshold register data) and locks the sensor's physical alarm threshold register (hardware address 0x90001000) to prevent the sensor from modifying it independently during the write operation.

[0045] Read the current version number Vd=1 of the target shadow register page (the target shadow register page still records the initial state and has not synchronized the sensor's autonomous modification); Read the target version number Vc=2 of the locked physical register (the sensor had previously autonomously changed the threshold to 70℃ due to environmental changes, and the version number was incremented from 1 to 2).

[0046] Since Vd=1 < Vc=2, it means that the target shadow register page data is outdated (it still records 80℃, while the physical register is actually 70℃). The system rejected the request to write to 85℃ and returned a version conflict warning, requiring the target shadow register page to be synchronized first (updating the 70℃ and Vc=2 of the physical register to the target shadow register page).

[0047] After the system synchronizes the target shadow register page (Vd is updated to 2), it re-initiates the write request: Lock the physical registers again and read Vd=2 and Vc=2 (Vd≥Vc); Perform write: Write 85° from the target shadow register page to the physical register, and synchronously update the version number of both to 3; After unlocking the physical register, the sensor's alarm threshold was successfully updated to 85℃.

[0048] Additionally, when a driver encounters a version conflict while attempting to write to a shadow register page—meaning the register version number used by the driver is lower than the current physical register version number—the system initiates a conflict handling mechanism to ensure data consistency. This mechanism uses an exponential backoff retry algorithm to manage the retry sequence of write requests. Upon initial detection of a version conflict, the system makes the write operation wait for a fixed 1-microsecond interval before attempting the write action again. If the conflict persists, the waiting time increases exponentially, delaying the write request for an even longer period to reduce contention and conflict frequency. This delay-increment mechanism effectively avoids write bombardment in multi-driver or multi-threaded environments, alleviating access pressure on the bus and registers. The system sets a maximum retry limit. When the number of consecutive retries exceeds this limit, the driver adaptation engine abandons further retries and returns a specific error code, E_REG_VERSION, to the driver layer, explicitly indicating that the write operation failed due to version mismatch. Upon receiving this error code, the driver can execute appropriate error handling strategies, such as resynchronizing the shadow register contents, refreshing register version information, or triggering a more advanced recovery process. Taking a network interface controller driver in a multi-tasking environment as an example, when multiple threads attempt to update the send queue status register simultaneously, version conflicts frequently occur. The exponential backoff mechanism gradually lengthens the write request interval, avoiding continuous conflicts and wasted system resources. When the number of retries is exhausted and an error is returned, the driver determines that the conflict is unresolved based on the error code, actively reads the latest register status to refresh the local cache, and ensures that subsequent operations are based on the latest hardware status, thereby maintaining the synchronization consistency between the driver and the hardware and the overall stability of the system.

[0049] In some embodiments, such as this embodiment, the preset rule further includes the following: If the interrupt triggering method of the target peripheral is inconsistent with the preset interrupt triggering method, the interrupt event of the target peripheral will be converted into a virtual interrupt event. The interrupt events of the target peripheral are processed through the virtual interrupt events.

[0050] In this embodiment of the invention, the interrupt triggering method of the target peripheral device refers to the interrupt signal type supported by the peripheral device hardware itself (such as level triggering—continuously outputting a high / low level; edge triggering—outputting a pulse only at the instant the signal changes from high to low or low to high). The preset interrupt triggering method refers to the interrupt signal type that is pre-declared in the driver and can only be recognized (such as the driver only supporting edge triggering due to design limitations and cannot respond to level triggering signals).

[0051] When the two are inconsistent (e.g., the peripheral is level-triggered while the driver is edge-triggered), the system automatically inserts a virtual interrupt routing layer between the peripheral's interrupt output and the driver's interrupt receiver. This layer monitors the peripheral's original interrupt signal in real time and converts the original signal into a virtual interrupt event according to the triggering method recognizable by the driver. For example, it extracts the moment of signal change from a continuous level signal to generate a short pulse (simulating edge triggering), or it extends the momentary edge signal into a continuous level (simulating level triggering), ensuring that the triggering method of the virtual event is consistent with the driver's preset and resolving compatibility conflicts.

[0052] The driver does not directly sense or process the original interrupt signal from the peripheral device; instead, it only receives virtual interrupt events output by the virtual interrupt routing layer. Upon receiving a virtual event, the driver executes interrupt handling according to normal logic (such as reading peripheral data and clearing the interrupt flag). Simultaneously, the system activates auxiliary safeguards (such as high-precision timers and interrupt suppression windows): preventing repeated triggering of virtual events (e.g., clearing the peripheral interrupt hanging bit with a timer when transitioning from a level to an edge, avoiding repeated generation of virtual pulses due to continuous level transitions); ensuring state reset after processing (e.g., the interrupt suppression window blocks new signals until the state machine returns to its initial state), ultimately achieving the effect of correctly responding to the original peripheral interrupt without the driver being aware of the transition process.

[0053] For example, the SHT-60 temperature and humidity sensor (peripheral) used in an industrial scenario is designed with low-level trigger interrupt: after the sensor completes a temperature and humidity acquisition, it will continuously output a low level (original interrupt signal) until the driver reads the data, at which point it will stop outputting the low level; however, the driver for this sensor in the system is an older version, which by default only supports rising edge trigger interrupt (the driver will only respond to the instantaneous pulse of "low level → high level", and will not react to continuous low level). Direct connection will cause the sensor driver to be unresponsive.

[0054] Conflict identification: When the system loads the SHT-60 driver, it automatically detects the inconsistency between the low-level trigger of the peripheral and the rising edge trigger of the driver through the compatibility enhancement descriptor, and triggers the interrupt conversion mechanism.

[0055] The system inserts a level-to-edge state machine (belonging to the virtual interrupt routing layer) between the interrupt output pin of the SHT-60 and the interrupt receive interface of the driver: When the SHT-60 completes the acquisition and outputs a continuous low level (original interrupt signal), the state machine monitors the change from high level to low level in real time (i.e., the start time of the low level). The state machine immediately generates a short rising edge pulse of 150ns (virtual interrupt event) – the triggering mode of this pulse perfectly matches the rising edge preset by the driver, and then sends the pulse to the driver's interrupt receiving interface.

[0056] After receiving the virtual rising edge pulse, the driver immediately starts the interrupt handling function to execute the operation of reading the temperature and humidity data of SHT-60. At the same time, the system starts a high-precision timer. After the driver enters the handling function, the timer automatically sends a control signal to SHT-60 after a delay of 200ns to indicate that the data reading is complete. After receiving the signal, SHT-60 stops outputting a low level (the original interrupt signal disappears).

[0057] The system synchronously enables an interrupt suppression window—within 600ns after the virtual pulse is sent, the state machine's detection of the SHT-60 interrupt signal is disabled to prevent the state machine from repeatedly generating virtual pulses due to the SHT-60 low level not disappearing in time, which would then cause the driver to repeatedly execute the processing function.

[0058] After the driver reads the data, the interrupt handling function exits normally, the high-precision timer and the interrupt suppression window are closed simultaneously, and the state machine returns to the initial state of listening to the original interrupt signal, waiting for the interrupt request after the next acquisition by SHT-60.

[0059] In some embodiments, such as this embodiment, the preset rule further includes the following: If the requested DMA memory address and length do not meet the requirements of the target peripheral, an aligned proxy buffer will be automatically allocated. Establish a bidirectional data synchronization channel between the unaligned buffer and the proxy buffer.

[0060] In this embodiment of the invention, the requested DMA memory refers to the memory region that the driver requests through a conventional memory allocation interface (such as kmalloc) and is planned for DMA transfer. Its address alignment or length may not meet the peripheral requirements (e.g., the driver requests 16-byte aligned memory, while the peripheral requires 32-byte alignment). The DMA requirements of the target peripheral device refer to the mandatory requirements of the peripheral device hardware for DMA transfers. These mainly include address alignment size (such as 32-byte alignment - the memory starting address must be an integer multiple of 32) and minimum transfer length (some peripheral devices require the length of a single DMA transfer to be an integer multiple of a specific value).

[0061] The system uses a compatibility enhancement descriptor (which records peripheral DMA requirements) to detect in real time whether the DMA memory requested by the driver meets the requirements. If the conditions are not met (e.g., insufficient address alignment, length mismatch), the kernel's high-alignment memory allocation interface (e.g., kmalloc specifying alignment parameters) will be automatically called to allocate a proxy buffer that strictly meets the peripheral DMA requirements. This buffer is kernel-mode memory independent of the memory requested by the driver and is used only for data transfer in DMA transfers to avoid DMA transfer failures due to non-aligned memory (e.g., data misalignment, hardware errors).

[0062] An unaligned buffer is a memory region originally allocated by the driver that does not meet DMA requirements (the driver will still access this buffer normally afterward, unaware of the existence of the proxy buffer). The core purpose of establishing a bidirectional synchronization channel is to ensure that data interaction between the driver and peripherals can be indirectly accomplished through the proxy buffer. The specific logic falls into two categories: Driver → Peripheral (DMA write operation, such as sending configuration commands): The channel automatically copies the data in the driver's unaligned buffer to the proxy buffer, and then the peripheral DMA controller reads the data from the proxy buffer. Peripheral → Driver (DMA read operation, such as receiving sensor data): The channel automatically copies the data written by the peripheral DMA controller to the agent buffer back to the driver's unaligned buffer for subsequent reading by the driver.

[0063] The synchronization process is automatically triggered by the system (such as before / after DMA transfer) without driver intervention, and is implemented through efficient interfaces such as memcpy, ensuring no data loss and no delay. Ultimately, the driver uses unaligned memory, while peripherals use aligned proxy buffers, and the data of both is consistent in real time.

[0064] In some embodiments, such as this embodiment, the preset rule further includes the following: Create a corresponding virtual operation interface for each physical register of the target peripheral, and allocate at least one shadow register page for each physical register; Each physical register is configured with a version number, which is automatically updated after the physical register is modified.

[0065] In this embodiment of the invention, the virtual operation interface refers to creating a unified software access interface (such as virtual read function and virtual write function) for each physical register of the peripheral device (hardware-level registers, such as data registers and control registers). The driver does not directly read or write the hardware address of the physical register, but operates indirectly through these virtual interfaces—the interfaces automatically handle logic such as shadow page synchronization, version number verification, and hardware access control, hiding hardware details from the driver.

[0066] A shadow register page refers to allocating at least one cached copy (shadow page) in memory for each physical register to temporarily store the latest state of the physical register. Its core function is to reduce the frequency of direct hardware access (hardware access is slow and prone to conflicts). As a data pre-operation area, the driver can modify data in the shadow page before synchronizing it to the physical register via a virtual interface. It works in conjunction with version numbers to implement data consistency checks. Version number configuration involves assigning a version identifier (such as a 32-bit integer) to each physical register; the initial value can be set to 1 to mark the number of times the register has been modified.

[0067] The automatic update mechanism means that whenever a physical register is modified (including two scenarios: the driver writes data through a virtual interface; the peripheral modifies it independently, such as a sensor updating measurement data), the version number automatically increments (e.g., from 1→2→3…). Simultaneously, the shadow register page also records the corresponding version number (reflecting the update status of the cached data). By comparing the version numbers of the physical register and the shadow page, it is possible to quickly determine whether the data is consistent (if the version numbers are the same, they are consistent; if they are different, there is a failure to synchronize the update).

[0068] For example, the ACC-300 accelerometer contains three core physical registers: Data register (PHY_DATA): Hardware address 0x50000004, stores raw X / Y / Z axis acceleration data (read-only, automatically updated by the sensor, refreshed every 10ms); Control register (PHY_CTRL): Hardware address 0x50000008, stores configurations such as sampling rate and range (read and write, can be modified by the driver, and may also be automatically adjusted by the sensor in low power mode); Interrupt Register (PHY_IRQ): Hardware address 0x5000000C, records interrupt status such as data ready (read-only, automatically modified when the sensor triggers an interrupt).

[0069] The system creates virtual operation interfaces for each of the three physical registers: virt_read_data(): Called when the driver reads acceleration data. The internal logic is to read the data shadow page → verify the version number → return the data. virt_write_ctrl(config): Called when the driver modifies the configuration. The internal logic is to modify the control shadow page → lock the physical register → verify the version number → synchronize data to PHY_CTRL → update the version number; virt_read_irq(): Called when the driver queries the interrupt status. The internal logic is to read the interrupt shadow page → synchronize the latest status of the physical registers → return the status.

[0070] Allocate one shadow register page (memory address) for each physical register: Shadow page (SHADOW_DATA): 0x60000004, caches the latest value of PHY_DATA; Control shadow page (SHADOW_CTRL): 0x60000008, caches the latest configuration of PHY_CTRL; Interrupt Shadow Page (SHADOW_IRQ): 0x6000000C, caches the interrupt status of PHY_IRQ.

[0071] Configure the initial version number V=1 for each of the three physical registers, and synchronously record the corresponding version number in the shadow page (the version number Vd=1 of SHADOW_DATA is consistent with Vc=1 of PHY_DATA, and so on).

[0072] Automatic version number update rules: PHY_DATA (data register): Every 10ms when the sensor updates data autonomously, the version number Vc of PHY_DATA is automatically incremented by 1 (e.g., from 1→2→3…). At the same time, the system triggers shadow page synchronization to update Vd of SHADOW_DATA to be consistent with Vc. PHY_CTRL (Control Register): When the driver modifies the configuration via virt_write_ctrl(), it first updates the Vd of SHADOW_CTRL (e.g., from 1 to 2), and after synchronizing to PHY_CTRL, the Vc of PHY_CTRL is also updated to 2. When the sensor adjusts its configuration autonomously due to low power consumption, the Vc value of PHY_CTRL is automatically increased by 1 (e.g., from 2 to 3). After the system detects this, it synchronously updates the Vd value of SHADOW_CTRL to 3. PHY_IRQ (Interrupt Register): When the sensor triggers a data ready interrupt, the state of PHY_IRQ changes, the version number Vc is automatically incremented by 1 (e.g., from 1 to 2), and the system synchronously updates SHADOW_IRQ's Vd=2.

[0073] For version control of low-frequency registers, a cyclic version number optimization strategy can be adopted, replacing the traditional 64-bit monotonically increasing version number with a 16-bit cyclic counter to reduce storage and computational overhead. This 16-bit counter resets to zero after reaching its maximum value, forming a cyclic counting mode. Since cyclic counting carries the risk of wraparound, which may lead to misjudgment of the version number order by the driver, the system introduces a CRC-8 check mechanism to verify version number changes and detect cyclic errors. Specifically, the version number V consists of a 16-bit cyclic counter value C and a CRC-8 checksum R, represented as: The CRC-8 checksum R is generated by verifying the loop counter value C and its previous state, ensuring the validity and consistency of version number changes. During version comparison, the driver not only compares the size of the counter value C but also checks whether the corresponding CRC-8 code matches. If a verification failure is found, it is determined that the version number has wrapped around, causing an error, thereby triggering a resynchronization process to avoid write conflicts or data inconsistencies caused by loop wrapping. This method reduces the requirement for version number storage bit width while maintaining the accuracy of version number detection and system stability.

[0074] In some embodiments, such as this embodiment, the automated configuration method may further include the following steps: Verify that the data in the shadow register page and its corresponding physical register page are consistent; If the data of the shadow register page and its corresponding physical register page are consistent, then the status information of the shadow register page is configured as valid. If the data in the shadow register page and its corresponding physical register page are inconsistent, the status information of the shadow register page is configured as invalid.

[0075] In this embodiment of the invention, the shadow register page is a cached copy of the physical register in memory. Data consistency means that the contents stored in both are exactly the same (e.g., every bit of the register value, configuration parameters, etc., match). The system determines consistency in two ways: Direct data comparison: Compare the contents of the shadow register page and the physical register byte by byte (suitable for registers with small data volumes, such as control registers); Indirect version number verification: By comparing the version numbers of the two (if the version numbers are the same, the default data is consistent; if the version numbers are different, the default data is inconsistent).

[0076] A valid status is an identifier for a shadow register page (e.g., marked by a status bit valid=1), indicating that its cached data is fully synchronized with the physical registers. At this point: The driver can directly read the shadow register page to obtain data without accessing the physical register (reducing hardware access latency and improving efficiency). When writing data to the driver, the shadow register page can be modified first, and then pushed to the physical register through the virtual interface synchronization mechanism (to avoid conflicts from directly operating the hardware).

[0077] An invalid state (e.g., valid=0) indicates that the data in the shadow register page is outdated (possibly due to the physical registers being modified by a peripheral device, or the shadow register page not being synchronized in time). In this case: When the driver reads data, the system will forcibly trigger the synchronization of physical register → shadow register page (updating the latest data to the shadow page). After the synchronization is completed, the status will switch to valid, and then the driver will be allowed to read. When the driver writes data, the system will refuse to write directly to the shadow page. It is necessary to first synchronize the shadow page and the physical register (to ensure that the modification is based on the latest state) to avoid overwriting the latest configuration of the physical register with old data.

[0078] Through the consistency check and status marking mechanism, the driver is ensured to always operate based on valid shadow register page data. This avoids the efficiency problem of directly accessing physical registers and prevents configuration errors or data reading anomalies caused by using outdated data by forcing synchronization through invalid states.

[0079] For example, the ACC-300's control register (PHY_CTRL, physical address 0x50000008) is used to configure the sampling rate (default 100Hz), and its corresponding shadow register page (SHADOW_CTRL, memory address 0x60000008) caches this configuration. The system tracks data consistency through version numbers (initially all V=1), and the valid status bit is initially set to 1 (valid).

[0080] Initial state (data consistent): PHY_CTRL stores a 100Hz sampling rate and version number V=1; SHADOW_CTRL caches "100Hz sampling rate", version number V=1; The system compares the version numbers of the two devices (which are the same), determines that the data is consistent, and sets the status of SHADOW_CTRL to valid=1 (valid). At this point, when the driver reads the sampling rate, it can directly access SHADOW_CTRL to obtain the correct data without needing to access the physical registers. However, peripheral modifications can cause data inconsistency: the sensor automatically adjusts the sampling rate to 50Hz due to low-power mode, triggering the following changes: The PHY_CTRL content is updated at 50Hz, and the version number is automatically incremented to V=2; At this time, SHADOW_CTRL is still cached at 100Hz, and the version number V=1 (not synchronized). The system periodically checks (or receives peripheral interrupt notifications) and finds that the version numbers of the two are different (1≠2), determines that the data is inconsistent, and sets the status of SHADOW_CTRL to valid=0 (invalid).

[0081] Driver access status response: When the driver needs to read the sampling rate: The system automatically triggers synchronization when the status of SHADOW_CTRL is detected as valid=0 (invalid): update the 50Hz of PHY_CTRL and the version number V=2 to SHADOW_CTRL; After synchronization is complete, the system re-determines that the data is consistent (both version numbers are 2) and switches the status of SHADOW_CTRL to valid=1; The driver reads SHADOW_CTRL to obtain the latest 50Hz sampling rate data.

[0082] Status response when the driver is modified: If the driver needs to change the sampling rate to 200Hz: If the SHADOW_CTRL status is detected as valid=0 (before synchronization), the system refuses to modify it directly and performs synchronization first (updating SHADOW_CTRL to 50Hz, V=2, and making the status valid). The driver was modified to set SHADOW_CTRL to 200Hz, and the version number was updated to V=3. The system locks PHY_CTRL, synchronizes data (writes 200Hz), and updates its version number to V=3; After synchronization is complete, the data of both are consistent, and the SHADOW_CTRL state remains valid=1.

[0083] In some embodiments, such as this embodiment, the automated configuration method may further include the following steps: If the target peripheral is detected to have modified its physical register, the modified physical register is confirmed to obtain the first physical register; Modify the status information of the shadow register page that matches the first physical register to the invalid state.

[0084] In this embodiment of the invention, peripheral devices (such as sensors and controllers) may autonomously modify their own physical registers during operation (not triggered by a driver, but actively updated by the peripheral device according to hardware logic), for example: After completing a measurement, the sensor automatically updates the value of the data register; in sleep mode, the low-power chip autonomously modifies the configuration parameters of the control register. These modifications can be detected through two mechanisms: Hardware interrupt triggering: When a peripheral device modifies a critical register (such as a data register), it will actively send a register update interrupt to notify the system that a register has been modified; Periodic status monitoring: For registers without interrupt functionality, the system periodically scans the version number or key bits of the physical register using a timer, compares them with the previous record, and determines whether the register has been modified.

[0085] Once a modification is detected, the system locates the specific physical register that was modified by using the interrupt vector (the register address pointed to by the interrupt source) or the address during scanning, and marks it as the first physical register.

[0086] Each physical register has a corresponding shadow register page (a cached copy in memory). When the first physical register is modified autonomously by a peripheral device, its stored data has changed, but the corresponding shadow register page still caches the old data before the modification (unsynchronized). In this case, the shadow page's status needs to be marked as invalid (e.g., the status bit valid=0). This prevents the driver from using outdated data when accessing the shadow page. After being marked as invalid, the system will force a synchronization between the physical register and the shadow page (updating the latest data to the shadow page) the next time the driver accesses that shadow page, ensuring that the driver obtains the correct modified data.

[0087] The automated configuration method of this invention can generate an original hardware description dataset based on register parameters, and obtain standardized descriptors based on the original hardware description dataset to standardize the register parameters of different peripherals. Then, preset rules are configured for the standardized descriptors to obtain compatibility enhancement descriptors. The compatibility enhancement descriptors are then bound to the target peripherals, and driver instances are dynamically loaded through a hot patching mechanism to implement driver configuration for the target peripherals. This method can generate a matching compatibility enhancement descriptor each time a peripheral is changed to adapt to different peripherals, which not only improves driver compatibility but also automatically reconfigures the driver to avoid adaptation logic errors.

[0088] Figure 2 This is a schematic block diagram of an automated configuration device 100 provided in an embodiment of the present invention. Figure 2 As shown, corresponding to the above-described automated configuration method, the present invention also provides an automated configuration apparatus 100. This automated configuration apparatus 100 includes a unit for executing the above-described automated configuration method. Specifically, please refer to... Figure 2 The automated configuration device 100 includes a first acquisition unit 110, a first generation unit 120, a first parsing unit 130, a first configuration unit 140, and a first binding unit 150.

[0089] The first acquisition unit 110 is used to, if a hot-plug event is detected, identify the target peripheral based on the hot-plug time, and scan the physical address space of the target peripheral through the memory mapping interface to obtain the register parameters of the target peripheral. The first generation unit 120 is used to generate an original hardware description dataset based on the register parameters; The first parsing unit 130 is used to parse the original hardware description dataset to convert the original hardware description dataset into a standardized descriptor; The first configuration unit 140 is used to configure preset rules for the standardized descriptor to obtain a compatibility-enhanced descriptor; The first binding unit 150 is used to bind the compatibility enhancement descriptor to the target peripheral and dynamically load a driver instance that matches the compatibility enhancement descriptor through a hot patching mechanism to implement driver configuration for the target peripheral.

[0090] In some embodiments, such as this one, the first configuration unit 140 further includes a second confirmation unit, a first reading unit, a first execution unit, and a second execution unit.

[0091] The second confirmation unit is used to confirm the target shadow register page according to the data write request controlled to write data to the target peripheral, and lock the target physical register corresponding to the target shadow register page. The first reading unit is used to read the current version number of the target shadow register page and obtain the target version number of the target physical register; The first execution unit is configured to execute the data read / write request if the current version number is greater than or equal to the target version number. The second execution unit is configured to reject the data write request if the current version number is less than the target version number.

[0092] In some embodiments, such as this one, the first configuration unit 140 further includes a first conversion unit and a third execution unit.

[0093] The first conversion unit is used to convert the interrupt event of the target peripheral into a virtual interrupt event if the interrupt triggering method of the target peripheral is inconsistent with the preset interrupt triggering method. The third execution unit is used to process the interrupt event of the target peripheral device through the virtual interrupt event.

[0094] In some embodiments, such as this one, the first configuration unit 140 further includes a first allocation unit and a first creation unit.

[0095] The first allocation unit is used to automatically allocate an aligned proxy buffer if it is detected that the requested DMA memory address and length do not meet the requirements of the target peripheral. The first creation unit is used to establish a bidirectional data synchronization channel between the unaligned buffer and the proxy buffer.

[0096] In some embodiments, such as this one, the first configuration unit 140 further includes a second creation unit and a second configuration unit.

[0097] The second creation unit is used to create a corresponding virtual operation interface for each physical register of the target peripheral and to allocate at least one shadow register page for each physical register. The second configuration unit is used to configure a version number for each of the physical registers, wherein the version number is automatically updated after the physical register is modified.

[0098] In some embodiments, such as this one, the automated configuration device 100 further includes a third confirmation unit, a third configuration unit, and a fourth configuration unit.

[0099] The third confirmation unit is used to confirm whether the data in the shadow register page and its corresponding physical register page are consistent. The third configuration unit is used to configure the status information of the shadow register page to a valid state if the data of the shadow register page and its corresponding physical register page are consistent. The fourth configuration unit is used to configure the status information of the shadow register page to an invalid state if the data of the shadow register page and its corresponding physical register page are inconsistent.

[0100] In some embodiments, such as this one, the automated configuration device 100 further includes a fourth confirmation unit and a first modification unit.

[0101] The fourth confirmation unit is used to confirm the modified physical register to obtain the first physical register if the target peripheral device is detected to have modified its physical register. The first modification unit is used to modify the status information of the shadow register page that matches the first physical register to the invalid state.

[0102] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned automated configuration device and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0103] The aforementioned automated configuration device can be implemented as a computer program, which can, for example... Figure 3 It runs on the computer device shown.

[0104] Please see Figure 3 , Figure 3 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 includes a processor 502, a memory, and an interface 507 connected via a system bus 501, wherein the memory may include a non-volatile storage medium 503 and internal memory 504.

[0105] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it causes the processor 502 to perform an automated configuration method.

[0106] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0107] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can perform an automated configuration method.

[0108] This interface 505 is used for communication with other devices. Those skilled in the art will understand that... Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0109] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (FSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0110] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0111] Therefore, the present invention also provides a storage medium. This storage medium may be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program implements any embodiment of the above-described automated configuration method.

[0112] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0113] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0114] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0115] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0116] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0117] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0118] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0119] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An automated configuration method, characterized in that, The method includes: If a hot-plug event is detected, the target peripheral is identified based on the hot-plug time, and the physical address space of the target peripheral is scanned through the memory mapping interface to obtain the register parameters of the target peripheral. Generate the original hardware description dataset based on the register parameters; The original hardware description dataset is parsed to convert it into a standardized descriptor; Configure preset rules for the standardized descriptors to obtain compatibility-enhanced descriptors; The compatibility enhancement descriptor is bound to the target peripheral, and a driver instance matching the compatibility enhancement descriptor is dynamically loaded through a hot patching mechanism to enable driver configuration for the target peripheral. The step of dynamically loading a driver instance that matches the compatibility enhancement descriptor via a hot patching mechanism includes: The system reads the compatible field from the compatibility enhancement descriptor and matches the corresponding driver instance in the driver library; The hot patching mechanism is activated, dynamically loading the i2c_acc_driver and injecting the adaptation rules from the compatibility enhancement descriptor: Interrupt transition logic injection: Insert falling edge to rising edge state machine code into the driver's acc_irq_handler function—when the sensor outputs a falling edge pulse, the state machine generates a 200ns rising edge virtual pulse to trigger the driver interrupt handling; Version number verification logic injection: In the function acc_read_data that reads the data register, insert the verification logic for reading the shadow page version number Vd and the physical register version number Vc, and execute the read only when Vd≥Vc, to avoid reading old data; Resource configuration adaptation: Automatically configure the driver's bus communication parameters based on the I2C address and register range in the compatibility enhancement descriptor; The preset rules include: Controlled by a data write request to write data to a target peripheral, the target shadow register page is confirmed according to the data write request, and the target physical register corresponding to the target shadow register page is locked; Read the current version number of the target shadow register page, and obtain the target version number of the target physical register; If the current version number is greater than or equal to the target version number, then the data read / write request is executed; If the current version number is less than the target version number, the data write request is rejected; If the interrupt triggering method of the target peripheral is inconsistent with the preset interrupt triggering method, the interrupt event of the target peripheral will be converted into a virtual interrupt event. The interrupt events of the target peripheral are processed through the virtual interrupt events; If the requested DMA memory address and length do not meet the requirements of the target peripheral, an aligned proxy buffer will be automatically allocated. Establish a bidirectional data synchronization channel between the unaligned buffer and the proxy buffer; Create a corresponding virtual operation interface for each physical register of the target peripheral, and allocate at least one shadow register page for each physical register; Each physical register is configured with a version number, which is automatically updated after the physical register is modified.

2. The method as described in claim 1, characterized in that, The method further includes: Verify that the data in the shadow register page and its corresponding physical register page are consistent; If the data of the shadow register page and its corresponding physical register page are consistent, then the status information of the shadow register page is configured as valid. If the data in the shadow register page and its corresponding physical register page are inconsistent, the status information of the shadow register page is configured as invalid.

3. The method as described in claim 2, characterized in that, The method further includes: If the target peripheral is detected to have modified its physical register, the modified physical register is confirmed to obtain the first physical register; Modify the status information of the shadow register page that matches the first physical register to the invalid state.

4. An automated configuration device, characterized in that, The device includes: The first acquisition unit is used to, if a hot-plug event is detected, identify the target peripheral based on the hot-plug time, and scan the physical address space of the target peripheral through the memory mapping interface to obtain the register parameters of the target peripheral; The first generation unit is used to generate an original hardware description dataset based on the register parameters; The first parsing unit is used to parse the original hardware description dataset to convert the original hardware description dataset into a standardized descriptor; The first configuration unit is used to configure preset rules for the standardized descriptor to obtain a compatibility-enhanced descriptor; The first binding unit is used to bind the compatibility enhancement descriptor to the target peripheral and dynamically load a driver instance that matches the compatibility enhancement descriptor through a hot patching mechanism to implement driver configuration for the target peripheral. The first binding unit is specifically used for: The system reads the compatible field from the compatibility enhancement descriptor and matches the corresponding driver instance in the driver library; The hot patching mechanism is activated, dynamically loading the i2c_acc_driver and injecting the adaptation rules from the compatibility enhancement descriptor: Interrupt transition logic injection: Insert falling edge to rising edge state machine code into the driver's acc_irq_handler function—when the sensor outputs a falling edge pulse, the state machine generates a 200ns rising edge virtual pulse to trigger the driver interrupt handling; Version number verification logic injection: In the function acc_read_data that reads the data register, insert the verification logic for reading the shadow page version number Vd and the physical register version number Vc, and execute the read only when Vd≥Vc, to avoid reading old data; Resource configuration adaptation: Automatically configure the driver's bus communication parameters based on the I2C address and register range in the compatibility enhancement descriptor; The first configuration unit includes: The second confirmation unit is used to confirm the target shadow register page according to the data write request controlled to write data to the target peripheral, and lock the target physical register corresponding to the target shadow register page. The first reading unit is used to read the current version number of the target shadow register page and obtain the target version number of the target physical register; The first execution unit is configured to execute the data read / write request if the current version number is greater than or equal to the target version number. The second execution unit is configured to reject the data write request if the current version number is less than the target version number. The first conversion unit is used to convert the interrupt event of the target peripheral into a virtual interrupt event if the interrupt triggering method of the target peripheral is inconsistent with the preset interrupt triggering method. The third execution unit is used to process the interrupt event of the target peripheral device through the virtual interrupt event; The first allocation unit is used to automatically allocate an aligned proxy buffer if it is detected that the requested DMA memory address and length do not meet the requirements of the target peripheral. The first creation unit is used to establish a bidirectional data synchronization channel between the unaligned buffer and the proxy buffer; The second creation unit is used to create a corresponding virtual operation interface for each physical register of the target peripheral and allocate at least one shadow register page for each physical register; The second configuration unit is used to configure a version number for each of the physical registers, wherein the version number is automatically updated after the physical register is modified.

5. A computer device, characterized in that, The computer device includes a memory and a processor connected to the memory; the memory is used to store a computer program; the processor is used to run the computer program stored in the memory to perform the steps of the method as described in any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the steps of the method as described in any one of claims 1-3.

Images