Simulator, driving test method, electronic device and computer-readable storage medium

Abstract

An embodiment of the present application provides a simulator, a driving test method, an electronic device, and a computer-readable storage medium. The simulator includes a bus access adaptation module, a data algorithm matching module, and a state machine management module. The bus access adaptation module is used to receive bus access messages. The data algorithm matching module is used to initialize the driving model data of different devices and generate a register access decision tree corresponding to each device. The data algorithm matching module is further used to receive the bus access message after timing marking, convert it into an extraction message, and then transmit it to the register access decision tree for access model matching. The state machine management module is used to, when an access model is matched, perform a driving state machine judgment according to the access model and output corresponding test results. Without relying on real hardware devices, the simulator can simulate the hardware devices of different products by reading the driving model data, and then perform driving function tests.

Description

Technical Field

[0001] This application relates to the field of testing technologies, and in particular, to a simulator, a driving test method, an electronic device, and a computer-readable storage medium. Background Art

[0002] Currently, when performing driving tests on electronic devices such as mobile phones, it is common to directly connect to real devices or perform automated tests on the device driving interface. However, in the Linux kernel-mode driver, it is impossible to dynamically obtain the access timing of real driver registers. Driving tests need to write test programs in the kernel driver architecture or perform tests based on the functional performance of the devices. When it is found that there is an error in the driver program, especially when the register value is written incorrectly, after modifying the kernel driver, the entire driver program and test program need to be recompiled. The driving test method is inefficient and relies on real hardware devices, which is relatively complex. Summary of the Invention

[0003] Embodiments of this application provide a simulator, a driving test method, an electronic device, and a computer-readable storage medium. By setting a simulator based on the register access timing, the simulator supports the extraction and model matching of the access timing of the user-mode driver to the bus, and can be pushed to a mobile phone or other device terminals, without the need for host control and can run independently. The simulator can also support driving function tests without relying on real hardware devices.

[0004] In a first aspect, the present application provides a simulator, which includes: a bus access adaptation module for receiving a bus access message and performing timing marking on the received bus access message, where the bus access message includes register access configuration parameters corresponding to a driving function; a data algorithm matching module connected to the bus access adaptation module for initializing driving model data of different devices and generating a register access decision tree corresponding to each device. The data algorithm matching module is further configured to receive the bus access message after timing marking, convert the bus access message into an extraction message, and transmit the extraction message to the register access decision tree for access model matching; a state machine management module connected to the data algorithm matching module for receiving the access model when the data algorithm matching module matches an access model, and performing a driving state machine judgment based on the access model to determine whether the access model is an access model that conforms to the current state, and outputting a corresponding test result according to the determination result. By setting a simulator based on register access timing, the simulator of the present application supports user-state driving access bus timing extraction and model matching, can be pushed to a mobile phone or other device terminals, and can run independently without host control. The simulator can also simulate devices such as a display screen (LCD), a touch screen (TP), and audio (Audio) of different products through driving model data reading without relying on a real hardware device, and then perform driving function testing.

[0005] In a possible design, the bus access adaptation module includes a bus access adaptation unit and a timing marking unit. The bus access adaptation unit is configured to receive the bus access message and bridge the bus access message to the timing marking unit. The timing marking unit is connected to the bus access adaptation unit for receiving the bus access message from the bus access adaptation unit and adding timing marking to the bus access message. Obviously, in this design, by setting the bus access adaptation unit and the timing marking unit, the bus access message can be effectively bridged through user-state bus access, the bus message interface can be hooked, and the corresponding driving function can be effectively tested without modifying the code under test.

[0006] In a possible design, the data algorithm matching module includes an initialization unit and an algorithm matching unit. The initialization unit is used to initialize the drive model data of different devices and generate a register access decision tree corresponding to each device. The algorithm matching unit is connected to the initialization unit and is used to, when the bus access adaptation module receives the bus access message, extract the information of the bus access message to generate an extraction message and send it to a message queue, control the dequeue of the extraction message in the message queue, and sequentially compare and match the dequeued extraction message with the register access decision tree to confirm whether there is an access model corresponding to the extraction message. Obviously, in this design, the simulator can combine a set of bus access messages with complete functions with the drive data model, and then judge whether the access content and timing of a set of instructions are correct through an algorithm (such as through the algorithm matching module), that is, perform access model matching.

[0007] In a possible design, the algorithm matching unit also adaptively adjusts the matching algorithm granularity according to the message dequeue quantity and the matching result. Obviously, in this design, the simulator can effectively adjust the granularity of the matching algorithm to support the matching of the access model, save matching resources and improve the matching efficiency.

[0008] In a possible design, the register access decision tree includes a register root node, register decision nodes, and access models. The register root node corresponds to one or more register decision nodes, and each register decision node corresponds to an access model and / or one or more register decision nodes. The register root node, several register decision nodes, and several access models together form a tree structure to form the register access decision tree. Obviously, in this design, the simulator can form a specific register access decision tree to match the operation model (i.e., the access model) based on a preset algorithm, and thus can effectively test the corresponding drive function without relying on real hardware devices.

[0009] In a possible design, the state machine management module includes a state machine management unit and a message interaction unit. The state machine management unit is connected to the data algorithm matching module and is used to, when receiving the access model, perform state machine judgment according to the received access model and output the test result through the message interaction unit. Obviously, in this design, the simulator can implement state machine management to judge unreasonable function settings and provide fault warning information to the drive layer.

[0010] In a possible design, the state machine management unit is further configured to, when receiving an access model, refresh the current state and the register model database according to the data of the access model, and transmit the refreshed register model data to the data algorithm matching module, and the data algorithm matching module initializes by using the refreshed register model data to establish the register access decision tree. Obviously, in this design, the simulator can implement state machine management to judge unreasonable function settings and provide fault warning information to the driver layer.

[0011] In a second aspect, the present application provides a driver test method, and the driver test method includes: initializing the driver model data of different devices and generating a register access decision tree corresponding to each device; receiving a bus access message and performing timing marking on the received bus access message, where the bus access message includes register access configuration parameters corresponding to the driver function; receiving the bus access message after timing marking, converting the bus access message into an extraction message, and transmitting the extraction message to the register access decision tree for access model matching; when an access model is matched, performing a driver state machine judgment according to the access model to determine whether the access model is an access model that conforms to the current state, and outputting a corresponding test result according to the determination result.

[0012] In a possible design, the receiving the bus access message after timing marking, converting the bus access message into an extraction message, and transmitting the extraction message to the register access decision tree for access model matching includes: receiving the bus access message, extracting the information of the bus access message to generate an extraction message and sending it to a message queue; controlling the dequeue of the extraction message in the message queue; sequentially comparing and matching the dequeued extraction message with the register access decision tree to confirm whether there is an access model corresponding to the extraction message.

[0013] In a possible design, the driver test method further includes: adaptively adjusting the matching algorithm granularity according to the message dequeue quantity and the matching result.

[0014] In a possible design, the register access decision tree includes a register root node, register decision nodes, and access models. The register root node corresponds to one or more register decision nodes, and each register decision node corresponds to an access model and / or one or more register decision nodes. The register root node, several register decision nodes, and several access models together form a tree structure to form the register access decision tree.

[0015] In a possible design, the drive test method further includes: when receiving an access model, refreshing the current state and the register model database according to the data of the access model; initializing the refreshed register model data, and then establishing a corresponding register access decision tree.

[0016] In a possible design, the drive test method further includes: opening one of the applications in the application layer, where the application accesses hardware resources; performing drive function settings according to the called hardware resources; converting the data of the drive function settings into corresponding register access configuration parameters, and transmitting them in the form of the bus access message.

[0017] In a third aspect, the present application provides an electronic device, including an operating system, where the operating system includes an application layer, an application framework layer, a hardware abstraction layer, a kernel layer, and the simulator, and the simulator is disposed in the hardware abstraction layer.

[0018] In a fourth aspect, the present application provides an electronic device, including a processor and a memory; the memory is used for storing instructions; the processor is used for calling the instructions in the memory, so that the electronic device executes the drive test method.

[0019] In a fifth aspect, the present application provides a computer-readable storage medium, where the computer-readable storage medium stores at least one instruction, and when the at least one instruction is executed by a processor, the drive test method is implemented.

[0020] For the technical effects brought by the second aspect to the fifth aspect, reference can be made to the descriptions related to the methods in the above method part, which will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the descriptions in the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0022] Figure 1a and Figure 1b is a schematic diagram of the operating environment and an interaction diagram of an existing drive test method;

[0023] Figure 1c is a schematic flowchart of another existing drive test method;

[0024] Figure 2 is a schematic diagram of the software framework of an electronic device provided by an embodiment of the present application;

[0025] Figure 3 Function block diagram of an emulator provided by an embodiment of the present application;

[0026] Figure 4 Schematic diagram of a register access decision tree generated by an emulator provided by an embodiment of the present application;

[0027] Figure 5 Schematic diagram of the working principle of a data algorithm matching module and a state machine management module in an emulator provided by an embodiment of the present application;

[0028] Figure 6 Schematic diagram of the flow of a drive test method provided by an embodiment of the present application;

[0029] Figure 7 Schematic diagram of the emulator provided by an embodiment of the present application applied to the first scenario;

[0030] Figure 8 Schematic diagram of the emulator provided by an embodiment of the present application applied to the second scenario;

[0031] Figure 9 Schematic diagram of an electronic device provided by an embodiment of the present application.

[0032] Description of main component symbols

[0033] Operating system 200, emulator 300, bus access adaptation module 31

[0034] Bus access adaptation unit 311, timing marking unit 313, data algorithm matching module 33

[0035] Initialization unit 331, algorithm matching unit 333, message queue 335

[0036] State machine management module 35, state machine management unit 351, message interaction unit 353

[0037] Register access decision trees 400, 400a, register root nodes 41, 0, register decision nodes 42, 1 - 9

[0038] Access models 43, 1 - 5

[0039] The following specific embodiments will further illustrate the present application in conjunction with the above - mentioned drawings. Specific embodiments

[0040] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the following will clearly and completely describe the technical solutions in the embodiments of this application with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are some, but not all, of the embodiments of this application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of this application without creative efforts shall fall within the scope of protection of this application.

[0041] It should be noted that in the embodiments of this application, "at least one" means one or more, and "a plurality" means two or more. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the technical field to which this application belongs.

[0042] The terms used in the description of this application are only for the purpose of describing specific embodiments and are not intended to limit this application. It should be understood that unless otherwise specified in this application, " / " means "or". For example, A / B can represent A or B. "A and / or B" in this application is only a description of the association relationship between associated objects, indicating that there can be three relationships: only A exists, only B exists, and both A and B exist.

[0043] It should be noted that in the embodiments of this application, terms such as "first" and "second" are only used for the purpose of distinguishing descriptions and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying order. Features defined with "first" and "second" may explicitly or implicitly include one or more of the described features. In the description of the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner.

[0044] It can be understood that please refer to Figure 1a , Figure 1a is a schematic diagram of the first common drive test method currently. When drive testing is required, first connect to a real device, such as directly connecting to the camera, display screen, sensor and other hardware devices of the device under test (mobile phone, PC, in-vehicle computer, etc.). Then, call a test framework for testing by simulating the functions of the Hardware Abstraction Layer (HAL) interface definition language (HAL interface definition language, HIDL) interface, and the test results depend on the state and data feedback of the real device.

[0045] For example, please refer to Figure 1b , which is one of the interaction diagrams of the first driving test method. Among them, in the first driving test method, the test binary, that is, the test framework, is first pushed into the device under test, and its input control is implemented through the simulation interface call. The observation point needs to rely on the response result of the real device. Obviously, the first driving test method requires connecting to real devices (such as the sensor shown in the figure). However, in the future, in the form of multiple products and multiple devices, a large number of real device environments are required to support the massive test cases of the system, and the resources are limited.

[0046] Please also refer to Figure 1c , which is a schematic flowchart of the second common driving test method at present. The second test method mainly includes the following steps: activating the driving device node; applying for physical memory space in the Linux system kernel and recording it as the buffer space; mapping the buffer space to the user space and recording it as the mapped space; assigning the initialization value of the peripheral controller to the mapped space; flushing the value in the mapped space to the peripheral controller; starting the peripheral controller, and according to the preset test requirements, dynamically modifying the data in the mapped space in a loop to view the driving test result. Obviously, in the above second test method, for single instruction processing, data mapping requires a conversion from the kernel state to the user state. In addition, the second test method also requires preset test requirements and can only compare whether a single instruction is set correctly. If there are problems with the timing of multiple instruction configurations, the driving test cannot be supported.

[0047] In view of the above problems, the embodiments of the present application provide a simulator, a driving test method, an electronic device, and a computer-readable storage medium. By setting a simulator based on the register access timing, the simulator supports the extraction and model matching of the user-state driver access bus timing, can be pushed to the mobile phone or other device terminals, and can run independently without the control of the host (HOST). The simulator can also support the driving function test without relying on real hardware devices.

[0048] It can be understood that the simulator provided by the embodiments of the present application is set in the electronic device. The electronic device can be, but is not limited to, different types of electronic devices such as a computer, a mobile phone, a tablet, a vehicle-mounted computer, a smart bracelet, and a smart watch. The electronic device can include, but is not limited to, components such as a processor, an external memory interface, an internal memory, a universal serial bus (USB) interface, a charging management module, a power management module, and a battery.

[0049] Please also refer to Figure 2 , Figure 2This is a software architecture block diagram of the electronic device in the embodiments of the present application. It can be understood that the electronic device involved in the embodiments of the present application includes, in addition to the components described above, an operating system 200 and a simulator 300. The operating system 200 can be, but is not limited to, a Linux system, an Android system, an IOS operating system, a Symbian operating system, a Black Berry operating system, a Windows Phone 8 operating system, and so on. It can be understood that in the embodiments of the present application, the Android system is taken as an example for illustration.

[0050] The operating system 200 is divided into several layers using a layered architecture, and each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In the embodiments of the present application, the operating system 200 is at least divided into four layers, from top to bottom, namely the application layer (Applications), the application framework layer (Application framework), the hardware abstraction layer (hardware abstraction layer, HAL), and the kernel layer.

[0051] Among them, the application layer is mainly used for the installation of applications, such as the system's built-in contact, SMS and other programs, or third-party application programs. The application programs can include, but are not limited to, the vehicle body launcher, the in-vehicle system UI, 360-degree surround view, vehicle control, audio and video, or other application programs (such as the camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message, etc.).

[0052] The application framework layer is mainly used to provide application programming interfaces (application programming interface, API) and programming frameworks for the application programs in the application layer. The application framework layer includes some predefined functions. The application program framework layer can include, but is not limited to, the window manager, the content provider, the view system, the telephone manager, the resource manager, the notification manager, etc.

[0053] The hardware abstraction layer is a set of interface standards defined by Android to provide interface support for the application framework layer.

[0054] The kernel layer is the layer between the hardware and the software. The kernel layer is used to enable various hardware of the electronic device, such as the image signal processor (ISP) and the front-end image sensor (sensors), to provide low-level drivers for various hardware, such as the display (Display) driver, the audio (Audio) driver, the camera (Camera) driver, the Bluetooth driver, the Wi-Fi driver, the sensor (Sensor) driver, etc.

[0055] It can be understood that the simulator 300 is provided in the hardware abstraction layer (HAL). The simulator 300 includes a bus access adaptation module 31, a data algorithm matching module 33, and a state machine management module 35.

[0056] Please refer to Figure 3 , the bus access adaptation module 31 includes a bus access adaptation unit 311 and a timing marking unit 313. The bus access adaptation unit 311 is connected to the user-mode bus of the hardware abstraction layer (see Figure 2 ) for receiving bus access messages and bridging or transmitting the bus access messages to the timing marking unit 313.

[0057] In the embodiment of the present application, the bus access message includes register access configuration parameters corresponding to the drive function. For example, when it is necessary to call the corresponding driver (such as an audio driver) to implement the corresponding function (such as playing music), logical processing needs to be performed first, such as processing the audio path configuration and selecting the interface of the audio device. Then, the corresponding hardware resources (such as the interface of the audio device) need to be called through the HIDL interface. Next, the called hardware resources are driven and processed and converted into register access configuration parameters. In this way, the converted register access configuration parameters are bridged (or transmitted) to the timing marking unit 313 in the form of the bus access message.

[0058] The timing marking unit 313 is connected to the bus access adaptation unit 311. The timing marking unit 313 is used to receive the bus access message from the bus access adaptation unit 311 and add timing marks to the bus access message.

[0059] The data algorithm matching module 33 is connected to the bus access adaptation module 31. The data algorithm matching module 33 is used to initialize the drive model data of each hardware device and generate a register access decision tree corresponding to each device. The data algorithm matching module 33 is also used to receive the data transmitted by the bus access adaptation module 31, such as the bus access message, and compare and match the bus access message with the data of the register access decision tree, that is, perform model data algorithm matching. Among them, the data algorithm matching module 33 includes an initialization unit 331 and an algorithm matching unit 333.

[0060] The initialization unit 331 is used to initialize the drive model data of different devices and generate a register access decision tree corresponding to each device. In the embodiments of the present application, the electronic device may correspond to different hardware devices, such as a camera, a sensor, a Bluetooth module, a WIFI module, a display screen, etc. Each hardware device corresponds to different drive model data. For example, for a camera, there is corresponding camera drive model data. For a display screen, there is corresponding display screen drive model data. Thus, the initialization unit 331 can generate different register access decision trees for different drive model data.

[0061] Please refer to Figure 4 for a schematic diagram of a register access decision tree 400 provided by the embodiments of the present application. Among them, the register access decision tree 400 includes a register root node 41, register decision nodes 42, and an access model 43. The register root node 41 generally corresponds to the type or model of a hardware device. The register root node 41 corresponds to one or more register decision nodes 42. Each register decision node 42 corresponds to an access model 43 and / or one or more register decision nodes 42. The register root node 41, several register decision nodes 42, and several access models 43 together form a tree structure to form the register access decision tree 400.

[0062] It can be understood that after importing the initialization data of each hardware device, the initialization unit 331 can automatically model according to the initialization data, and then generate a register access decision tree 400 corresponding to the hardware device. In the embodiments of the application, the register root node 41 and the register decision nodes 42 respectively correspond to a piece of program code. For example, please refer to Figure 5 , Figure 5 for a schematic diagram of generating a corresponding register access decision tree 400a using an initialization data. In one of the embodiments, assume that the initialization data of the hardware device is:

[0063] <SCENCE NAME="POWER_ON_L"CONTROL_MASK="0x1"VALUE="{

[0064] #set gain to 17dB#

[0065] 0x61, 0x03c0, 0x0100, 0x00, 0x00,

[0066] 0x00, 0x0008, 0x0008, 0x00, 0x00,

[0067] 0x00, 0x0010, 0x0010, 0x00, 0x00,

[0068] 0x00, 0x0001, 0x0000, 0x00, 0x00,

[0069] 0x00, 0x0014, 0x0014, 0x00, 0x00,

[0070] #enable interrupts#

[0071] 0x48, 0xffff, 0x0000, 0x00, 0x00}" / >

[0072] <SCENCE NAME="POWER_OFF_L"CONTROL_MASK="0x1"VALUE="{

[0073] #disable all interrupt first#

[0074] 0x48, 0xffff, 0x0000, 0x00, 0x00,

[0075] 0x00, 0x0008, 0x0000, 0x00, 0x00,

[0076] 0x00, 0x0010, 0x0000, 0x00, 0x00,

[0077] 0x00, 0x0001, 0x0001, 0x00, 0x00,

[0078] 0x00, 0x0014, 0x0000, 0x00, 0x00}" / >

[0079] Then, the initialization unit 331 first correspondingly sets the program code 0 (0x61, 0x03c0, 0x0100, 0x00, 0x00) as the register root node 0. Then, the initialization unit 331 sequentially sets the code of the "POWER_ON_L" instruction, i.e., program code 1 (0x00, 0x0008, 0x0008, 0x00, 0x00), program code 2 (0x00, 0x0010, 0x0010, 0x00, 0x00), program code 3 (0x00, 0x0001, 0x0000, 0x00, 0x00), and program code 4 (0x00, 0x0014, 0x0014, 0x00, 0x00) as register decision nodes 1, 2, 3, and 4 respectively. The initialization unit 331 then sets the program code 5 (0x48, 0xffff, 0x0000, 0x00, 0x00), program code 6 (0x00, 0x0008, 0x0000, 0x00, 0x00), program code 7 (0x00, 0x0010, 0x0000, 0x00, 0x00), program code 8 (0x00, 0x0001, 0x0001, 0x00, 0x00), and program code 9 (0x00, 0x0014, 0x0000, 0x00, 0x00) corresponding to the "POWER_OFF_L" instruction as register decision nodes 5, 6, 7, 8, and 9 respectively.

[0080] In addition, as described above, each register decision node corresponds to an access model and / or one or more register decision nodes. For example, register decision node 2 corresponds to access model 0 (such as mute), register decision node 3 corresponds to access model 1 (such as play), register decision node 4 corresponds to access model 2 (such as power on), register decision node 6 corresponds to access model 3, register decision node 8 corresponds to access model 4, and register decision node 9 corresponds to access model 5 (such as power off).

[0081] Obviously, the initialization unit 331 can generate a register access decision tree corresponding to each device according to the initialization data of different devices.

[0082] Please refer to again Figure 3, the algorithm matching unit 333 is connected to the initialization unit 331. When the bus access adaptation module 31 receives a register access message through the user-mode bus, the algorithm matching unit 333 is used to extract information such as the device address, register address, timing, parameters, type, etc. of the bus access message, and form the extracted information into extraction messages msg1, msg2, msg3... msgN and send them to a message queue 335. The algorithm matching unit 333 then controls the dequeue of the extraction messages in the message queue 335 based on the timing interval and the number of messages, and sequentially compares and matches the dequeued extraction messages with the information of the root node 0 and decision nodes 1-9 corresponding to the register access decision tree 400a generated by the initialization unit 331, so as to confirm whether there is an access model corresponding to the extraction message.

[0083] It can be understood that when the algorithm matching unit 333 confirms or finds an access model corresponding to the extraction message, it further transmits the matched access model to the state machine management module 35.

[0084] It can be understood that in the embodiment of the present application, the algorithm matching unit 333 can also adaptively adjust or control the granularity of its matching algorithm according to the number of message dequeues and its access model matching results. For example, in one embodiment, assume that the algorithm matching unit 333 receives 20 bus access messages at a time, and controls the dequeue of 5 extraction messages each time for access model matching. When the algorithm matching unit 333 finds that the 5 extraction messages are not sufficient to match the corresponding access model after matching, the algorithm matching unit 333 can adjust the granularity of the matching algorithm, such as increasing the number of dequeued extraction messages. For example, it can control the dequeue of 8 or 10 extraction messages in sequence to support the matching of the access model. Again, in another embodiment, assume that the algorithm matching unit 333 receives 20 access messages at a time, and controls the dequeue of 10 extraction messages each time. When the algorithm matching unit 333 finds that only 5 extraction messages are needed to match the corresponding access model, the algorithm matching unit 333 can adjust the granularity of the matching algorithm, such as reducing the number of dequeued extraction messages, to support the matching of the access model and save matching resources and improve matching efficiency.

[0085] The state machine management module 35 is used to simulate the processing of the device driver state machine, update the register data, and provide register configurations and response capabilities in different states. The state machine management module 35 includes a state machine management unit 351 and a message interaction unit 353. Among them, the state machine management unit 351 is connected to the data algorithm matching module 33. When the state machine management unit 351 receives one or more access models, it indicates that the algorithm matching unit 333 finally finds the access model corresponding to the extraction message. At this time, the state machine management unit 351 makes a state machine judgment according to the received access model.

[0086] The state machine management unit 351 may include multiple driver state machines. For example, the state machine management unit 351 includes, but is not limited to, a display screen (LCD) state machine, a touch screen (TP) state machine, an audio state machine, and / or other state machines. The state machine management unit 351 determines that the access model is an access model that conforms to the current state. For example, if the current state is the display screen (LCD) state machine and the state machine management unit 351 receives an access model related to the display screen, then the state machine management unit 351 determines that the access model is an access model that conforms to the current state. Another example is that when the state machine management unit 351 continuously receives two identical instructions, such as a power-on instruction (i.e., the data of two consecutive access models is the same), the state machine management unit 351 can make a state machine judgment and determine that it is an access model that does not conform to the current state, and then return an error result through the message interaction unit 353, such as returning an error code.

[0087] It can be understood that the state machine management unit 351 is also used to refresh the current state and the register model database according to the data of the access model when receiving the access model.

[0088] It can be understood that in the embodiment of the present application, the state machine management unit 351 is also used to transmit the refreshed register model data to the initialization unit 331 at the same time, so that the initialization unit 331 can use the refreshed register model data for initialization to establish or update the corresponding register access decision tree.

[0089] It can be understood that in the embodiment of the present application, when the message interaction unit 353 receives the error result, it can also output the error result through the bus access adaptation unit 311 and the user state bus.

[0090] The working principle of the simulator 300 is introduced in detail below.

[0091] First, in the embodiments of the present application, the simulator 300 first imports the initialization data (i.e., drive model data) of each device, and initializes the drive model data of different devices by using the initialization unit 331 to generate a register access decision tree corresponding to each device. Then, the simulator 300 realizes register access adaptation through the bus access adaptation module 31 to obtain a plurality of bus access messages, and performs timing marking on the plurality of bus access messages. The data algorithm matching module 33 then extracts information such as the device address, register address, timing, parameters, type, etc. of the bus access message to generate corresponding extraction information, and sends the extraction message to the message queue 335. Among them, in the embodiments of the present application, the data algorithm matching module 33 can control the dequeue of the extraction messages in the message queue based on the timing interval and the number of messages. Next, the data algorithm matching module 33 compares and matches the dequeued extraction messages with the data of the above-generated register access decision tree, and then confirms whether there is an access model corresponding to the extraction message. When there is an access model corresponding to the extraction message, the data algorithm matching module 33 sends the access model to the state machine management module 35. The state machine management module 35 then performs state machine judgment according to the matching result of the data algorithm matching module 33, updates the register data, and provides operations such as register configuration and response capabilities in different states.

[0092] For example, please refer to again Figure 5 , in one of the embodiments, first import the initialization data (i.e., drive model data) of each device, and use the initialization unit 331 to initialize the drive model data of different devices to generate a register access decision tree corresponding to each device (S50). Then, assume that the algorithm matching unit 333 receives four register access messages, such as bus access message 1, bus access message 2, bus access message 3, and bus access message 4. The structure of the bus access message is as Figure 5 shown, for example, including device address, mask, register address, timing, type, etc.

[0093] The algorithm matching unit 333 sequentially extracts information such as the device address, register address, timing, parameters, and type of each bus access message to generate corresponding extracted information msg1, msg2, msg3, and msg4, and then sends the extracted information msg1, msg2, msg3, and msg4 to the message queue 335 (S51). Next, the algorithm matching unit 333 further controls the dequeue of the extracted messages in the message queue 335 based on the timing interval and the number of messages, and sequentially compares and matches the dequeued extracted messages with the information of the register root node 0 and decision nodes 1-9 corresponding to the register access decision tree 400a generated by the initialization unit 331, so as to confirm whether there is an access model corresponding to the extracted message (S52).

[0094] As Figure 5 shown, assume that the algorithm matching unit 333 finds an access model 2 corresponding to the extracted message, and the access model 2 is a power-on operation. Then the algorithm matching unit 333 further transmits the matched access model 2 to the state machine management module 35 (S53). When the state machine management unit 351 in the state machine management module 35 determines that the access model 2 is an access model that conforms to the current state, the state machine management unit 351 refreshes the current state and the register model database according to the data of the access model 2, and at the same time returns a result through the message interaction unit 353, such as returning success, to indicate that the register driver configuration is successful. In addition, the state machine management unit 351 also transmits the refreshed register model data to the initialization unit 331 at the same time, so that the initialization unit 331 can use the refreshed register model data for initialization to establish a corresponding register access decision tree (S54). Of course, the algorithm matching unit 333 can also adaptively adjust or control the matching algorithm granularity according to the dequeue number of the extracted messages and their matching results (S55).

[0095] Please refer to Figure 6 , which is a flowchart of a method for performing a driver test using the simulator provided by an embodiment of the present application. Specifically, the driver test method includes:

[0096] S60, open one of the APKs (Android Package, Android installation package, that is, an application) in the application layer, and the application accesses the hardware resources.

[0097] It can be understood that when opening the corresponding APK, it is usually necessary to call the corresponding hardware resources according to the corresponding APK file. For example, when playing music is required, it is usually necessary to perform audio path configuration and select the interface of the audio device, etc.

[0098] S61, perform driver function settings according to the called hardware resources.

[0099] In the embodiment of the present application, the hardware abstraction layer performs driver processing on the data called by the HIDL interface (such as the data of hardware resources). For example, when camera driver settings are required, the driver function settings include, but are not limited to, sending down parameters such as sensor configuration, main type, format, resolution, frame rate, etc.

[0100] S62, Convert the data of the driver function settings into corresponding register access configuration parameters, and bridge them to the simulator 300 in the form of a bus access message.

[0101] It can be understood that in the embodiment of the present application, the hardware abstraction layer bridges the bus access message to the simulator 300 through the user-mode bus.

[0102] S63, The simulator 300 receives the bus access message through the bus access adaptation unit 311, adds timing marks to the bus access message through the timing marking unit 313, and then transmits the marked bus access message to the data algorithm matching module 33.

[0103] S64, The data algorithm matching module 33 receives the marked bus access message through the algorithm matching unit 333, and converts the bus access message into an extraction message.

[0104] S65, The algorithm matching module 33 matches the extraction message with the information of the root node and decision nodes corresponding to the register access decision tree generated by the initialization unit 331 through the algorithm matching unit 333, so as to confirm whether there is a matching model corresponding to the extraction message. When it is confirmed that a corresponding access model is matched, step S66 is executed. When it is confirmed that no corresponding access model is matched, return to step S63 to continue receiving bus access messages.

[0105] It can be understood that the structures, functions, mutual relationships of the initialization unit 331 and the algorithm matching unit 333 in the algorithm matching module 33, and the principle (i.e., the algorithm model) of using the initialization unit 331 and the algorithm matching unit 333 to match the extraction message with the information of the root node and decision nodes corresponding to the generated register access decision tree are as described above (for example, refer to Figure 4 and / or Figure 5 as shown), and will not be elaborated here.

[0106] S66. The algorithm matching unit 333 transfers the matched access model to the state machine management module 35. S67. The state machine management module 35 receives the access model through the state machine management unit 351, and refreshes the current state and the register model database (such as the register list) according to the data of the access model.

[0107] S68. The state machine management module 35 makes a state machine judgment through the state machine management unit 351 to determine whether the access model is an access model that conforms to the current state, that is, to confirm whether its access state is correct. When it is determined that the access model is an access model that conforms to the current state, step S69 is executed. When it is determined that the access model does not conform to the current state, step S610 is executed.

[0108] S69. The state machine management module 35 returns a status through the message interaction unit 353, such as returning success.

[0109] S610. The state machine management module 35 returns an error result through the message interaction unit 353, such as returning an error code.

[0110] Obviously, the simulator 300 extracts the drive model data of each device to generate a corresponding register access decision tree. At the same time, the simulator 300 can extract the accessed register address, assignment, and timing marking, and match the operation model (i.e., the access model) based on a preset algorithm, thereby effectively testing its corresponding drive function. The algorithm timing control point or granularity of the preset algorithm can be self-learned and adjusted. The simulator 300 is also provided with a state machine management module 35, and the state machine management module 35 can judge whether the access models of different devices match the current state of the current device and refresh the register data. In addition, the simulator 300 can also access the bridge access message through the user-mode bus, hook the bus message interface, without modifying the code under test. Furthermore, for operations that conform to the device state, the register address, configuration value, timing are matched with the preset correct timing model, and the result is returned.

[0111] Please refer to Figure 7 , which is a schematic diagram of the simulator provided by the embodiment of the present application applied to the first scenario.

[0112] In the first scenario, taking the need to play music and using the simulator to simulate the drive function of a smart PA as an example for illustration.

[0113] First, music playback is applied (S70). Next, the system service performs logical processing, such as audio path configuration (S71). Then the hardware abstraction layer calls hardware resources through the HIDL interface (S72). An audio driver module is then used to drive the hardware resources called by the HIDL interface and convert them into register access configuration parameters, that is, convert them into the bus access messages described above (S73). Next, the simulator simulates the register playback music configuration of the smart PA, matches the timing, and determines whether the register access for music playback is correct (S74). When the simulator determines that the drive configuration is sent correctly, it can return a corresponding result (such as returning success) to the audio driver module (S75). The audio driver module then switches the path and feeds back to the system service (S76). The system service then determines that the path switch is successful, and thus music can be played normally (S77).

[0114] In the first scenario, due to the setting of the simulator, the electronic device can achieve audio drive call without the response of a real smart PA device. That is to say, the drive function settings, such as music playback, and the register control of the device can be obtained through the algorithm matching of the simulator. The simulator can also determine whether the current device state allows the operation of playing music, that is, perform the state machine judgment. When it is determined that it can be performed, the register configuration and device state can be refreshed, and the drive function configuration result can be returned.

[0115] That is to say, in the first scenario, through the setting of the simulator, the interception of bus access messages can be performed without modifying the development code. Furthermore, the simulator can combine a set of bus access messages with complete functions with the drive data model, and then determine whether the access content and timing of a set of instructions are correct (that is, perform access model matching) through an algorithm (such as through the algorithm matching module 33 described above). Finally, the simulator realizes state machine management (such as through the state machine management module 35 described above) to judge unreasonable function settings and provide fault warning information to the drive layer.

[0116] Please refer to Figure 8 for the schematic diagram of the simulator provided by the embodiment of the present application applied in the second scenario.

[0117] In the second scenario, the simulator is set in the hardware abstraction layer of the operating system. The operating system also includes an application layer, an application framework layer, a system layer, and a kernel layer. Descriptions of each layer in the operating system and the structure and working principle of the simulator can be referred to Figure 2 , Figure 4 and / or Figure 5 for the description, which will not be elaborated here.

[0118] In the second scenario, when it is necessary to test one of the driving functions of the device under test (such as the camera driving function), the simulator can be used for simulation and configuration first (i.e., simulating the register configuration and access timing of the camera, etc.). Then, set the corresponding test framework, and directly call the test framework through the HIDL interface in the device under test to test the driving function. After the test, the corresponding test results and test logs are returned through the test framework.

[0119] It can be understood that in the embodiments of the present application, the test framework is not limited. The test framework can be set in a test device, such as a host, or pushed to the device under test.

[0120] It can be understood that in the embodiments of the present application, a test report can also be generated according to the test results and the test logs.

[0121] It can be understood that in the second scenario, by setting the simulator, without connecting a real hardware device, the simulator can be implemented by simulating the bus access timing call and algorithm matching response of the software simulation bus adaptation layer, and the underlying hardware device can be shielded from the system. Furthermore, through the drive model data reading in the simulator, devices such as the display screen (LCD), touch screen (TP), and audio (Audio) of different products can be simulated, and then the driving function test can be carried out.

[0122] That is to say, in the embodiments of the present application, the simulator and its driving test method have at least the following beneficial effects:

[0123] (1) The interception of bus access messages can be carried out without modifying the development code.

[0124] (2) A set of bus access messages with complete functions can be combined with the drive data model, and then it can be judged whether the access content and timing of a set of instructions are correct through an algorithm.

[0125] (3) Through state machine management, unreasonable function settings can be judged, and fault warning information can be provided to the drive layer.

[0126] As Figure 9 shown, it is a schematic diagram of an electronic device 90 provided by an embodiment of the present application. The electronic device 90 includes a memory 901, a processor 902, and computer-readable instructions stored in the memory 901 and executable on the processor 902, such as a drive test program. When the processor 902 executes the computer-readable instructions, the steps in the above-mentioned embodiment of the drive test method are implemented.

[0127] Those skilled in the art can understand that the schematic Figure 9This is only an example of the electronic device 90, which does not constitute a limitation on the electronic device 90. It may include more or fewer components than those shown in the figure, or combine some components, or different components. For example, the electronic device 90 may also include input / output devices, network access devices, buses, etc.

[0128] The processor 902 may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or the processor 902 may also be any conventional processor, etc. The processor 902 is the control center of the electronic device 90, and connects various parts of the entire electronic device 90 using various interfaces and lines.

[0129] The memory 901 can be used to store the computer-readable instructions. The processor 902 realizes various functions of the electronic device 90 by running or executing the computer-readable instructions or modules stored in the memory 901, and by calling the data stored in the memory 901. The memory 901 may mainly include a program storage area and a data storage area. Among them, the program storage area may store an operating system, applications required for at least one function (such as a sound playback function, an image playback function, etc.); the data storage area may store data created according to the use of the electronic device 90. In addition, the memory 901 may include a hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one magnetic disk storage device, flash device, read-only memory (ROM), random access memory (RAM), or other non-volatile / volatile storage devices.

[0130] If the modules integrated in the electronic device 90 are implemented in the form of software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-described embodiment methods of the present invention, relevant hardware can also be instructed by computer-readable instructions. The computer-readable instructions can be stored in a computer-readable storage medium. When the computer-readable instructions are executed by a processor, the steps of the above-described method embodiments can be implemented. Among them, the computer-readable instructions include computer-readable instruction codes, and the computer-readable instruction codes can be in the form of source code, object code, executable files, or some intermediate forms, etc. The computer-readable medium can include: any entity or device capable of carrying the computer-readable instruction codes, recording media, USB flash drives, mobile hard disks, magnetic disks, optical disks, computer memories, read-only memories (ROMs), random access memories (RAMs), etc.

[0131] This embodiment also provides a computer-readable storage medium. Computer instructions are stored in the computer-readable storage medium. When the computer instructions run on an electronic device, the electronic device is caused to execute the above-related method steps to implement the drive function simulation method in the above embodiment.

[0132] This embodiment also provides a computer program product. When the computer program product runs on an electronic device, the electronic device is caused to execute the above-related steps to implement the drive function simulation method in the above embodiment.

[0133] In addition, an embodiment of the present application also provides a device, which may specifically be a chip, component, or module. The device may include a processor and a memory connected to each other. Among them, the memory is used to store computer execution instructions. When the device runs, the processor can execute the computer execution instructions stored in the memory so that the chip executes the drive function simulation method in the above method embodiments.

[0134] Among them, the electronic device, computer-readable storage medium, computer program product, or chip provided in this embodiment are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be elaborated here.

[0135] Through the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and brevity of description, only the above division of each functional module is used as an example. In actual applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

[0136] In several embodiments provided by the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the module or unit is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in electrical, mechanical or other forms.

[0137] In addition, each functional unit in various embodiments of the present application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0138] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on such an understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The software product is stored in a storage medium and includes several instructions for causing a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods described in various embodiments of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, ROMs, magnetic disks, or optical discs that can store program codes.

[0139] For those skilled in the art, it is obvious that the present application is not limited to the details of the above-mentioned exemplary embodiments, and can be implemented in other specific forms without departing from the spirit or basic characteristics of the present application. Therefore, as long as it is within the scope of the substantial spirit of the present application, the appropriate changes and variations made to the above embodiments should fall within the scope of protection required by the present application.

Claims

1. A simulator, characterized in that, The simulator includes: A bus access adaptation module, configured to receive bus access messages and perform timing marking on the received bus access messages, where the bus access messages include register access configuration parameters corresponding to drive functions; A data algorithm matching module, connected to the bus access adaptation module, configured to initialize drive model data of different devices and generate a register access decision tree corresponding to each device. The data algorithm matching module is further configured to receive the bus access message with timing marking, convert the bus access message into an extraction message, and transmit the extraction message to the register access decision tree for access model matching; A state machine management module, connected to the data algorithm matching module, configured to receive the access model when the data algorithm matching module matches an access model, perform drive state machine judgment based on the access model to determine whether the access model is an access model that conforms to the current state, and output a corresponding test result according to the determination result.

2. The simulator according to claim 1, characterized in that, The bus access adaptation module includes a bus access adaptation unit and a timing marking unit. The bus access adaptation unit is configured to receive the bus access message and bridge the bus access message to the timing marking unit. The timing marking unit is connected to the bus access adaptation unit and is configured to receive the bus access message from the bus access adaptation unit and add timing marking to the bus access message.

3. The simulator according to claim 1 or 2, characterized in that, The data algorithm matching module includes an initialization unit and an algorithm matching unit. The initialization unit is configured to initialize drive model data of different devices and generate a register access decision tree corresponding to each device. The algorithm matching unit is connected to the initialization unit and is configured to, when the bus access adaptation module receives the bus access message, extract the information of the bus access message to generate an extraction message and send it to a message queue, control the dequeue of the extraction message in the message queue, and sequentially compare and match the dequeued extraction message with the register access decision tree to confirm whether there is an access model corresponding to the extraction message.

4. The simulator according to claim 3, characterized in that, The algorithm matching unit also adaptively adjusts the matching algorithm granularity according to the number of message dequeues and the matching result.

5. The simulator according to any one of claims 1 - 4, characterized in that, The register access decision tree includes a register root node, register decision nodes, and access models. The register root node corresponds to one or more register decision nodes, and each register decision node corresponds to an access model and / or one or more register decision nodes. The register root node, several register decision nodes, and several access models together form a tree structure to form the register access decision tree.

6. The simulator according to any one of claims 1 - 5, characterized in that, The state machine management module includes a state machine management unit and a message interaction unit. The state machine management unit is connected to the data algorithm matching module and is configured to, when receiving the access model, perform state machine judgment based on the received access model and output the test result through the message interaction unit.

7. The simulator according to claim 6, characterized in that, The state machine management unit is further configured to, when receiving an access model, refresh the current state and the register model database according to the data of the access model, and transmit the refreshed register model data to the data algorithm matching module, and the data algorithm matching module initializes by using the refreshed register model data to establish the register access decision tree.

8. A drive test method, characterized in that, The drive test method includes: Initializing the drive model data of different devices and generating a register access decision tree corresponding to each device; Receiving a bus access message and performing timing marking on the received bus access message, where the bus access message includes register access configuration parameters corresponding to drive functions; Receiving the bus access message after timing marking, converting the bus access message into an extraction message, and transmitting the extraction message to the register access decision tree for access model matching; When an access model is matched, performing a drive state machine judgment according to the access model to determine whether the access model is an access model that conforms to the current state, and outputting a corresponding test result according to the determination result.

9. The drive test method according to claim 8, characterized in that, The receiving the bus access message after timing marking, converting the bus access message into an extraction message, and transmitting the extraction message to the register access decision tree for access model matching includes: Receiving the bus access message, extracting the information of the bus access message to generate an extraction message and sending it to a message queue; Controlling the dequeue of the extraction message in the message queue; Sequentially comparing and matching the dequeued extraction message with the register access decision tree to confirm whether there is an access model corresponding to the extraction message.

10. The drive test method according to claim 9, characterized in that, The drive test method further includes: Adapting and adjusting the matching algorithm granularity according to the message dequeue quantity and the matching result.

11. The drive test method according to any one of claims 8 - 10, characterized in that, The register access decision tree includes a register root node, register decision nodes, and access models. The register root node corresponds to one or more register decision nodes, and each register decision node corresponds to an access model and / or one or more register decision nodes. The register root node, several register decision nodes, and several access models together form a tree structure to form the register access decision tree.

12. The drive test method according to any one of claims 8 - 11, characterized in that, The drive test method further includes: When receiving an access model, refreshing the current state and the register model database according to the data of the access model; Initializing the refreshed register model data, and further establishing a corresponding register access decision tree.

13. The drive test method according to any one of claims 8 - 12, characterized in that, The drive test method further includes: Opening one of the applications in the application layer, where the application accesses hardware resources; Performing drive function settings according to the called hardware resources; Converting the data of the drive function settings into corresponding register access configuration parameters and transmitting them in the form of the bus access message.

14. An electronic device, comprising an operating system, characterized in that, The operating system includes an application layer, an application framework layer, a hardware abstraction layer, a kernel layer, and a simulator as described in any one of claims 1 to 7, and the simulator is disposed in the hardware abstraction layer.

15. An electronic device, characterized in that, It includes a processor and a memory; the memory is used to store instructions; the processor is used to call the instructions in the memory so that the electronic device executes the drive test method described in any one of claims 8 to 13.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction, and when the at least one instruction is executed by a processor, it implements the drive test method described in any one of claims 8 to 13.

Images