Camera parameter dynamic switching method and system supporting batch script configuration

Abstract

The embodiment of the application provides a kind of camera parameter dynamic switching method and system supporting batch script configuration, belong to parameter configuration technical field.The method comprises: parsing the batch script configuration file corresponding to target camera mode, obtains multiple configuration instructions, generates configuration execution queue, and determines the execution control information corresponding to each configuration instruction;Execute multiple configuration instructions, and write configuration value to corresponding target register;When configuration instruction executes abnormally, determine the affected recovery range according to the function module to which the abnormal configuration instruction belongs and the function module dependency relationship, and perform recovery processing on the affected recovery range.The application scheme reduces the configuration exception and global rewriting risk in camera dynamic switching through script dependent execution, register read-back verification and differential recovery, and improves switching stability.

Description

Technical Field

[0001] This invention relates to the field of parameter configuration technology, and more specifically to a method and system for dynamically switching camera parameters that supports batch script configuration. Background Technology

[0002] With the increasing application of automotive and machine vision cameras in driver assistance, industrial inspection, and image acquisition equipment, cameras often need to switch between different operating modes, such as resolution, frame rate, exposure mode, or HDR (High Dynamic Range) mode. In current debugging or production configuration processes, the host computer software typically loads the configuration file, and then the acquisition device sequentially writes parameters to the registers of the deserializer, serializer, and image sensor. This method can complete basic configuration, but in most cases it is still an open-loop write method executed sequentially according to a script. The register states, link lock states, and image sensor response states after writing are not fully incorporated into the same execution flow.

[0003] In real-world automotive or testing environments, camera links typically include USB (Universal Serial Bus) transmission, SerDes (serializer / deserializer) links, coaxial cables, and I2C (Inter-Integrated Circuit) control buses. These links are long and susceptible to electromagnetic interference, abnormal cable connections, or transient hardware response anomalies. If critical registers such as PLL (Phase-Locked Loop), frame synchronization, video output format, or link locking fail to be written, and the system continues to execute subsequent configurations, the camera may remain in an intermediate state where some parameters have been switched while others have not taken effect, leading to abnormal images, video stream interruptions, or the need for a power-on recovery. Directly performing a global rollback or full rewrite may cause secondary disturbances to unaffected stable modules.

[0004] Therefore, there is an urgent need for a method that can dynamically switch camera parameters by combining the functional module dependencies during batch script configuration and determining the scope of recovery when an anomaly occurs. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for dynamically switching camera parameters that supports batch script configuration, so as to at least solve the problem of poor dynamic switching stability caused by the lack of status confirmation and differential recovery in the existing batch configuration process of cameras.

[0006] To achieve the above objectives, the first aspect of the present invention provides a method for dynamically switching camera parameters supporting batch script configuration. The method includes: parsing a batch script configuration file corresponding to a target camera mode to obtain multiple configuration instructions, and determining the register configuration parameters, read-back verification rules, and functional module dependencies corresponding to each configuration instruction; generating a configuration execution queue based on the functional module to which each configuration instruction belongs and the functional module dependencies, and determining the execution control information corresponding to each configuration instruction; executing the multiple configuration instructions according to the configuration execution queue and the execution control information; writing configuration values ​​to the corresponding target registers according to the register configuration parameters; and after completing the writing of the configuration values, reading the target register status according to the corresponding read-back verification rules to determine whether the corresponding configuration instruction has been executed successfully; and when a configuration instruction execution is abnormal, determining the affected recovery range based on the functional module to which the abnormal configuration instruction belongs and the functional module dependencies, and performing recovery processing on the affected recovery range.

[0007] Optionally, before executing the plurality of configuration instructions according to the configuration execution queue and the execution control information, the method includes: reading the register states of the deserializer, serializer, and image sensor corresponding to the functional module dependencies in the current camera mode to generate a state snapshot of the current camera link; the state snapshot is used to determine the recovery parameters of the corresponding functional module during recovery processing.

[0008] Optionally, the register configuration parameters include: target device identifier, target register address, and configuration value; the readback verification rules include: expected readback value, bitmask, and status determination conditions; the functional module dependency relationship includes the functional module to which each configuration instruction belongs, the preceding functional module of the functional module, and the downstream functional modules that depend on the functional module.

[0009] Optionally, generating a configuration execution queue based on the functional module to which each configuration instruction belongs and the functional module dependency includes: determining the preconditions for each configuration instruction according to the functional module dependency; adding the corresponding configuration instruction to the configuration execution queue when the preconditions are met; and in the configuration execution queue, ensuring that configuration instructions related to link locking, clock locking, frame synchronization, video output format, and video output enable are executed before downstream configuration instructions that depend on the corresponding functional module.

[0010] Optionally, the execution control information includes: post-write waiting time, readback polling count, and retries count; the execution control information is determined based on the functional module to which each configuration instruction belongs, the historical anomaly records of the corresponding functional module, and the current camera link status; the historical anomaly records include at least one of: write no-response records, readback inconsistency records, read timeout records, and retry failure records.

[0011] Optionally, when the configuration instruction belongs to a link locking module, clock locking module, frame synchronization module, video output format module, or video output enable module, and the corresponding functional module has historical abnormal records or the current camera link status does not meet the preset stability conditions, the write wait time, read-back polling count, or retries count corresponding to the configuration instruction are increased within a preset range.

[0012] Optionally, the step of reading the target register status according to the corresponding readback verification rule to determine whether the corresponding configuration instruction has been executed successfully includes: after completing the writing of the configuration value, waiting for hardware response according to the write wait time in the corresponding execution control information, and reading the actual status value of the target register; extracting the valid status bit using the bitmask in the readback verification rule, and comparing the valid status bit with the expected readback value or status determination condition; if any one of the following is not met—read timeout, write no response, valid status bit mismatch, or status determination condition—it is determined that the corresponding configuration instruction has not been executed successfully.

[0013] Optionally, determining the affected recovery range based on the functional module to which the abnormal configuration instruction belongs and the functional module dependencies, and performing recovery processing on the affected recovery range, includes: determining the functional module to which the abnormal configuration instruction belongs, the downstream functional modules that depend on the functional module to which the abnormal configuration instruction belongs, and the associated functional modules whose readback states do not meet the stability conditions as candidate recovery ranges; eliminating read-only status registers, hardware auto-update registers, and status bit registers that are not allowed to be recovered and written, based on the register attributes of each target register in the candidate recovery range, to obtain a set of recoverable registers; determining the target registers in the set of recoverable registers whose current readback values ​​are inconsistent with the corresponding register states in the status snapshot as differential recovery registers; performing recovery writing on the differential recovery registers based on the recovery parameters corresponding to the differential recovery registers in the status snapshot, and confirming the recovery result based on the readback states of the read-only status registers or hardware auto-update registers after recovery writing.

[0014] A second aspect of the present invention provides a dynamic switching system for camera parameters that supports batch script configuration. The system includes: a configuration parsing unit, configured to parse a batch script configuration file corresponding to a target camera mode, obtain multiple configuration instructions, and determine the register configuration parameters, read-back verification rules, and functional module dependencies corresponding to each configuration instruction; a scheme generation unit, configured to generate a configuration execution queue based on the functional module to which each configuration instruction belongs and the functional module dependencies, and determine the execution control information corresponding to each configuration instruction; a configuration execution unit, configured to execute the multiple configuration instructions according to the configuration execution queue and the execution control information, write configuration values ​​to the corresponding target registers according to the register configuration parameters, and after completing the writing of the configuration values, read the target register status according to the corresponding read-back verification rules to determine whether the corresponding configuration instruction has been executed successfully; and a configuration recovery unit, configured to determine the affected recovery range based on the functional module to which the abnormal configuration instruction belongs and the functional module dependencies when the configuration instruction execution is abnormal, and perform recovery processing on the affected recovery range.

[0015] On the other hand, the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the above-described method for dynamically switching camera parameters that supports batch script configuration.

[0016] Through the above technical solution, this invention establishes a correspondence between configuration instructions, register configuration parameters, read-back verification rules, and functional module dependencies by parsing batch script configuration files, thus ensuring that the batch configuration process is no longer just a sequential blind write. During configuration execution, a configuration execution queue is generated according to the functional module dependencies, and the target register status is read after writing the configuration value, enabling timely confirmation of whether critical configurations have actually taken effect. When a configuration instruction execution error occurs, the affected recovery scope is determined based on the functional module to which the error configuration instruction belongs and its functional module dependencies. Recovery processing is only performed on the affected scope, avoiding the continuation of subsequent configurations or unnecessary global rewriting due to local errors. This reduces the risk of the camera remaining in an intermediate abnormal state and improves the stability and recovery reliability of the dynamic switching process.

[0017] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings: Figure 1This is a flowchart of the steps of a method for dynamically switching camera parameters that supports batch script configuration, provided by one embodiment of the present invention. Figure 2 This is a schematic diagram of the camera register configuration control link provided in one embodiment of the present invention; Figure 3 This is a schematic diagram of a camera image transmission link provided in one embodiment of the present invention; Figure 4 This is a schematic diagram of configuration execution queue generation based on functional module dependency provided by one embodiment of the present invention; Figure 5 This is a system structure diagram of a camera parameter dynamic switching system that supports batch script configuration, provided by one embodiment of the present invention. Detailed Implementation

[0019] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0020] like Figure 1 As shown, this embodiment of the invention provides a method for dynamically switching camera parameters that supports batch script configuration. The method includes: Step S10: Parse the batch script configuration file corresponding to the target camera mode to obtain multiple configuration instructions, and determine the register configuration parameters, read-back verification rules and functional module dependencies corresponding to each configuration instruction.

[0021] Specifically, the register configuration parameters include: target device identifier, target register address, and configuration value; the readback verification rules include: expected readback value, bitmask, and status determination conditions; the functional module dependency relationship includes the functional module to which each configuration instruction belongs, the preceding functional module of the functional module, and the downstream functional modules that depend on the functional module.

[0022] In this embodiment of the invention, after obtaining the batch script configuration file corresponding to the target camera mode, the batch script configuration file is parsed. The batch script configuration file can be an XML (extensible markup language) file, a JSON (JavaScript Object Notation) file, or a custom format script file, as long as it can express the register write and read-back verification relationship according to preset fields. After parsing, multiple configuration instructions are obtained, each configuration instruction corresponding to one register configuration operation, or corresponding to a group of register configuration operations with a continuous execution relationship.

[0023] For each configuration instruction, the corresponding register configuration parameters are determined. These parameters include the target device identifier, the target register address, and the configuration value. The target device can be a deserializer, serializer, or image sensor. The target register address indicates the register location to be written to, and the configuration value represents the parameter value to be written to that register in the target camera mode. For example, when switching to HDR mode, the configuration instruction may include configuration parameters for the image sensor output format register, frame synchronization register, and SerDes-related registers.

[0024] Simultaneously, readback verification rules corresponding to each configuration instruction are determined. These rules include the expected readback value, a bitmask, and status determination conditions. The bitmask is used to extract the valid status bits to be verified from the readback register status. The status determination conditions can be that the valid status bits are equal to a preset value, or that the link-locked state, PLL-locked state, or output-enabled state meets a preset condition. Furthermore, based on the hardware function of each configuration instruction, functional module dependencies are determined. These dependencies include the functional module to which each configuration instruction belongs, the preceding functional modules of each functional module, and the downstream functional modules that depend on each functional module. This ensures that subsequent configuration execution and anomaly recovery can be processed according to the functional association scope.

[0025] Step S20: Generate a configuration execution queue based on the functional module to which each configuration instruction belongs and the functional module dependencies, and determine the execution control information corresponding to each configuration instruction.

[0026] Specifically, a configuration execution queue is generated based on the functional modules to which each configuration instruction belongs and the dependencies between the functional modules. This includes: determining the preconditions for each configuration instruction according to the functional module dependencies; adding the corresponding configuration instruction to the configuration execution queue when the preconditions are met; and in the configuration execution queue, ensuring that configuration instructions related to link locking, clock locking, frame synchronization, video output format, and video output enable are executed before downstream configuration instructions that depend on the corresponding functional modules.

[0027] Furthermore, the execution control information includes: post-write waiting time, readback polling count, and retries count; the execution control information is determined based on the functional module to which each configuration instruction belongs, the historical anomaly records of the corresponding functional module, and the current camera link status; the historical anomaly records include at least one of: write no-response records, readback inconsistency records, read timeout records, and retry failure records.

[0028] Preferably, when the configuration instruction belongs to a link locking module, clock locking module, frame synchronization module, video output format module, or video output enable module, and the corresponding functional module has historical abnormal records or the current camera link status does not meet the preset stability conditions, the write wait time, read-back polling number, or retry number corresponding to the configuration instruction are increased within a preset range.

[0029] In this embodiment of the invention, the functional modules may include a link locking module, a clock locking module, a frame synchronization module, a video output format module, a video output enable module, an exposure gain module, and an auxiliary state module. During the switching between different camera modes, there are usually sequential dependencies between the functional modules. For example, the SerDes link locking state must be satisfied first for subsequent image sensor output format configuration and video receiver configuration to have a basis for execution; after the PLL is locked or the clock is stable, the frame synchronization and video output enable related configurations are suitable to continue execution.

[0030] Specifically, the preconditions for each configuration instruction are determined based on the functional module dependencies. These preconditions may include the preceding functional module having completed writing, the preceding functional module's readback state meeting the corresponding state judgment condition, or the preceding functional module not being in an abnormal recovery state. When the preconditions are met, the corresponding configuration instruction is added to the configuration execution queue. For configuration instructions related to link locking, clock locking, frame synchronization, video output format, and video output enable, since these instructions affect subsequent video stream establishment or image output status, they are executed before downstream configuration instructions that depend on the corresponding functional modules in the configuration execution queue. This order does not arbitrarily change the hardware timing defined in the chip manual or script, but rather organizes the execution order according to the functional module dependencies within the range allowed by the preset hardware timing.

[0031] Furthermore, corresponding execution control information is determined for each configuration instruction. This execution control information includes a write-after-wait time, read-back polling count, and retries. The write-after-wait time is used to wait for the target device to complete its internal response after writing the configuration value. The read-back polling count limits the maximum number of times the target register status is read. The retries limit the number of times the configuration instruction is rewritten if it fails to execute successfully. This execution control information can come from default fields in the batch script configuration file, or it can be adjusted based on the functional module to which each configuration instruction belongs, the historical anomaly records of the corresponding functional module, and the current camera link status.

[0032] The historical anomaly records may include at least one of the following: write no-response records, read-back inconsistency records, read timeout records, and retry failure records. The current camera link status may include at least one of the following: deserializer link lock status, serializer connection status, image sensor response status, and video reception status. For example, if a frame synchronization module experienced multiple read-back inconsistencies during a previous switch, or if the current SerDes link lock status exhibits brief jitter, then when executing the corresponding configuration command for that functional module, the write wait time, read-back polling count, or retry count can be increased within a preset range. For configuration commands that have a relatively small impact on link establishment, such as exposure gain, test patterns, or ordinary debugging parameters, the default execution control information can be used. In this way, the configuration execution queue and execution control information correspond to the functional modules of the configuration commands and the actual link status, facilitating subsequent execution of write, read-back verification, and anomaly handling according to the configuration execution queue.

[0033] In another possible implementation, the frame count status, frame synchronization status, or video receiver buffer status output by the current image sensor or deserializer is read, and configuration instructions related to video output format, frame synchronization, or video output enable are marked as frame boundary configuration instructions. These frame boundary configuration instructions are not written directly at any arbitrary time, but are added to the configuration execution queue and executed when the end of the current frame is detected, before the next frame has entered the valid image data output stage, or when the video receiver is in a preset short-term suspended state.

[0034] For configuration commands such as link locking and PLL locking that require prior stability confirmation, execution still follows the corresponding preconditions. In this way, the configuration execution queue can take into account both functional module dependencies and video frame boundary states, reducing anomalies caused by modifications to critical registers during valid image data output.

[0035] Step S30: Execute the multiple configuration instructions according to the configuration execution queue and the execution control information, write configuration values ​​to the corresponding target registers according to the register configuration parameters, and after completing the writing of the configuration values, read the status of the target registers according to the corresponding read-back verification rules to determine whether the corresponding configuration instructions have been executed successfully.

[0036] Specifically, the target register status is read according to the corresponding readback verification rule to determine whether the corresponding configuration instruction has been executed successfully. This includes: after completing the writing of the configuration value, waiting for hardware response according to the write wait time in the corresponding execution control information, and reading the actual status value of the target register; extracting the valid status bit using the bitmask in the readback verification rule, and comparing the valid status bit with the expected readback value or status determination condition; if any of the following is not met: read timeout, no write response, valid status bit mismatch, or status determination condition, the corresponding configuration instruction is determined to have not been executed successfully.

[0037] In this embodiment of the invention, for each configuration instruction, the target device identifier, target register address, and configuration value are first determined based on the register configuration parameters. The target device can be a deserializer, serializer, or image sensor. After determining the target device, the configuration value is written to the target register via the corresponding control bus. This control bus can be an I2C bus or other communication interface capable of performing register read / write control; this embodiment of the invention does not limit the specific type of bus.

[0038] After the configuration value is written, the system waits for a hardware response according to the write-after-wait time specified in the execution control information corresponding to the configuration instruction. This write-after-wait time is used to allow processing time for internal state updates, link locking, clock stabilization, or output state switching of the target device. For example, the write-after-wait time can be shorter for ordinary exposure gain registers; for PLL locking, frame synchronization, or video output enable registers, the write-after-wait time can be appropriately extended according to the script settings or execution control information.

[0039] After the waiting period ends, the actual status value of the target register is read, and the success of the configuration instruction is determined according to the corresponding readback verification rules. Specifically, the valid status bits are extracted from the actual status value using a bitmask in the readback verification rules to avoid including irrelevant bits, reserved bits, or hardware-automatically-changing bits in the judgment. Then, the valid status bits are compared with the expected readback value, or it is determined whether the valid status bits meet the corresponding status determination conditions. The status determination conditions may include a valid link lock status, a valid PLL lock status, a frame synchronization status meeting a preset state, and a video output enable status being set, etc.

[0040] If a read timeout, write failure, mismatch between the extracted valid status bits and the expected read-back value, or failure to meet the status judgment conditions occurs when reading the target register, the corresponding configuration instruction is determined to have failed to execute. For configuration instructions that fail to execute, the execution control information of the configuration instruction can be used to determine whether to rewrite and reread for verification. If the read-back verification rules are still not met after retrying, the configuration instruction is treated as an abnormal configuration instruction, so that subsequent steps can determine the affected recovery scope based on the functional module to which the abnormal configuration instruction belongs and the functional module dependencies.

[0041] In another possible implementation, for configuration instructions related to link locking, PLL locking, frame synchronization, or video output enable, after writing the configuration value and reading the target register status, in addition to using a single readback result as the basis for successful execution, a readback stability window can be set. Specifically, after the post-write wait time ends, the target register status is read continuously at preset intervals, and valid status bits are extracted using bitmasks. The configuration instruction is considered successful only when the valid status bits meet the expected readback value or status determination condition in multiple consecutive reads. If the first readback meets the condition but subsequent readbacks show a jump, the configuration instruction is marked as an unstable instruction, and polling or retrying is performed according to the corresponding execution control information. This method avoids the mistaken assumption that a brief link lock, instantaneous clock readiness, or status bit jitter has resulted in a stable and effective configuration.

[0042] Step S40: When a configuration instruction execution error occurs, determine the affected recovery scope based on the functional module to which the abnormal configuration instruction belongs and the functional module dependencies, and perform recovery processing on the affected recovery scope.

[0043] Specifically, before executing the plurality of configuration instructions according to the configuration execution queue and the execution control information, the method includes: reading the register states of the deserializer, serializer, and image sensor corresponding to the functional module dependencies in the current camera mode to generate a state snapshot of the current camera link; the state snapshot is used to determine the recovery parameters of the corresponding functional module during recovery processing.

[0044] Specifically, the functional module to which the abnormal configuration instruction belongs, the downstream functional modules that depend on the functional module to which the abnormal configuration instruction belongs, and the associated functional modules whose readback states do not meet the stability conditions are determined as candidate recovery ranges. Based on the register attributes of each target register within the candidate recovery range, read-only status registers, hardware auto-update registers, and status bit registers that are not allowed to be recovered are eliminated to obtain a set of recoverable registers. The target registers in the set of recoverable registers whose current readback values ​​are inconsistent with the corresponding register states in the status snapshot are determined as differential recovery registers. Based on the recovery parameters corresponding to the differential recovery registers in the status snapshot, recovery writing is performed on the differential recovery registers, and the recovery result is confirmed based on the readback states of the read-only status registers or hardware auto-update registers after the recovery writing.

[0045] In this embodiment of the invention, before executing multiple configuration instructions according to the configuration execution queue and execution control information, the stabilization register state in the current camera mode is read to generate a state snapshot of the current camera link. Specifically, the register states corresponding to functional modules involved in the functional module dependencies in the deserializer, serializer, and image sensor can be read, such as link lock-related registers, clock lock-related registers, frame synchronization registers, video output format registers, and video output enable registers. The state snapshot can be stored according to functional modules, so that each functional module corresponds to a set of recovery parameters. When subsequent configuration instructions fail to execute, the corresponding recovery parameters can be read from the state snapshot according to the functional module to which the abnormal configuration instruction belongs and the affected recovery range, without needing to perform indiscriminate recovery of all registers.

[0046] When step S30 determines that a configuration instruction execution is abnormal, the configuration instruction is treated as an abnormal configuration instruction, and the affected recovery range is determined based on the functional module to which the abnormal configuration instruction belongs and the functional module dependencies. The affected recovery range is not directly equivalent to all registers, nor is it limited to the single register corresponding to the abnormal configuration instruction; rather, a candidate recovery range is first determined. Specifically, the functional module to which the abnormal configuration instruction belongs, the downstream functional modules that depend on the functional module to which the abnormal configuration instruction belongs, and the associated functional modules whose current readback state does not meet the stability condition are determined as candidate recovery ranges. For example, if the abnormal configuration instruction belongs to the clock locking module, the candidate recovery range may include the clock locking module itself, the frame synchronization module that depends on the clock state, and the video output format module; if the abnormal configuration instruction only belongs to the exposure gain module, and both the link locking and frame synchronization states are normal, the candidate recovery range can be limited to exposure gain-related modules.

[0047] Furthermore, the target registers within the candidate recovery range are evaluated for attributes. Register attributes can be determined based on the script configuration file, device register description table, or preset register attribute table. For read-only status registers, hardware auto-update registers, and registers containing status bits that disallow recovery writes, recovery writes are not performed directly; instead, these registers are used as readback objects when confirming the recovery result. For registers that allow writes and are suitable for recovery, a set of recoverable registers is formed.

[0048] After obtaining the set of recoverable registers, the current readback value of each target register in the set is read and compared with the corresponding register status in the status snapshot. If they match, the target register remains in the recovery baseline state and does not need to be rewritten; if they do not match, the target register is identified as the differential recovery register. Subsequently, recovery writing is performed on the differential recovery register according to the recovery parameters corresponding to the differential recovery register in the status snapshot. After the recovery writing is completed, the status of the read-only status register or the hardware auto-update register is read again, such as the link lock status, PLL lock status, or video output status, to confirm whether the camera link after recovery meets the stability conditions.

[0049] Example

[0050] The dynamic switching of camera parameters can be completed by the host computer software in conjunction with the data acquisition device. See also Figure 2 After the host computer software loads the batch script configuration file corresponding to the target camera mode, it sends the configuration task to the acquisition device via USB control commands. The acquisition device then configures the target registers in the deserializer, serializer, and image sensor via I2C register write or pass-through access. After each write operation, the host computer software or acquisition device can also read the corresponding register status and use the read-back result as the basis for verification.

[0051] See Figure 3 The image data output by the camera is transmitted along the direction of the image sensor, serializer, coaxial link or SerDes link, deserializer, acquisition device and host computer software. This image transmission link works in conjunction with the configuration control link, but the data flow and target of the two are different.

[0052] Further integration Figure 4When executing batch script configuration files, the scripts are first parsed to obtain a set of configuration instructions, and the functional modules to which each configuration instruction belongs are identified. Then, the dependencies between these functional modules are analyzed. When the preconditions for a configuration instruction are met, the instruction is added to the configuration execution queue according to its dependencies. When the preconditions are not met, the process waits for the corresponding precondition functional module to complete. Simultaneously, execution control information is determined based on historical anomaly records and the current camera link status. This execution control information includes the write wait time, readback polling count, and retries. In this way, multiple configuration instructions in the batch script configuration files can be executed in an orderly manner according to functional module dependencies and the current link status, facilitating subsequent register writing, readback verification, and anomaly recovery processing.

[0053] like Figure 5 As shown, this invention provides a dynamic switching system for camera parameters that supports batch script configuration. The system includes: a configuration parsing unit, used to parse the batch script configuration file corresponding to the target camera mode, obtain multiple configuration instructions, and determine the register configuration parameters, read-back verification rules, and functional module dependencies corresponding to each configuration instruction; a scheme generation unit, used to generate a configuration execution queue based on the functional module to which each configuration instruction belongs and the functional module dependencies, and determine the execution control information corresponding to each configuration instruction; a configuration execution unit, used to execute the multiple configuration instructions according to the configuration execution queue and the execution control information, write configuration values ​​to the corresponding target registers according to the register configuration parameters, and after completing the writing of the configuration values, read the target register status according to the corresponding read-back verification rules to determine whether the corresponding configuration instruction has been executed successfully; and a configuration recovery unit, used to determine the affected recovery range based on the functional module to which the abnormal configuration instruction belongs and the functional module dependencies when the configuration instruction execution is abnormal, and perform recovery processing on the affected recovery range.

[0054] The present invention also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the above-described method for dynamically switching camera parameters that supports batch script configuration.

[0055] Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a microcontroller, chip, or processor to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0056] The optional embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the embodiments of the present invention are not limited to the specific details described above. Within the scope of the technical concept of the embodiments of the present invention, various simple modifications can be made to the technical solutions of the embodiments of the present invention, and these simple modifications all fall within the protection scope of the embodiments of the present invention. It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, the embodiments of the present invention will not further describe the various possible combinations.

[0057] Furthermore, various different embodiments of the present invention can be combined in any way, as long as they do not violate the spirit of the embodiments of the present invention, they should also be regarded as the content disclosed by the embodiments of the present invention.

Claims

1. A method for dynamically switching camera parameters that supports batch script configuration, characterized in that, The method includes: The batch script configuration file corresponding to the target camera mode is parsed to obtain multiple configuration instructions, and the register configuration parameters, read-back verification rules and functional module dependencies corresponding to each configuration instruction are determined. Based on the functional modules to which each configuration instruction belongs and the dependencies between the functional modules, a configuration execution queue is generated, and the execution control information corresponding to each configuration instruction is determined. The multiple configuration instructions are executed according to the configuration execution queue and the execution control information. Configuration values ​​are written to the corresponding target registers according to the register configuration parameters. After the configuration values ​​are written, the target register status is read according to the corresponding read-back verification rules to determine whether the corresponding configuration instructions have been executed successfully. When a configuration instruction fails to execute, the affected recovery scope is determined based on the functional module to which the abnormal configuration instruction belongs and the functional module dependencies, and recovery processing is performed on the affected recovery scope.

2. The method for dynamically switching camera parameters supporting batch script configuration according to claim 1, characterized in that, Before executing the plurality of configuration instructions according to the configuration execution queue and the execution control information, the method includes: Read the register states in the deserializer, serializer, and image sensor corresponding to the dependencies of the functional modules in the current camera mode to generate a snapshot of the current camera link state; The status snapshot is used to determine the recovery parameters of the corresponding functional module during the recovery process.

3. The method for dynamically switching camera parameters supporting batch script configuration according to claim 1, characterized in that, The register configuration parameters include: Target device identifier, target register address, and configuration value; The readback verification rules include: Expected readback values, bitmasks, and status determination conditions; The functional module dependencies include the functional module to which each configuration instruction belongs, the preceding functional module of the functional module, and the downstream functional modules that depend on the functional module.

4. The method for dynamically switching camera parameters supporting batch script configuration according to claim 1, characterized in that, The step of generating a configuration execution queue based on the functional modules to which each configuration instruction belongs and their dependencies includes: The prerequisites for each configuration instruction are determined according to the functional module dependencies. If the prerequisites are met, the corresponding configuration instruction is added to the configuration execution queue. In the configuration execution queue, configuration instructions related to link locking, clock locking, frame synchronization, video output format, and video output enable are executed before downstream configuration instructions that depend on the corresponding functional modules.

5. The method for dynamically switching camera parameters supporting batch script configuration according to claim 1, characterized in that, The execution control information includes: Write wait time, read-back polling count, and retries; The execution control information is determined based on the functional module to which each configuration instruction belongs, the historical anomaly records of the corresponding functional module, and the current camera link status. The historical anomaly records include: Write at least one of the following: no response record, inconsistent read record, read timeout record, and retry failure record.

6. The method for dynamically switching camera parameters supporting batch script configuration according to claim 5, characterized in that, When the configuration instruction belongs to a link locking module, clock locking module, frame synchronization module, video output format module, or video output enable module, and the corresponding functional module has historical abnormal records or the current camera link status does not meet the preset stability conditions, the write wait time, read-back polling count, or retries count corresponding to the configuration instruction are increased within the preset range.

7. The method for dynamically switching camera parameters supporting batch script configuration according to claim 1, characterized in that, The step of reading the target register status according to the corresponding readback verification rules to determine whether the corresponding configuration instruction has been executed successfully includes: After completing the writing of the configuration value, wait for the hardware response according to the write wait time in the corresponding execution control information, and read the actual status value of the target register. The valid status bits are extracted using the bitmask in the readback verification rule, and the valid status bits are compared with the expected readback value or status determination condition; If any of the following conditions are not met: read timeout, write no response, valid status bit mismatch, or status determination condition, the corresponding configuration instruction is determined to have failed to execute.

8. The method for dynamically switching camera parameters supporting batch script configuration according to claim 2, characterized in that, The step of determining the affected recovery scope based on the functional module to which the abnormal configuration instruction belongs and the functional module dependencies, and performing recovery processing on the affected recovery scope, includes: The functional module to which the abnormal configuration instruction belongs, the downstream functional modules that depend on the functional module to which the abnormal configuration instruction belongs, and the associated functional modules whose readback states do not meet the stability conditions are identified as candidate recovery ranges. Based on the register attributes of each target register within the candidate recovery range, read-only status registers, hardware auto-update registers, and status bit registers that are not allowed to be recovered are eliminated to obtain a set of recoverable registers; The target register whose current readback value in the recoverable register set is inconsistent with the corresponding register state in the state snapshot is identified as the difference recovery register; Based on the recovery parameters corresponding to the differential recovery register in the state snapshot, a recovery write is performed on the differential recovery register, and the recovery result is confirmed based on the read-back status of the read-only status register or the hardware auto-update register after the recovery write.

9. A system for dynamically switching camera parameters that supports batch script configuration, characterized in that, The system includes: The configuration parsing unit is used to parse the batch script configuration file corresponding to the target camera mode, obtain multiple configuration instructions, and determine the register configuration parameters, read-back verification rules and functional module dependencies corresponding to each configuration instruction. The scheme generation unit is used to generate a configuration execution queue based on the functional module to which each configuration instruction belongs and the functional module dependency relationship, and to determine the execution control information corresponding to each configuration instruction; The configuration execution unit is configured to execute the plurality of configuration instructions according to the configuration execution queue and the execution control information, write configuration values ​​to the corresponding target registers according to the register configuration parameters, and after completing the writing of the configuration values, read the status of the target registers according to the corresponding read-back verification rules to determine whether the corresponding configuration instructions have been executed successfully. The configuration recovery unit is used to determine the affected recovery scope based on the functional module to which the abnormal configuration instruction belongs and the functional module dependency relationship when the configuration instruction is executed abnormally, and to perform recovery processing on the affected recovery scope.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the dynamic switching method for camera parameters supporting batch script configuration as described in any one of claims 1-8.

Images