CAN port drive communication test method, system and product

Abstract

The invention discloses a CAN port drive communication test method, system and product, and the method comprises the steps that a transmitting end generates communication test data automatically through a frame data generation tool in a command line tool script, and transmits the communication test data to a second hardware single board; wherein a bus monitoring tool in the command line tool script synchronously runs and starts a background process to store communication test data generated by the sending end; the receiving end uses a bus monitoring tool to start a background process to record the data sent by the sending end, and stores the data sent by the sending end to a receiving record file; and the receiving end obtains a comparison result of the received record file and the communication test data stored in the background process, and the CAN port drive communication test is completed. The generation, sending, receiving and verification of the data in the CAN port drive communication test can be automatically completed based on the pre-configured command line tool script, so that the full-automatic execution of the whole test process is realized, and the test efficiency is improved while the test cost is saved.

Description

Technical Field

[0001] This application relates to the field of driver stability testing, specifically to a CAN port driver communication testing method, system, and product. Background Technology

[0002] Currently, traditional CAN port communication testing usually requires manually creating test data and sending it to the test terminal. After receiving the data, the test terminal still needs to manually verify it to determine the communication test results.

[0003] Therefore, the existing communication testing process often consumes a lot of manpower and time, which leads to low efficiency in communication testing; secondly, the method of manually determining the results of communication tests is also prone to a high error rate.

[0004] Therefore, existing CAN port communication testing methods still suffer from low testing efficiency and accuracy. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a CAN port driver communication testing method, system and product. In this method, the generation, transmission, reception and verification of data in CAN port driver communication testing can be automatically implemented based on a pre-configured command line tool script, so as to realize the fully automatic execution of the entire testing process, thereby saving testing costs and improving testing efficiency.

[0006] In a first aspect, the present invention provides a CAN port driver communication testing method. This method is applied to a CAN port driver communication testing system, which includes two hardware boards that transmit data based on the CAN communication protocol. Each hardware board is pre-configured with a command-line tool script. When the first hardware board runs the command-line tool script and determines itself to be the transmitter, and the second hardware board runs the command-line tool script and determines itself to be the receiver, the method includes: The sending end uses the frame data generation tool in the command-line tool script to automatically generate communication test data and sends the communication test data to the receiving end; the bus monitoring tool in the command-line tool script runs synchronously and starts a background process to save the communication test data generated by the sending end; The receiving end uses a bus monitoring tool to start a background process to record the data sent by the sending end, and saves the data sent by the sending end to the receiving log file; The receiving end obtains the comparison results between the received record file and the communication test data saved by the background process, and completes the CAN port driver communication test.

[0007] In one possible implementation, when the comparison result indicates that the received record file and the communication test data are inconsistent, the method further includes: Back up the current received log file and the current communication test data, and trigger the setting script to return an error flag.

[0008] In one possible implementation, after the sending end automatically generates communication test data using a frame data generation tool, the method further includes: The sending end starts the process of receiving the trigger tag file. When the sending end receives the trigger tag file created by the receiving end, it sends the communication test data to the receiving end.

[0009] In one possible implementation, the first or second hardware board runs a command-line tool script, including: The CAN port number and initialization parameters are determined sequentially by the command-line tool script at multiple preset locations, and the CAN port is initialized according to the initialization parameters; the initialization parameters include at least the operation type, the number of test loops, the test data frame type, and the data frame transmission and reception format.

[0010] In one possible implementation, when the operation type obtained by the hardware board represents a write operation, the hardware board is the sending end; When the operation type obtained by the hardware board represents a read operation, the hardware board is the receiving end.

[0011] In one possible implementation, the test loop is repeated 64 times.

[0012] In one possible implementation, the command-line tool script is the CANUTILS toolset, the frame data generation tool is the cangen tool, and the bus monitoring tool is the candump tool.

[0013] Secondly, a CAN port driver communication test system is provided. The system includes two hardware boards, which are a transmitter and a receiver for data transmission based on the CAN communication protocol, and are used to execute the CAN port driver communication test method in the first aspect.

[0014] In one possible implementation, the hardware board is a circuit board equipped with a touch display device.

[0015] Thirdly, a computer program product is provided, which contains instructions that, when the instructions are executed, are performed according to the method described in the first aspect above.

[0016] Fourthly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method described in the first aspect above.

[0017] Fifthly, a computer-readable storage medium is provided having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the method described in the first aspect above.

[0018] Compared to the low efficiency and accuracy of manual CAN port communication testing in existing technologies, the CAN port driver communication testing method, system, and product provided in this application can automatically generate test data for CAN port driver communication testing based on pre-configured command-line tool scripts on each hardware board, and automatically complete the sending, receiving, and verification processes of test data, thereby achieving fully automated execution of the entire testing process and improving testing efficiency. Secondly, it can automatically generate test results for CAN port driver communication testing based on the verification and comparison results of test data, thereby improving the accuracy of communication testing. Attached Figure Description

[0019] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of the architecture of the CAN port driver communication test system 10 provided in the embodiments of this application; Figure 2 This is a flowchart illustrating a CAN port driver communication testing method provided in an embodiment of this application. Figure 3 This is a schematic diagram of the initialization process of the test CAN port provided in an embodiment of this application; Figure 4 This is a schematic diagram of the execution flow of the sending end 11 provided in the embodiments of this application; Figure 5 This is a schematic diagram of the execution flow of the receiving end 12 provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0020] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.

[0022] Currently, existing CAN port communication testing methods, which rely on manually creating CAN port communication test data and manually verifying the stability of CAN port communication, still suffer from low testing efficiency and accuracy.

[0023] To address this issue, this application provides a CAN port driver communication testing method. The method utilizes a CAN port driver communication testing system where two boards are connected via a standard CAN port. Based on a pre-configured command-line tool script, different preset operation parameters (write / read operations) are obtained, thereby initiating the sending or receiving process respectively. Specifically, the generation and verification of sent and received data are entirely automated by the tool and script, significantly reducing testing costs. Furthermore, this testing method can quickly and accurately verify the stability and completeness of the CAN port driver's porting and adaptation, further ensuring the delivery quality of products using this driver.

[0024] In one embodiment of this application, a CAN port driven communication testing system is provided.

[0025] In one possible implementation, Figure 1 This is a schematic diagram of the architecture of the CAN port driver communication test system 10 provided in this application embodiment. The CAN port driver communication test system 10 is used to execute the CAN port driver communication test method provided in this application, such as... Figure 1 As shown, the CAN port driver communication test system 10 includes a first hardware board 1 and a second hardware board 2 for data transmission based on the CAN communication protocol.

[0026] For example, the first hardware board 1 and the second hardware board 2 are pre-configured with command-line tool scripts; correspondingly, the first hardware board 1 and the second hardware board 2 can run the command-line tool scripts respectively to determine themselves as the sender 11 or the receiver 12.

[0027] Specifically, the first hardware board 1 and the second hardware board 2 can determine themselves as the sender 11 or the receiver 12 based on the operation type parameters represented by the command line tool script; wherein, the operation type parameters include Write operation (i.e., corresponding to sender 11) and Read operation (i.e., corresponding to receiver 12).

[0028] For example, the first hardware board 1 and the second hardware board 2 can be circuit boards equipped with touch display devices (e.g., touch screens). This application does not impose specific limitations on the size of the touch display devices.

[0029] It should be noted that the CAN port driver communication test system 10 is limited to one transmitter and one receiver. Based on this, the command line tool scripts pre-configured in the first hardware board 1 and the second hardware board 2 respectively include one of the Write operation parameters and the Read operation parameters.

[0030] In another embodiment of this application, a CAN port driver communication testing method is provided.

[0031] In one possible implementation, Figure 2 This is a flowchart illustrating a CAN port driver communication testing method provided in an embodiment of this application, such as... Figure 2 As shown, the method specifically includes the following steps: In step S201, the sending end 11 automatically generates communication test data using the frame data generation tool in the command-line tool script and sends the communication test data to the receiving end 12; wherein, the bus monitoring tool in the command-line tool script runs synchronously and starts a background process to save the communication test data generated by the sending end 11.

[0032] In one possible implementation, the command-line tool script is a shell script containing the standard CANUTILS toolset, which includes the frame data generation tool cangen and the bus monitoring tool candump sub-tool.

[0033] For example, the sending end 11 uses the frame data generation tool cangen to automatically generate communication test data and sends the communication test data to the receiving end 12. At the same time, it uses the bus monitoring tool candump to start a background process to automatically save the communication test data generated by the sending end 11 and the identifier of the sending process (e.g., the sending process ID).

[0034] In this embodiment, on the one hand, based on the application of the frame data generation tool cangen, communication test data is automatically generated without the need for manual data filling; on the other hand, the communication test data is saved through a background process to facilitate subsequent verification and comparison of the data received by the receiving end 12.

[0035] In one possible implementation, after the sending end 11 automatically generates communication test data, the sending end 11 starts the process of receiving the trigger marker file; wherein, the trigger marker file is a write trigger marker file actively created by the receiving end 12 for the sending end 11.

[0036] For example, the receiving end 12 can create a trigger flag file by mounting the directory of the sending end 11 (e.g., mounting via sshfs).

[0037] Correspondingly, when the sending end 11 receives the trigger flag file created by the receiving end 12, it indicates that the trigger flag file is ready. At this time, the sending end 11 clears the previous transmission data file and sends the communication test data to the receiving end 12.

[0038] For example, the time window for sending communication test data by the sending end 11 can be set to 2 seconds; specifically, when the 2-second sending time is reached, the background process will automatically stop, that is, the sending end 11 will finish sending this time.

[0039] Correspondingly, when the above-mentioned transmission ends, the sending end 11 clears the trigger flag file received this time, and at the same time increases the number of transmission cycles by one.

[0040] In this embodiment, based on the synchronization mechanism formed by the trigger tag file, the communication test data is sent to the receiving end 12 only when the sending end 11 receives the trigger tag file, thereby avoiding the omission of communication test data; it should be noted that the trigger tag file can be synchronously agreed upon in the command line tool script configured on each hardware board.

[0041] In step S202, the receiving end 12 uses a bus monitoring tool to start a background process to record the data sent by the sending end 11, and saves the data sent by the sending end 11 to the receiving record file.

[0042] For example, when receiver 12 starts, it first clears the previously received data file, then creates a trigger flag file for sender 11, and after the trigger flag file is sent to sender 11, it uses the bus monitoring tool candump to start a background process to record the data sent by sender 11 and the identifier of the receiving process (e.g., receiving process ID).

[0043] For example, the data reception time of the receiving end 12 can be set to 5 seconds; specifically, when the 5-second reception time is reached, the background process will automatically stop, that is, the reception end 12 ends this reception.

[0044] In step S203, the receiving end 12 obtains the comparison result between the receiving record file and the communication test data saved by the background process, and completes the CAN port driver communication test.

[0045] For example, when the comparison result indicates that the received record file is consistent with the communication test data generated by the sending end 11, the result of this communication test is that the data reception is correct.

[0046] Optionally, if the comparison result indicates that the received record file is inconsistent with the communication test data generated by the sending end 11, then the result of this communication test is a data reception error.

[0047] Specifically, when a data reception error occurs, the receiving end 12 can record an error file (i.e., back up the current reception record file and the current communication test data), and check and analyze the error file after the test is completed to trigger the setting script to return an error flag.

[0048] Correspondingly, after the above data comparison is completed, the receiving end 12 can increase the number of receiving cycles by one.

[0049] In the CAN port driver communication testing method provided in this application embodiment, the transmitting end 11 uses the cangen tool to generate and send communication test data, and uses the candump tool to record the sent data; the receiving end 12 uses the candump tool to receive and record the communication test data, compares the received / sent data after receiving, and automatically backs up the received / sent data when errors occur, so as to facilitate traceability and analysis after the test is completed. Based on this, this application provides a simple and reliable CAN port driver stability testing method. This testing method is easy to implement and efficient and stable, so that it can detect potential problems in CAN port driver porting and adaptation in a timely manner when the platform is imported, thereby meeting the driver self-test requirements when the new platform is imported and ensuring delivery quality.

[0050] In another embodiment of this application, initialization operations for a hardware board are also provided.

[0051] In this embodiment, the two hardware boards perform an initialization operation before conducting CAN port driver communication tests.

[0052] In one possible implementation, when the first hardware board 1 or the second hardware board 2 runs the command-line tool script, the CAN port number and initialization parameters can be determined sequentially based on the parameters at multiple preset locations in the command-line tool script, and the CAN port can be initialized according to the initialization parameters.

[0053] For example, the initialization parameters include at least the operation type, the number of test loops, the test data frame type, and the data frame transmission format; wherein, the operation type may include write / read operation, the test data frame type may include CAN standard frame / extended frame (i.e., std / ext), and the data frame transmission format may include sequential transmission / random transmission (i.e., seq mode / rdm mode).

[0054] Specifically, the seq mode mentioned above corresponds to the sequential sending / receiving of data frames, meaning the number of data frames sent / received each time is the same as the current loop count. For example, if the current loop is the 1st, then 1 data frame is sent / received; if the current loop is the nth, then n data frames are sent / received. The rdm mode mentioned above corresponds to the random sending / receiving of data frames. For example, if the current loop is the 1st, then x data frames are sent / received, where x is a random number (ranging from 1 to the loop count); if the current loop is the nth, then x data frames are sent / received, where x is also a random number.

[0055] For example, the CAN port number can be determined based on the first parameter of the command-line tool script, the operation type can be determined based on the second parameter, the number of test loops can be determined based on the third parameter, the test data frame type can be determined based on the fourth parameter, and the data frame transmission and reception format can be determined based on the fifth parameter. The number of test loops can be customized by the user, such as 64 or 1060 times.

[0056] Correspondingly, when the operation type determined by the hardware board based on the command-line tool script is a write operation, the hardware board is the sender 11; when the operation type determined by the hardware board based on the command-line tool script is a read operation, the hardware board is the receiver 12.

[0057] In one example, Figure 3 This is a schematic diagram of the initialization process of the test CAN port provided in an embodiment of this application, as shown below. Figure 3 As shown, the process includes the following steps: Step S301: Parse the parameters in the command-line tool script to determine the CAN port number; Step S302: Set the standard CAN frame arbitration stage bit rate to 500 kbit / s; Step S303: Set the sampling point for the arbitration phase to 80% of the in-situ time; Step S304: Set the bit rate of the data phase to 2 Mbit / s; Step S305: Set the sampling point in the data phase to 80% of the in-situ time; Step S306: Enable CAN FD mode.

[0058] In another embodiment of this application, another CAN port driver communication test method is also provided. This CAN port driver communication test method is also applicable to the above-mentioned CAN port driver communication test system 10, so as to perform CAN port data communication test based on the standard CANUTILS toolset.

[0059] For example, taking a single-loop test as an example, the method includes the following steps: (1) The receiving end 12 creates a trigger flag file on the sending end 11 to trigger the sending end 11 to start sending test data; (2) The sending end 11 uses the cangen command to send test data. The test data is automatically generated by the cangen tool. At the same time, the candump command is used to automatically record the sent test data in the background (so that the receiving end 12 can receive and compare the verification). Among them, the frame type of the sent test data is compatible with CAN standard frame and extended frame, and the number of sent frames is compatible with both sequential (seq) and random (rdm) modes. (3) The receiving end 12 uses the candump command to receive and save the received test data in the background; (4) After receiving the data, the receiving end 12 compares the received data with the test data generated by the sending end 11. If the received / sent data are inconsistent, the received / sent data is backed up so that it can be checked and analyzed after the test is completed. (5) The test ends after both the sender and receiver have completed all the loops according to the above process.

[0060] In one example, taking a test loop of 64 times and using extended frames and sequential frame transmission as an example, the test command can be implemented using the following code: ` / can-test.sh can0 up` # Before the test starts, both the sending and receiving ends initialize the can0 port. / can-test.sh can0 w 64 ext seq # First start the sending board / can-test.sh can0 r 64 ext seq # Restart the receiving board In the CAN port driver communication test method provided in this application embodiment, firstly, the entire test process is executed automatically, saving test costs and improving test efficiency without manual intervention; secondly, the communication test is compatible with CAN standard frame and extended frame communication tests, and the number of test frames can be a single incremental pattern or a random value to simulate various complex scenarios in actual applications.

[0061] Correspondingly, Figure 4 This is a schematic diagram of the execution flow of the sending end 11 provided in the embodiments of this application, as follows: Figure 4 As shown, the process includes the following steps: Step S401, Sending begins; Step S402: Determine whether the preset number of test cycles has been reached; For example, if the condition is not met, proceed to step S403; otherwise, continue to step S412.

[0062] Step S403: Determine whether a trigger marker file has been received; For example, if received, step S404 is executed; otherwise, step S403 is executed.

[0063] Step S404, the execution time window is 0.5s; Step S405: Clear the previously sent data; Step S406: Start a background process to record the sent data and the sending process ID; Step S407: Send standard / extended frames, and send a number of frames sequentially / randomly; Step S408, the execution time window is 2 seconds; Step S409, increase the loop count by 1; Step S410: Clear the background process sending data and the sending process ID; Step S411: Clear the trigger marker file; Step S412, transmission complete.

[0064] Correspondingly, Figure 5 This is a schematic diagram of the execution flow of the receiving end 12 provided in the embodiments of this application, as follows: Figure 5 As shown, the process includes the following steps: Step S501, reception begins; Step S502: Determine whether the preset number of test cycles has been reached; For example, if the condition is not met, proceed to step S503; otherwise, continue with step S511.

[0065] Step S503: Clean up the received data file; Step S504: Create a trigger marker file; Step S505: Start a background process to record received data and the receiving process ID; Step S506, the execution time window is 5 seconds; Step S507: Clear the background process receiving data and the receiving process ID; Step S508: Determine whether the received data is consistent with the data sent by the sending end 11; For example, if so, proceed to step S509; otherwise, proceed to step S510.

[0066] Step S509, increase the loop count by 1; Step S510: Record the error file; Step S511, reception ends.

[0067] The following is for reference. Figure 6 , Figure 6A schematic diagram of a communication device suitable for implementing embodiments of this application is shown, such as... Figure 6 As shown, the communication device 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 602 or a program loaded from a storage section 608 into a random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the system's operating instructions. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0068] The following components are connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0069] Specifically, according to embodiments of this application, the flowchart above refers to... Figures 2-5 Any of the described processes can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined in the system of this application.

[0070] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium compatible with computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0071] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0072] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be housed in a processor; for example, a processor may be described as including a semantic extraction unit, a weight allocation unit, and a determination unit. The names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0073] On the other hand, this application also provides a computer-readable storage medium, which may be included in the communication device described in the above embodiments, or may exist independently and not assembled into the communication device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figures 2-5 Each step of any of the methods shown.

[0074] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figures 2-5 Each step of any of the methods shown.

[0075] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A CAN port driver communication testing method, characterized in that, The method is applied to a CAN port driver communication test system, which includes two hardware boards that transmit data based on the CAN communication protocol. Each hardware board is pre-configured with a command-line tool script. When the first hardware board runs the command-line tool script and determines itself to be the sending end, and the second hardware board runs the command-line tool script and determines itself to be the receiving end, the method includes: The sending end automatically generates communication test data using the frame data generation tool in the command-line tool script, and sends the communication test data to the receiving end; wherein, the bus monitoring tool in the command-line tool script runs synchronously and starts a background process to save the communication test data generated by the sending end; The receiving end uses the bus monitoring tool to start the background process to record the data sent by the sending end, and saves the data sent by the sending end to the receiving record file; The receiving end obtains the comparison result between the received record file and the communication test data saved by the background process, and completes the CAN port driver communication test.

2. The CAN port driver communication test method according to claim 1, characterized in that, When the comparison result indicates that the received record file is inconsistent with the communication test data, the method further includes: Back up the current received log file and the current communication test data, and trigger the setting script to return an error flag.

3. The CAN port driver communication test method according to claim 1, characterized in that, After the sending end automatically generates communication test data using the frame data generation tool, the method further includes: The sending end initiates the process of receiving the trigger marker file. When the sending end receives the trigger marker file created by the receiving end, it sends the communication test data to the receiving end.

4. The CAN port driver communication test method according to claim 1, characterized in that, The first hardware board or the second hardware board runs the command-line tool script, including: Based on the parameters at multiple preset locations, the command-line tool script sequentially determines the CAN port number and initialization parameters, and performs initialization operations on the CAN port according to the initialization parameters; wherein, the initialization parameters include at least the operation type, the number of test loops, the test data frame type, and the data frame transmission and reception format.

5. The CAN port driver communication test method according to claim 4, characterized in that, When the operation type obtained by the hardware board represents a write operation, the hardware board is the sending end; When the operation type acquired by the hardware board represents a read operation, the hardware board is the receiving end.

6. The CAN port driver communication test method according to claim 4, characterized in that, The test was repeated 64 times.

7. The CAN port driver communication test method according to claim 1, characterized in that, The command-line tool script is a shell script containing the standard CANUTILS toolset, the frame data generation tool is the cangen tool, and the bus monitoring tool is the candump tool.

8. A CAN port driver communication test system, characterized in that, The system includes two hardware boards, which are a transmitter and a receiver for data transmission based on the CAN communication protocol, and are used to execute the CAN port drive communication test method according to any one of claims 1-7.

9. The CAN port driver communication test system according to claim 8, characterized in that, The hardware board is a circuit board equipped with a touch display device.

10. A computer program product, characterized in that, The computer program product includes instructions that, when executed, cause the method as described in any one of claims 1-7 to be implemented.

Images