Point screen system, point screen method, host computer and point screen testing device

Abstract

The application relates to a point screen system, a point screen method, an upper computer and a point screen testing device. The point screen system comprises an application module, a processing module and a driving module. The application module is used for acquiring module information of a to-be-tested panel and a user-indicated test-related parameter of the to-be-tested panel. The processing module is used for selecting a corresponding target analysis library from at least one candidate analysis library according to the module information, and adopting the target analysis library to analyze the test-related parameter to obtain a hardware instruction sequence. The driving module is used for adopting the hardware instruction sequence to drive the to-be-tested panel.

Description

Technical Field

[0001] This application relates to the field of display panel testing technology, and in particular to a screen dotting system, screen dotting method, host computer, and screen dotting test device. Background Technology

[0002] In the manufacturing process of display panels (also known as displays or screens), screen testing is a critical quality control step. Before leaving the factory, qualified panels must undergo screen testing (screen lighting test) to observe whether the panel can be lit up, whether there is screen flickering, light leakage, defective points or dead pixels, and then the panels with quality problems are graded and processed.

[0003] The screen testing system requires modifications to the driver layer to adapt to different types of panels under test. This necessitates modifications to the underlying firmware of the driver layer to achieve compatibility with different panels, increasing the user's workload and the complexity of the testing process.

[0004] How to make the screen display system better adapt to different types of panels under test, and reduce the workload of users and the complexity of testing, is an urgent problem to be solved. Summary of the Invention

[0005] In view of the above, this application provides a screen-pointing system, a screen-pointing method, a host computer, and a screen-pointing testing device to solve at least one problem existing in the background art.

[0006] In a first aspect, embodiments of this application provide a screen-dotting system, the screen-dotting system comprising: The application module is used to obtain the module information of the panel under test and the test-related parameters of the panel under test as indicated by the user. The processing module is used to select a corresponding target parsing library from at least one candidate parsing library according to the module information, and use the target parsing library to parse the test association parameters to obtain a hardware instruction sequence; A driver module is used to drive the panel under test using the hardware instruction sequence.

[0007] In some embodiments, the application module is specifically used for: Obtain user commands from the user interface; The module information and the test-related parameters are determined based on user instructions.

[0008] In some embodiments, the test correlation parameters include at least one of the following: Test mode parameters associated with the test type; Display debugging parameters associated with the display parameters of the panel under test; Quality criterion parameters associated with the test judgment threshold; Communication adaptation parameters associated with the communication between the dot-screen system and the panel under test.

[0009] In some embodiments, the processing module is further configured to read module information of the panel under test and send the module information to the application module; The application module is specifically used to: receive the module information sent by the processing module.

[0010] In some embodiments, the application module further specifically includes: Based on the target parsing library, the candidate test association parameters corresponding to the target parsing library are displayed to the user. Based on user instructions, determine the test association parameter selected by the user from the candidate test association parameters.

[0011] In some embodiments, the processing module is further configured to: verify the test-related parameters.

[0012] In some embodiments, the hardware instruction sequence includes at least one of the following: The initialization parameters of the panel under test; Test mode configuration.

[0013] In some embodiments, the processing module is further configured to send the hardware instruction sequence to the driver module via an application programming interface.

[0014] In some embodiments, the driver module is specifically used for at least one of the following: Based on the hardware instruction sequence, a drive signal is output to the panel under test; The feedback signal of the panel under test is acquired based on the hardware instruction sequence.

[0015] Secondly, embodiments of this application provide a screen tapping method, the screen tapping method comprising: Obtain the module information of the panel under test and the test-related parameters of the panel under test as indicated by the user; Based on the module information, a corresponding target parsing library is selected from at least one candidate parsing library, and the target parsing library is used to parse the test-related parameters to obtain a hardware instruction sequence; The panel under test is driven using the aforementioned hardware instruction sequence.

[0016] Thirdly, embodiments of this application provide a screen-clicking system, the screen-clicking system comprising: a host computer and a screen-clicking testing device, wherein the host computer includes: an application module and a processing module, and the screen-clicking testing device includes a driver module, wherein... The application module is used to obtain the module information of the panel under test and the test-related parameters of the panel under test as indicated by the user. The processing module is used to select a corresponding target parsing library from at least one candidate parsing library according to the module information, and use the target parsing library to parse the test association parameters to obtain a hardware instruction sequence; The driving module is used to drive the panel under test using the hardware instruction sequence.

[0017] Fourthly, embodiments of this application provide a host computer, the host computer comprising: The application module is used to obtain the module information of the panel under test and the test-related parameters of the panel under test as indicated by the user. The processing module is used to select a corresponding target parsing library from at least one candidate parsing library according to the module information, and use the target parsing library to parse the test-related parameters to obtain a hardware instruction sequence; the hardware instruction sequence is used to drive the panel under test by the driving module of the dot-screen testing device.

[0018] Fifthly, embodiments of this application provide a screen testing device, the screen testing device comprising: A driver module is used to drive the panel under test using a hardware instruction sequence; wherein the hardware instruction sequence is obtained by the application module of the host computer selecting the corresponding target parsing library from at least one candidate parsing library according to the module information, and using the target parsing library to parse the test association parameters; wherein the module information and the test association parameters are obtained by the application module of the host computer, and the test association parameters are indicated by the user.

[0019] This application provides a screen-pointing system, screen-pointing method, host computer, and screen-pointing testing device. The screen-pointing system includes: an application module for acquiring module information and test-related parameters of the panel under test; a processing module for selecting a corresponding target parsing library from at least one candidate parsing library based on the module information, and using the target parsing library to parse the test-related parameters to obtain a hardware instruction sequence; and a driver module for driving the panel under test using the hardware instruction sequence. The screen-pointing system achieves automatic adaptation to different types of panels under test through the coordinated operation of the application module, processing module, and driver module, thereby reducing repeated modifications to the underlying firmware of the driver layer. The application module is configured to acquire module information and test-related parameters of the panel under test. The module information and test-related parameters are the basic input data for system operation, ensuring the relevance and accuracy of subsequent processing. The processing module selects a corresponding target parsing library from at least one candidate parsing library based on the module information, and uses the target parsing library to parse the test-related parameters, thereby generating a hardware instruction sequence; using the module information as a unique identifier for the panel type, it dynamically matches and adapts the parsing logic, automatically converting the test parameters into hardware executable instructions. The driver module directly drives the panel under test to complete the screen tapping operation using a sequence of hardware instructions, achieving seamless integration between the analysis results and hardware control. Manual input of test-related parameters improves the rationality of the parameter range and enhances the flexibility of parameter configuration. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the composition structure of a dot-screen system according to an embodiment of this application. Figure 1 ; Figure 2 This is a schematic diagram of the composition structure of a dot-screen system according to an embodiment of this application. Figure 2 ; Figure 3 This is a schematic diagram of the composition structure of a host computer according to an embodiment of this application; Figure 4 This is a schematic diagram of the composition structure of a dot-screen testing device according to an embodiment of this application; Figure 5 This is a schematic flowchart illustrating a screen tapping method according to an embodiment of this application. Detailed Implementation

[0021] To make the technical solution and beneficial effects of this application more apparent and understandable, a detailed description is provided below by listing specific embodiments. The accompanying drawings are not necessarily drawn to scale, and local features may be enlarged or reduced to more clearly show the details of the local features; unless otherwise defined, the technical and scientific terms used herein have the same meanings as those in the technical field to which this application pertains.

[0022] The embodiments in this application are not exhaustive, but merely illustrative of some embodiments, and are not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments.

[0023] In each embodiment of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of the embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0024] In the description of the embodiments of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0025] In the traditional display panel manufacturing process, the screen detection stage requires modifying the underlying firmware of the driver layer to adapt to different types of panels under test, which increases the user's workload and the complexity of testing. This problem stems from the lack of an automated module information recognition and instruction generation mechanism, necessitating manual intervention in the firmware configuration process each time the panel type is changed, thus affecting testing efficiency and system adaptability.

[0026] For example, display panels come with various interfaces, such as MIPI and LVDS, and their display technologies may also differ, such as LCD and LED panels. When performing multi-model panel testing on a display panel production line, panels with different interfaces are often encountered. Operators need to manually adjust timing parameters and voltage configurations in the driver layer firmware. Furthermore, this process involves recompiling the firmware code and burning it to the testing equipment, increasing the risk of test interruptions and configuration errors. Consequently, the system cannot quickly respond to changes in panel type, leading to extended testing cycles and increased maintenance costs.

[0027] This embodiment provides a dot-screen system, such as Figure 1As shown, the screen display system 10 includes: an application module 100, used to acquire module information of the panel under test and test-related parameters of the panel under test indicated by the user; a processing module 200, used to select a corresponding target parsing library from at least one candidate parsing library according to the module information, and use the target parsing library to parse the test-related parameters to obtain a hardware instruction sequence; and a driving module 300, used to drive the panel under test using the hardware instruction sequence.

[0028] Here, the application module, processing module, and driver module can be located in different physical devices or in the same physical device.

[0029] In one possible implementation, the application module and processing module can reside in one physical device, while the driver module resides in another. For example, the application module and processing module can reside in the host computer of the screen-on-demand system, while the driver module resides in the screen-on-demand testing device of the system. The screen-on-demand testing device can be directly connected to the panel under test and drive it. The screen-on-demand testing device can also test the lighting results of the panel under test.

[0030] Module information can be used to indicate the type of the panel under test (including interface type and / or panel display technology type). Different types of panels under test may have different driving methods and control logic. For example, module information may include a unique ID that indicates the type of the panel under test.

[0031] Test-related parameters may include a set of configuration parameters related to the test process of the panel under test, such as the test voltage of the panel under test, and / or the resolution used for the test of the panel under test.

[0032] In one possible implementation, test-related parameters can be used to indicate the tests performed on the panel under test.

[0033] At least some of the test-related parameters can be configured by the user, which improves configuration flexibility and the rationality of the parameter range compared to automatic system configuration, and reduces chaotic operation processes and repetitive configuration.

[0034] In one possible implementation, users can configure core parameters in the test-related parameters, thereby reducing the workload of manual configuration.

[0035] The candidate parsing library can include a database storing different types of panel parsing rules. Each candidate parsing library can have a correspondence with different module information. For example, one candidate parsing library can correspond to one module information, or one candidate parsing library can correspond to multiple module information.

[0036] In practical applications, the parsing library (candidate parsing library and target parsing library) can be encapsulated in the form of a dynamic link library (DLL).

[0037] The hardware instruction sequence is generated into the low-level control instruction stream required to drive the panel.

[0038] The processing module can determine the corresponding target parsing library based on the module information according to the corresponding relationship, and use the target parsing library to parse the test-related parameters to obtain the hardware instruction sequence. The processing module dynamically selects the target parsing library and parses the test-related parameters according to the module information, reducing the need for modifications to the underlying firmware of the driver layer, and realizing automatic adaptation of the touch screen system to different types of panels under test, thereby reducing the complexity of user operation steps and testing processes.

[0039] For example, the application module can be specifically implemented as a data acquisition program running on an industrial control computer to receive module information and test-related parameters; the processing module can use a matching algorithm based on module information to select a target parsing library from multiple predefined parsing libraries stored in memory, and perform parameter parsing operations to generate a hardware instruction sequence; the driving module can be specifically a field-programmable gate array (FPGA) chip, which outputs corresponding driving signals according to the hardware instruction sequence to control the panel under test.

[0040] By employing a modular collaboration mechanism, the reliance on customized modifications to the underlying firmware of the driver layer is reduced, enabling the system to quickly adapt to different types of panels under test. As a result, users no longer need to manually adjust the underlying program for each panel type, simplifying the testing process, reducing the user's operational burden and the complexity of the testing work, thereby improving the efficiency of screen detection.

[0041] The screen-pointing system achieves automatic adaptation to different types of panels under test through the coordinated operation of application, processing, and driver modules, thereby reducing redundant modifications to the underlying firmware of the driver layer. The application module is configured to acquire the module information and test-related parameters of the panel under test. This information serves as the basic input data for system operation, ensuring the targeted and accurate nature of subsequent processing. The processing module selects the corresponding target parsing library from at least one candidate parsing library based on the module information and uses this library to parse the test-related parameters, generating a hardware instruction sequence. Using the module information as a unique identifier for the panel type, it dynamically matches and adapts the parsing logic, automatically converting the test parameters into hardware-executable instructions. The driver module then directly drives the panel under test to complete the screen-pointing operation using the hardware instruction sequence, achieving seamless integration between the parsing results and hardware control. Manual input of the test-related parameters improves the rationality of the parameter range and enhances the flexibility of parameter configuration.

[0042] In some embodiments, the application module is specifically used for: obtaining user instructions from the user interface; and determining the module information and the test association parameters based on the user instructions.

[0043] User interfaces can include human-computer interaction interfaces, which can be implemented using graphical user interfaces (GUIs) or touchscreen interfaces, with the aim of providing a channel for user input.

[0044] Determining module information and test-related parameters based on user instructions can include application modules allowing users to select and / or input module information and test-related parameters through the user interface.

[0045] In one possible implementation, the user interface can be configured with default module information and / or test-related parameters. The default module information and / or test-related parameters can be used when the user does not input or select anything.

[0046] For example, the application module receives real-time commands from the user interface, parses these commands as a dynamic input source, and generates module information and test-related parameters that match the type of panel under test. This replaces the traditional method that relies on predefined configurations, ensuring that test parameters are customized as needed. Based on this, the processing module selects a target parsing library according to the dynamically generated module information to parse the test-related parameters and generate a hardware instruction sequence. The driver module then executes the panel test accordingly, forming a complete closed loop from user input to test execution, reducing the need to modify the underlying firmware of the driver layer when adapting to new panel types.

[0047] For example, a user selects the model identifier of the panel under test through a graphical user interface. After receiving the user's instruction, the application module calls the rule engine parsing module to determine the corresponding module information and test-related parameters. The rule engine can dynamically generate test parameters based on a preset model-parameter mapping relationship. In this way, the touchscreen system can adapt to different types of panels under test without modifying the underlying firmware of the driver layer, reducing the user's operational burden and the complexity of the testing work.

[0048] In some embodiments, the test correlation parameters include at least one of the following: Test mode parameters associated with the test type; Display debugging parameters associated with the display parameters of the panel under test; Quality criterion parameters associated with the test judgment threshold; Communication adaptation parameters associated with the communication between the dot-screen system and the panel under test.

[0049] In one possible implementation, different test-related parameters can provide inputs and / or options for the user to input and / or select different parameter values.

[0050] In one possible implementation, each test-related parameter can be set with a default value, which the user can modify based on.

[0051] Test mode parameters can be used to characterize the test type of the panel under test, such as illumination test, optical test, etc. Different panels may have different test types, so users can select the specific test type.

[0052] Display debugging parameters can be used to characterize the specific display parameters of the panel under test during testing, such as brightness and screen tilt angle. Users can input and / or select specific values ​​based on the specific needs of the panel under test in actual applications to adapt to the application scenario.

[0053] Display debugging parameters can be used to characterize the test judgment thresholds of the panel under test during testing. For example, for brightness testing, users can set the brightness threshold range based on the characteristics of different panels under test. During testing, if the brightness value of the panel under test is within the brightness threshold range, it is judged as qualified; otherwise, it is judged as unqualified.

[0054] Communication adaptation parameters are used to configure communication parameters between the dot-screen system and the panel under test, such as data transmission bit rate. Since different panels under test use different communication protocols and have different communication rates, the dot-screen system can meet the communication requirements of different panels by setting the communication adaptation parameters.

[0055] In some embodiments, the processing module is further configured to read module information of the panel under test and send the module information to the application module; The application module is specifically used to: receive the module information sent by the processing module.

[0056] Here, the processing module can read module information through its connection with the panel under test. For example, the processing module can read the ID of the panel under test.

[0057] In one possible implementation, the processing module can directly match the corresponding target parsing library based on the read module information.

[0058] The application module can receive module information acquired by the processing module. This improves the automation capability of module information acquisition.

[0059] In some embodiments, the application module further specifically includes: Based on the target parsing library, the candidate test association parameters corresponding to the target parsing library are displayed to the user. Based on user instructions, determine the test association parameter selected by the user from the candidate test association parameters.

[0060] After the processing module determines the target parsing library, the application module can select corresponding candidate test-related parameters based on the target parsing library for the user to choose or adjust.

[0061] Users can interact with the application modules through the interactive interface to select test-related parameters.

[0062] In one possible implementation, candidate test-related parameters can be displayed by category (e.g., by test mode parameters; display debugging parameters; quality criterion parameters; communication adaptation parameters). This improves the regularity of parameter display and reduces the difficulty of user operation.

[0063] Candidate test-related parameters can provide specific parameter values ​​for user confirmation or adjustment. For example, it can display: backlight brightness default 0x20, test duration default 10s. Users can confirm or adjust candidate test-related parameters through human-computer interaction to obtain confirmed test-related parameters.

[0064] In this way, by selecting candidate test-related parameters based on the target parsing library through the application module, the user does not need to input each parameter one by one, which can reduce the user's load of inputting all parameters and reduce invalid operations.

[0065] In some embodiments, the processing module is further configured to: verify the test-related parameters.

[0066] In one possible implementation, validating the test-related parameters includes: validating the legality of the test-related parameters.

[0067] Validation includes at least verifying whether the test-related parameters meet different specifications (such as communication protocols). This reduces the likelihood of users inputting invalid parameters and improves the reliability of parameter input.

[0068] For example, the processing module can call the verification logic in a dedicated DLL to verify the test-related parameters. For example, the baud rate must be an integer multiple of 1.2Kbps, and the number of bad pixels cannot be negative. If the verification fails, the processing module can return an error message (such as "timeout must be between 1s and 10s") through the application module for the user to modify. In some embodiments, the hardware instruction sequence includes at least one of the following: The initialization parameters of the panel under test; Test mode configuration.

[0069] Initialization parameters can include basic configuration data required when the panel under test (DUT) starts up. Initialization parameters can include one or more of the following: voltage settings, timing parameters, or communication protocol configuration. Initialization parameters can be used to ensure the panel is accurately initialized to a working state, reducing screen failures caused by parameter mismatches.

[0070] Test mode configuration can include the specific display method of the panel, such as the displayed color, color temperature, and illumination duration. This allows the system to dynamically adapt to the testing requirements of different panels, enabling flexible adjustments to the test process without relying on manual modifications to the driver layer code.

[0071] By configuring initialization parameters and test modes, the processing module can generate a complete instruction sequence from the target parsing library based on the module information. Initialization parameters ensure that key operating parameters are accurately configured for the panel during startup, thus eliminating detection anomalies caused by initialization mismatches. Test mode configuration dynamically defines the specific execution logic of the test process, enabling the system to automatically adjust test strategies for different panel types. Together, these two mechanisms give the hardware instruction sequence universality and flexibility, allowing the system to adapt to diverse panels without repeatedly modifying the underlying driver firmware, fundamentally simplifying the operation of the touchscreen system.

[0072] This reduces the need for frequent modifications to the underlying firmware of the driver layer due to changes in panel type, lowers the workload and complexity of testing when adapting to different panels under test, and improves the versatility and operational efficiency of the touch screen system.

[0073] In some embodiments, the processing module is further configured to send the hardware instruction sequence to the driver module via an application programming interface.

[0074] Application Programming Interface (API) can refer to a standardized software communication mechanism used for data exchange between different software modules. It can be implemented using function call libraries, message queue middleware, or remote procedure call protocols. Its purpose is to decouple the instruction transmission process from the underlying hardware implementation and reduce the need to adjust the underlying code of the driver module due to changes in panel type.

[0075] For example, after the verification is successful, the processing module converts the user input parameters into a hardware instruction sequence (such as "Test type = optical test + brightness = 0x30" corresponding to instruction 0x020x1E0x30), and sends it to the driver module through the API; the driver module performs standard operations (signal output, data acquisition) to complete the screen test.

[0076] This application establishes a unified abstraction layer between the processing module and the driver module through an application programming interface (API). After the processing module generates a hardware instruction sequence, it can send it using the standard method defined by the interface. The driver module parses the sequence and performs corresponding operations through a preset interface receiving point. Since the interface specification is independent of specific hardware details, there is no need to modify the underlying implementation of the driver module, thereby ensuring the reliability and consistency of data transmission and reducing compatibility issues caused by direct hardware interaction.

[0077] In one possible implementation, the driver module is also used to feed back test results to the processing module.

[0078] In one possible implementation, the processing module is used to compare the test results with the quality criterion parameters.

[0079] In one possible implementation, the application module is used to display to the user the comparison results of the processing module's comparative test results and the comparison results of the quality criterion parameters.

[0080] For example, the driver module sends the collected test data back to the processing module, which then generates a test report (such as "brightness detection value 350cd / m² ≥ threshold 300cd / m², qualified") by combining the quality criteria parameters configured by the user. The report is then displayed in the form of charts and text by the application module.

[0081] Thus, the processing module actively judges the test results by combining the quality criterion parameters provided by the user. On the one hand, having the processing module judge the test results improves automation and reduces the user's workload. On the other hand, actively judging the test results by combining quality criterion parameters, rather than judging based on fixed values, increases the flexibility of test result judgment and adapts to different scenarios. In some embodiments, the driving module is specifically used for at least one of the following: Based on the hardware instruction sequence, a drive signal is output to the panel under test; The feedback signal of the panel under test is acquired based on the hardware instruction sequence.

[0082] Outputting drive signals to the panel under test based on a hardware instruction sequence can include a drive module dynamically generating electrical signals adapted to the panel's characteristics according to the instructions in the hardware instruction sequence. For example, the drive module can be implemented using a digital signal processor or a field-programmable gate array to improve the matching between the drive signal and the panel's initialization parameters and test mode configuration; Acquiring feedback signals from the panel under test based on a hardware instruction sequence can include a driver module that executes data acquisition operations according to predefined feedback instructions in the hardware instruction sequence. The driver module can be implemented using an analog-to-digital converter or a general-purpose input / output interface. Its purpose is to leverage the differences in panel feedback mechanisms already reflected in the instruction sequence to achieve flexible adaptation of the acquisition behavior, eliminating the need to develop dedicated code for each panel.

[0083] By relying entirely on hardware instruction sequences to execute signal output and feedback acquisition operations, the driver module achieves universality and configurability of driver behavior. The processing module dynamically parses test-related parameters using a target parsing library to generate hardware instruction sequences that already contain key information such as the initialization parameters and test mode configuration of the panel under test. The driver module directly parses and executes the instructions in this sequence, thus standardizing the signal output and feedback acquisition process. Since the generation of the hardware instruction sequences is adapted to different panel types through a parsing library, the driver module can adapt to multiple panel types without modifying the underlying firmware, forming a complete standardized mechanism for driver layer operations.

[0084] A specific example is provided in conjunction with the above embodiments.

[0085] This example edits different DLLs in the processing layer (i.e., the processing module) to adapt to different screen modules. Each DLL encapsulates the instruction processing logic of a specific module (such as parameter conversion and instruction sequence generation), so that the application layer (i.e., the application module) can call the corresponding DLL through the module category index (i.e., the module information). There is no need to modify the driver layer (i.e., the driver module). The processing layer is located in the host computer. Changing the module only requires editing the required process for screen clicking in the DLL in the host computer.

[0086] By simply editing relevant instructions in the host computer (processing layer), different modules can be tested without changing the driver layer firmware. This reduces the need for frequent firmware updates and improves adaptability. Both the application layer and the processing layer reside in the host computer. The application layer is developed based on a graphical user interface (GUI) and accepts user input instructions (such as selecting module type and test parameters, i.e., module information and test-related parameters). The processing layer runs as a service on the computer and contains multiple DLL files (e.g., DLL_A.dll corresponds to module A, DLL_B.dll corresponds to module B); the driver layer firmware is burned into the microcontroller of the screen testing device (screen testing equipment).

[0087] The user selects module A through the application layer and issues a screen test command; the application layer identifies the module type and calls DLL_A.dll in the processing layer; DLL_A.dll parses the command and generates a hardware command sequence adapted to module A (such as initialization parameters and test mode); the processing layer issues the command to the driver layer through the API; the driver layer performs standard operations (such as signal output and feedback acquisition) to complete the screen test without firmware modification.

[0088] The effect is reflected in rapid adaptation: when adding a new module C, the user only needs to edit the new DLL_C.dll in the processing layer, and the test can start it without any changes to the driver layer.

[0089] This application also provides a dot-screen system, such as... Figure 2As shown, the screen dotting system includes: a host computer 11 and a screen dotting test device 12, wherein the host computer 11 includes: an application module 100 and a processing module 200, and the screen dotting test device 12 includes a driver module 300, wherein the application module is used to acquire module information and test-related parameters of the panel under test; The processing module is used to select a corresponding target parsing library from at least one candidate parsing library according to the module information, and use the target parsing library to parse the test association parameters to obtain a hardware instruction sequence; The driving module is used to drive the panel under test using the hardware instruction sequence.

[0090] In one possible implementation, the host computer can be implemented by a device with interactive and computing capabilities, such as a computer.

[0091] In one possible implementation, the screen testing device can be implemented using both hardware and software.

[0092] The specific implementation methods of the application module, processing module, and driver module are as described in any of the above embodiments, and will not be repeated here.

[0093] This application also provides a host computer, such as... Figure 3 As shown, the host computer 11 includes: Application module 100 is used to obtain module information and test-related parameters of the panel under test; The processing module 200 is used to select a corresponding target parsing library from at least one candidate parsing library according to the module information, and use the target parsing library to parse the test-related parameters to obtain a hardware instruction sequence; the hardware instruction sequence is used to drive the panel under test by the driving module of the dot-screen testing device.

[0094] In one possible implementation, the host computer can be implemented by a device with interactive and computing capabilities, such as a computer.

[0095] The specific implementation methods of the application module and the processing module are as described in any of the above embodiments, and will not be repeated here.

[0096] This application also provides a screen dot test device, such as... Figure 4 As shown, the screen testing device 12 includes: The driving module 300 is used to drive the panel under test using a hardware instruction sequence; wherein the hardware instruction sequence is obtained by the application module of the host computer selecting the corresponding target parsing library from at least one candidate parsing library according to the module information, and using the target parsing library to parse the test-related parameters, wherein the module information and the test-related parameters are obtained by the application module of the host computer.

[0097] In one possible implementation, the screen testing device can be implemented using both hardware and software.

[0098] The specific implementation of the driver module is as described in any of the above embodiments, and will not be repeated here.

[0099] This application also provides a screen tapping method, such as... Figure 5 The screen tapping method includes: Step 501: Obtain the module information and test-related parameters of the panel under test; Step 502: Select the corresponding target parsing library from at least one candidate parsing library according to the module information, and use the target parsing library to parse the test association parameters to obtain the hardware instruction sequence; Step 503: Drive the panel under test using the hardware instruction sequence.

[0100] Here, the screen tapping method can be executed by the screen tapping system. Specifically, it can be executed by the application module, processing module, and driver module of the screen tapping system respectively. The specific implementation method is as described in any of the above embodiments, and will not be repeated here.

[0101] In some embodiments, obtaining the module information and test-related parameters of the panel under test includes: Obtain user commands from the user interface; The module information and the test-related parameters are determined based on user instructions.

[0102] In some embodiments, the hardware instruction sequence includes at least one of the following: The initialization parameters of the panel under test; Test mode configuration.

[0103] In some embodiments, the method further includes sending the hardware instruction sequence via an application programming interface.

[0104] In some embodiments, driving the panel under test using the hardware instruction sequence includes at least one of the following: Based on the hardware instruction sequence, a drive signal is output to the panel under test; The feedback signal of the panel under test is acquired based on the hardware instruction sequence.

[0105] The various embodiments or implementation methods described in this specification are presented in a progressive manner. Each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other.

[0106] In the description of this specification, references to "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0107] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A dot-screen system, characterized in that, The dot-screen system includes: The application module is used to obtain the module information of the panel under test and the test-related parameters of the panel under test as indicated by the user. The processing module is used to select a corresponding target parsing library from at least one candidate parsing library according to the module information, and use the target parsing library to parse the test association parameters to obtain a hardware instruction sequence; A driver module is used to drive the panel under test using the hardware instruction sequence.

2. The dot-screen system according to claim 1, characterized in that, The application module is specifically used for: Obtain user commands from the user interface; The module information and the test-related parameters are determined based on user instructions.

3. The dot-screen system according to claim 1, characterized in that, The test-related parameters include at least one of the following: Test mode parameters associated with the test type; Display debugging parameters associated with the display parameters of the panel under test; Quality criterion parameters associated with the test judgment threshold; Communication adaptation parameters associated with the communication between the dot-screen system and the panel under test.

4. The dot-screen system according to claim 1, characterized in that, The processing module is also used to read the module information of the panel under test and send the module information to the application module; The application module is specifically used to: receive the module information sent by the processing module.

5. The dot-screen system according to claim 4, characterized in that, The application module is also used for: Based on the target parsing library, the candidate test association parameters corresponding to the target parsing library are displayed to the user. Based on user instructions, determine the test association parameter selected by the user from the candidate test association parameters.

6. The dot-screen system according to claim 1, characterized in that, The processing module is also used to: verify the test-related parameters.

7. The dot-screen system according to claim 1, characterized in that, The hardware instruction sequence includes at least one of the following: The initialization parameters of the panel under test; Test mode configuration.

8. The dot-screen system according to claim 1, characterized in that, The processing module is also used to send the hardware instruction sequence to the driver module through an application programming interface.

9. The dot-screen system according to any one of claims 1 to 8, characterized in that, The driver module is specifically used for at least one of the following: Based on the hardware instruction sequence, a drive signal is output to the panel under test; The feedback signal of the panel under test is acquired based on the hardware instruction sequence.

10. A screen dot method, characterized in that, The screen tapping method includes: Obtain the module information of the panel under test and the test-related parameters of the panel under test as indicated by the user; Based on the module information, a corresponding target parsing library is selected from at least one candidate parsing library, and the target parsing library is used to parse the test-related parameters to obtain a hardware instruction sequence; The panel under test is driven using the aforementioned hardware instruction sequence.

11. A dot-screen system, characterized in that, The screen-pointing system includes a host computer and a screen-pointing test device. The host computer includes an application module and a processing module. The screen-pointing test device includes a driver module. The application module is used to obtain the module information of the panel under test and the test-related parameters of the panel under test as indicated by the user. The processing module is used to select a corresponding target parsing library from at least one candidate parsing library according to the module information, and use the target parsing library to parse the test association parameters to obtain a hardware instruction sequence; The driving module is used to drive the panel under test using the hardware instruction sequence.

12. A host computer, characterized in that, The host computer includes: The application module is used to obtain the module information of the panel under test and the test-related parameters of the panel under test as indicated by the user. The processing module is used to select a corresponding target parsing library from at least one candidate parsing library according to the module information, and use the target parsing library to parse the test-related parameters to obtain a hardware instruction sequence; the hardware instruction sequence is used to drive the panel under test by the driving module of the dot-screen testing device.

13. A screen dot test device, characterized in that, The screen testing device includes: A driver module is used to drive the panel under test using a hardware instruction sequence; wherein the hardware instruction sequence is obtained by the application module of the host computer selecting the corresponding target parsing library from at least one candidate parsing library according to the module information, and using the target parsing library to parse the test association parameters; wherein the module information and the test association parameters are obtained by the application module of the host computer, and the test association parameters are indicated by the user.

Images