A test method and device for a serial communication protocol of an internet of things communication device

Abstract

The application relates to the technical field of communication equipment testing, and provides a test method and device for a serial communication protocol of Internet of Things communication equipment.The test method comprises the following steps: a test board card automatically receives data of a to-be-tested equipment and performs testing; according to a test case, the test board card receives and analyzes data of the to-be-tested equipment, records and outputs a test result of the test case, and the execution of all test cases is completed; wherein the process of analyzing the data of the to-be-tested equipment comprises the following steps: the test board card receives cache data with a time stamp, and the type of a communication protocol is confirmed according to the imported test case; based on the type of the communication protocol, the cache data is selectively divided; the idle state, the starting condition and the stopping condition of the divided data are found, the cache data is analyzed according to the type of the communication protocol, and an analysis result is obtained; the analysis result is compared with an expected result, so that whether the analysis is successful or not is judged, and a test report is generated.

Description

Technical Field

[0001] This invention relates to the field of communication equipment testing technology, and in particular to a method and apparatus for testing serial communication protocols of Internet of Things (IoT) communication devices. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] Testing serial communication protocols in IoT communication devices involves parameter testing of various serial communication protocols, such as UART, SPI, and I2C. Currently, the testing method for serial communication protocols in IoT devices involves configuring the serial interface parameters of the device under test (DUT) using commands, controlling the DUT's serial interface output data, capturing data using an oscilloscope and logic analyzer, observing the specific waveforms, analyzing the waveforms of various serial communication protocols, and confirming whether the protocol parameters are consistent with the preset parameters and whether the protocol-carried data is correct.

[0004] Traditional testing methods require manual configuration of the device under test (DUT), signal capture and analysis for various serial communication protocols, and comparison with expected parameters to obtain test results. Because each DUT has numerous parameters, manual analysis is complex and labor-intensive, reducing overall testing efficiency. Furthermore, manual testing is susceptible to inaccurate results due to human error and differences in testing equipment. Summary of the Invention

[0005] To address the technical problems mentioned above, this invention provides a method and apparatus for testing serial communication protocols of IoT communication devices. This invention can automatically configure the device under test, capture and analyze the protocol data output by the device under test, compare it with preset protocol data, and output a test report, which will greatly improve testing efficiency and accuracy.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: The first aspect of the present invention provides a method for testing serial communication protocols of Internet of Things (IoT) communication devices.

[0007] A method for testing serial communication protocols of IoT communication devices, comprising: The test cases and configuration commands for the device under test (DUT) are imported into the host computer via a script, and then sent to the test board. The test board is connected to the DUT, and the test board sends configuration information to the DUT to configure its parameters. The host computer sends a start test signal to the test board, and the test board controls the DUT to output data according to the set parameters. The test board automatically receives the data from the DUT and performs the test. According to the test cases, the test board receives and parses the DUT data, records and outputs the test results for each test case, until all test cases have been executed and the test is complete. The process of parsing the data of the device under test includes: the test board receives cached data with timestamps and confirms the type of communication protocol based on the imported test cases; based on the type of communication protocol, the cached data is selectively divided; the idle state, start condition, and stop condition of the divided data are found, and the cached data is parsed according to the type of communication protocol to obtain the parsing result; the parsing result is compared with the expected result to determine whether the parsing is successful and a test report is generated.

[0008] Furthermore, the types of communication protocols include UART, SPI, and I2C protocols.

[0009] Furthermore, the process of selectively dividing the cached data based on the type of communication protocol includes: dividing the cached data using the SPI protocol into SCK data, CS data, MOSI data, and MISO data, and dividing the cached data using the I2C protocol into SCL data and SDA data.

[0010] Furthermore, the process of parsing the cached data according to the type of communication protocol includes: parsing the UART protocol data, specifically: when the idle state is consistent with the preset time, finding the start bit and recording the timestamp; calculating the baud rate based on the expected UART parameters and the start bit; when the baud rate is within the error range, acquiring and parsing the data content; when the parsing result is consistent with the expected result, acquiring the parity bit; when the parity bit is consistent with the expected parity bit, acquiring and parsing the stop bit based on the expected number of stop bits; when the parsed stop bit is consistent with the expected stop bit, the parsing is successful; if any of the aforementioned steps fails, the parsing fails.

[0011] Furthermore, the process of parsing the cached data according to the type of communication protocol also includes: parsing the SPI protocol data, specifically: finding the active edge of the CS data, and determining the first active edge of the clock according to the expected SPI mode; after finding the first active edge, continuing to search for the next active clock edge; after finding the next active clock edge, calculating the clock frequency and comparing it with the expected frequency to determine whether the clock frequency is within the error range; if so, parsing the MOSI data and MISO data according to the clock signal to obtain the parsing result, comparing the parsing result with the expected result to determine whether the parsing is successful; if any of the aforementioned steps fails, the parsing fails.

[0012] Furthermore, the process of parsing cached data according to the type of communication protocol also includes: parsing I2C protocol data, specifically: using SCL data to find two consecutive rising edges, when the clock frequency is within the error range, parsing the address according to the queried starting condition, comparing the parsed address with the expected address, if the parsed address is accurate, then parsing the read / write bits, after parsing the read / write bits, then parsing the ACK, i.e. the acknowledgment bit, and comparing it with the expected ACK, if the ACK parsing result is correct, parsing the specific data content, and comparing the parsing result with the expected result to determine whether the parsing was successful.

[0013] A second aspect of the present invention provides a test apparatus for serial communication protocols of Internet of Things (IoT) communication devices.

[0014] A serial communication protocol testing device for Internet of Things (IoT) communication devices includes a host computer, a test execution module, and a device under test (DUT), wherein the test execution module is connected to both the host computer and the DUT. The test execution module includes a microcontroller, which includes a protocol parsing module, a protocol parsing algorithm library, and a report generation module. The host computer is used to import test cases and configuration commands for the device under test, and send the test cases and configuration commands to the test board. The test board is used to send configuration information to the device under test (DUT) to configure the parameters of the DUT; receive the start test signal sent by the host computer; control the DUT to output data according to the set parameters; automatically receive the data of the DUT and perform tests; according to the test cases, the test board receives and parses the data of the DUT, records and outputs the test results of the test cases until all test cases are completed. The protocol parsing module is used to receive cached data with timestamps, confirm the type of communication protocol based on the imported test cases, selectively divide the cached data based on the type of communication protocol, find the idle state, start condition and stop condition of the divided data, parse the cached data according to the type of communication protocol, and obtain the parsing result; compare the parsing result with the expected result to determine whether the parsing was successful. The report generation module is used to generate test reports.

[0015] Furthermore, the test execution module also includes a test interface module, a level conversion module, a non-volatile memory, a board control interface, and a device under test control interface; The test interface module has physical communication interfaces with multiple serial port interface standards for capturing signals from the device under test. The level conversion module is used to provide the microcontroller with a usable level signal; The non-volatile memory is used to store test cases and test parameters; it is also used to store test process data and test results. The board control interface is used to interact with the host computer; The device under test (DUT) control interface is used to interact with the DUT.

[0016] Furthermore, the protocol parsing algorithm library includes a variety of serial communication protocol parsing algorithms, including but not limited to UART protocol parsing algorithm, SPI protocol parsing algorithm and I2C protocol parsing algorithm.

[0017] Furthermore, the process of the UART protocol parsing algorithm includes: reading cached data, obtaining and parsing the idle state, finding the start bit and recording the timestamp when the idle state matches the preset time, calculating the baud rate based on the expected UART parameters and the start bit, obtaining and parsing the data content when the baud rate is within the error range, obtaining the parsing bit when the parsing result matches the expected result, obtaining the parity bit when the parity bit matches the expected parity bit, obtaining and parsing the stop bit based on the expected number of stop bits when the parsed stop bit matches the expected stop bit, and parsing is successful when any of the aforementioned steps fails.

[0018] Furthermore, the SPI protocol parsing algorithm process includes: reading buffered data, dividing the signal line data into SCK data, CS data, MOSI data, and MISO data, finding the active edge of the CS data, and determining the first active edge of the clock according to the expected SPI mode; after finding the first active edge, continuing to search for the next active clock edge; after finding the next active clock edge, calculating the clock frequency and comparing it with the expected frequency to determine whether the clock frequency is within the error range; if so, parsing the MOSI data and MISO data according to the clock signal to obtain the parsing result, comparing the parsing result with the expected result to determine whether the parsing is successful; if any of the aforementioned steps fails, the parsing fails.

[0019] Furthermore, the I2C protocol parsing algorithm process includes: reading cached data, dividing the signal line data into SCL data and SDA data, using SCL data to find two consecutive rising edges, and when the clock frequency is within the error range, parsing the address according to the queried starting condition, comparing the parsed address with the expected address, and if the parsed address is accurate, parsing the read and write bits, parsing the ACK after parsing the read and write bits, parsing the ACK (acknowledgment bit), and comparing it with the expected ACK, and if the ACK parsing result is correct, parsing the specific data content, and comparing the parsing result with the expected result to determine whether the parsing was successful.

[0020] Furthermore, the microcontroller also includes: The data capture module is used to capture protocol data; The timestamp module is used to add timestamps to protocol data; The data caching module is used for data caching.

[0021] Compared with the prior art, the beneficial effects of the present invention are: This invention employs multi-protocol parsing, and the software can also be extended with protocols, offering high flexibility. It not only includes common protocols such as UART, SPI, and I2C, but can also be extended to other custom protocols, demonstrating greater flexibility and applicability.

[0022] The protocol parsing algorithm library described in this invention makes the parsing protocol extensible and configurable.

[0023] This invention provides a fully automated solution for the entire process, from test case input, test environment preparation, data capture to protocol parsing and report output, which can significantly improve testing efficiency and accuracy and reduce human error.

[0024] This invention provides a specific protocol parsing process, including steps such as data capture, timestamp addition, data caching (a data structure of level state + timestamp), and protocol parsing. It improves testing efficiency by substituting known test case parameters into the parsing steps for judgment, rather than comparing data after parsing. These processes ensure real-time, efficient, and accurate testing. This invention is suitable for batch testing and long-term testing, applicable to both R&D and production scenarios. Attached Figure Description

[0025] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0026] Figure 1 This is a flowchart illustrating the serial communication protocol testing method for IoT communication devices according to the present invention; Figure 2 This is a framework diagram of the serial communication protocol testing device for Internet of Things communication devices shown in this invention; Figure 3 This is a framework diagram of multi-protocol data reception and processing shown in this invention; Figure 4 This invention illustrates a design drawing for testing a company's serial port server product. Detailed Implementation

[0027] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0028] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0029] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0030] It should be noted that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and systems according to various embodiments of this disclosure. It should be noted that each block in a flowchart or block diagram may represent a module, segment, or portion of code, which may include one or more executable instructions for implementing the logical functions specified in the various embodiments. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutively represented 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 flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, may be implemented using a dedicated hardware-based system that performs the specified functions or operations, or using a combination of dedicated hardware and computer instructions.

[0031] Example 1 like Figure 1 As shown, this embodiment provides a method for testing the serial communication protocol of an Internet of Things (IoT) communication device. A method for testing serial communication protocols of IoT communication devices, comprising: The test cases and configuration commands for the device under test (DUT) are imported into the host computer via a script, and then sent to the test board. The test board is connected to the DUT, and the test board sends configuration information to the DUT to configure its parameters. The host computer sends a start test signal to the test board, and the test board controls the DUT to output data according to the set parameters. The test board automatically receives the data from the DUT and performs the test. According to the test cases, the test board receives and parses the DUT data, records and outputs the test results for each test case, until all test cases have been executed and the test is complete. The process of parsing the data of the device under test includes: the test board receives cached data with timestamps and confirms the type of communication protocol based on the imported test cases; based on the type of communication protocol, the cached data is selectively divided; the idle state, start condition, and stop condition of the divided data are found, and the cached data is parsed according to the type of communication protocol to obtain the parsing result; the parsing result is compared with the expected result to determine whether the parsing is successful and a test report is generated.

[0032] The types of communication protocols include UART, SPI, and I2C.

[0033] The process of selectively dividing cached data based on the type of communication protocol includes: dividing cached data using the SPI protocol into SCK data, CS data, MOSI data, and MISO data, and dividing cached data using the I2C protocol into SCL data and SDA data.

[0034] The process of parsing cached data according to the type of communication protocol includes: parsing UART protocol data, specifically: when the idle state is consistent with the preset time, finding the start bit and recording the timestamp; calculating the baud rate based on the expected UART parameters and the start bit; when the baud rate is within the error range, acquiring and parsing the data content; when the parsing result is consistent with the expected result, acquiring the parity bit; when the parity bit is consistent with the expected parity bit, acquiring and parsing the stop bit based on the expected number of stop bits; when the parsed stop bit is consistent with the expected stop bit, the parsing is successful; if any of the above steps fails, the parsing fails.

[0035] The process of parsing cached data according to the type of communication protocol also includes: parsing SPI protocol data, specifically: finding the active edge of CS data, and determining the first active edge of the clock according to the expected SPI mode; after finding the first active edge, continuing to search for the next active clock edge; after finding the next active clock edge, calculating the clock frequency and comparing it with the expected frequency to determine whether the clock frequency is within the error range. If so, parsing the MOSI data and MISO data according to the clock signal to obtain the parsing result, comparing the parsing result with the expected result to determine whether the parsing is successful; if any of the aforementioned steps fails, the parsing fails.

[0036] The process of parsing cached data according to the type of communication protocol also includes: parsing I2C protocol data, specifically: using SCL data to find two consecutive rising edges, when the clock frequency is within the error range, parsing the address according to the queried starting condition, comparing the parsed address with the expected address, if the parsed address is accurate, then parsing the read and write bits, and after parsing the read and write bits, parsing the ACK, i.e. the acknowledgment bit, and comparing it with the expected ACK, if the ACK parsing result is correct, parsing the specific data content, and comparing the parsing result with the expected result to determine whether the parsing was successful.

[0037] Example 2 This embodiment provides a test device for serial communication protocols of Internet of Things (IoT) communication devices.

[0038] like Figure 2 , Figure 3As shown, an IoT communication device serial communication protocol testing device includes: a host computer, a test execution module, and a device under test (DUT). The DUT communicates with the test execution module, and the test execution module communicates with the host computer.

[0039] The following is a detailed description of each module of this device: The host computer is used to input test cases, control the start and end of tests, and collect and display test reports submitted by the test boards.

[0040] The test execution module, including the test board, is responsible for test execution and data analysis, and outputs a test report. Specifically, the test execution module includes a test interface module, a level conversion module, a microcontroller, non-volatile memory, a power management module, a board control interface, and a device under test (DUT) control interface. The following is a detailed description of each part of the test execution module: Test interface module: A physical communication interface with multiple serial port interface standards, including RS232, RS485, and multiple probes, used to capture signals from the device under test.

[0041] Level conversion module: Provides usable level signals to the microcontroller. In order to ensure compatibility with various devices, the level conversion module is used to convert the data level received from different communication interfaces into a unified level that can be accepted by the internal modules of the test board.

[0042] A microcontroller (such as a high-performance microcontroller) includes: a data acquisition module (capable of sampling and capturing multiple data streams), a timestamp module, a data caching module, a protocol parsing module, a protocol parsing algorithm library, and a report generation module. The data acquisition module captures protocol data; the timestamp module adds timestamps; the data caching module caches data; the protocol parsing module parses the protocol; and the report generation module generates test reports. Furthermore, the contents of the protocol parsing algorithm library are described in detail below: The protocol parsing algorithm library includes independent code modules, which are stored in a separate memory area in the microcontroller, facilitating protocol updates and upgrades. The protocol parsing algorithm library also includes various serial communication protocol parsing algorithms; Each protocol includes: protocol number, protocol name, version number, corresponding protocol parsing function, and protocol description, as shown in Table 1.

[0043] Table 1. Relevant parameters of different protocols

[0044] Non-volatile memory is used to store test cases and test parameters; it is also used to store test process data and test results. Examples include high-capacity Flash memory.

[0045] The power management module is used to supply power to the various components.

[0046] Board control interface: An interface for interacting with a host computer, consisting of interfaces such as Ethernet, for example, a host computer communication interface.

[0047] Control interface for device under test: Supports RS232, RS485, RS422, Ethernet, Bluetooth, etc., for interacting with IoT communication devices under test to configure the device under test.

[0048] The device under test is an IoT communication device.

[0049] The implementation process of the IoT communication device serial communication protocol testing device described in this embodiment is described in detail below: (1) Input test data Import the test cases into the host computer via script. The test cases include information such as the type of protocol to be tested, protocol parameters, and the data content output by the device under test. (This is both the test case and the expected result. The data parsed later will be compared with this result.)

[0050] For example, Table 2 shows a sample test case input: Table 2 Test Case Input Examples

[0051] Input the script for the device under test. The script contains two parts: test cases and configuration commands for the device under test. The configuration commands for the device under test include AT commands, etc. The above relevant data is sent to the test board through the test board's control interface.

[0052] (2) Perform the test (2-1) Prepare the test environment The test board establishes a connection between the control interface of the device under test (DUT) and the configuration interface of the DUT, such as through an RS232 or Ethernet interface. The test board is then connected to the control terminal of the DUT to prepare for configuring the IoT communication device under test.

[0053] The test interface module of the test board is physically connected to the data output interface of the device under test. The connection needs to be made according to different interface types. For example, for communication interfaces such as SPI and I2C, probes can be used for multi-channel connection. There is no need to distinguish the signal lines when connecting. For UART protocol testing, RS232 and RS485 communication interfaces can be used to connect according to the device interface in order to prepare for capturing the data output by the device under test.

[0054] (2-2) Configure the test board with the device under test The test board establishes a connection with the configuration interface of the device under test (DUT). The test board sends configuration information to the DUT and configures the DUT parameters, such as the UART parameters above: baud rate 115200, data bits 8, stop bits 1, parity 0dd. After successfully configuring the DUT, it waits for the start test signal from the host computer.

[0055] (2-3) The host computer triggers the start of the test. The host computer sends a start test signal to the test board. The test board controls the device under test to output data according to the set parameters. For example, according to test case 1, the device under test outputs data 0x55 0x55 0x55 via UART, sends 100 times, and sends data at 500ms interval.

[0056] (2-4) Capture data from the device under test After the communication data from the device under test is level-converted, the data acquisition unit (such as GPIO sampling) in the microcontroller captures the data according to the acquisition conditions, capturing data within a fixed time range, such as capturing 5 seconds. The timestamp module adds a precise timestamp to each captured data segment or event, which facilitates subsequent analysis of the timing relationship in the data. The captured and timestamped data is temporarily stored in the data cache module. The data cache module stores an array of data structures consisting of level status and timestamp. This array may be one or more, and this data is the waveform-like data used for subsequent analysis.

[0057] (2-5) Test Data Analysis The protocol parsing module inside the microcontroller first calls the corresponding protocol parsing algorithm to parse the array composed of a data structure of level state and timestamp in detail, based on the protocol name input in the test case. If the parsing is successful according to the protocol parsing algorithm, the test case passes; otherwise, the test fails.

[0058] The overall parsing algorithm uses an array partitioning and known parameter substitution method. After confirming which line the received array belongs to, some parameters of the protocol data, such as the communication frequency, are initially parsed. Then, the known test case parameters are substituted one by one into the parsing step. If the parsing is successful using the known parameters, it means that the parsing is successful; otherwise, the parsing fails. When parsing fails, the data in the current parsing array for a period of time is stored for subsequent failure analysis.

[0059] The overall parsing algorithm includes the UART protocol parsing algorithm, the SPI protocol parsing algorithm, and the I2C protocol parsing algorithm.

[0060] The specific process of the UART protocol parsing algorithm includes: 1) Read data from the cache array; 2) Look for a long-term high-level state, i.e., an idle state: - Iterate through all samples to find continuous high-level states.

[0061] - Verify whether the duration of the high-level state meets the requirements. For example, in this embodiment, the data transmission interval is 500ms, so the duration of the high-level state is about 500ms and meets the error requirements of the idle state.

[0062] 3) Find the starting position: After finding an idle state, continue traversing the samples until a sample whose level changes from high to low is found, which is the start bit.

[0063] 4) Verify the validity of the start bit: - Check if the starting position has been found in the sample array.

[0064] - And confirm whether the remaining samples in the array are sufficient to parse the complete UART frame.

[0065] 5) Calculate the baud rate: - The actual baud rate is calculated using the time from the start bit to the stop bit.

[0066] - Compare the calculated baud rate with the expected baud rate to ensure the error is within acceptable limits.

[0067] 6) Parse data bits: - Skip the start position.

[0068] - Read data bit by bit. For each bit, first move it to the middle of the bit, then read the level status. High level represents 1, low level represents 0.

[0069] - Continue this process until all data bits have been read.

[0070] 7) Verify the data content: - Compare the received data with the expected data.

[0071] 8) Parse the check digit (if it exists): - Move to the middle of the parity bit, then read the level; - Calculate the check digit; 9) Parsing the stop bits: - Analyze all stop bits one by one.

[0072] - Move to the middle of each stop bit and then verify that its level is high.

[0073] 10) Return results: - If all the above steps are completed successfully, return `true`, indicating that the UART data parsing was successful.

[0074] - If any step fails, return `false` and store the relevant data and the reason for the failure.

[0075] The specific process of the SPI protocol parsing algorithm includes: 1) Start 2) Divide the SPI lines and allocate a sample array to each line; Input: A two-dimensional array of buffered data; Outputs: One-dimensional array of clock line data (CLK), one-dimensional array of chip select line data (CS), one-dimensional array of MOSI line data, and one-dimensional array of MISO line data; 3) Identify the active edges of CS; If not found: end and return failure; If found: Proceed to the next step; 4) Determine the first active edge of the clock according to the SPI mode; 5) Locate the first active edge of the clock; If not found: end and return failure; If found: Record the timestamp and continue to the next step; 6) Find the next active edge of the clock; If not found: end and return failure; If found: Record the timestamp and continue to the next step; 7) Calculate the actual frequency based on the time difference between the two active edges; ->If the frequency deviation is too large: terminate and return failure; If the frequency is normal: Proceed to the next step; 8) Parse MOSI and MISO data; -> Iterate through each data bit: * Read the data at the current bit position; * Find the next active edge of the clock; * If not found: end and return failure; 9) Compare the expected data with the received data; ->If the data does not match: end and return failure; If the data matches: Proceed to the next step; 10) If all the above steps are successful, a success message will be returned; 11) Return the storage exception data and reason for failure; 12) End.

[0076] The specific process of the I2C protocol parsing algorithm includes: 1) Initialization steps: - Identify the SCL and SDA lines.

[0077] - Define a pointer or index (e.g., `i`) to iterate over the samples.

[0078] 2) Calculate the clock frequency: - When parsing data or addresses, record the time difference between two consecutive rising edges of SCL.

[0079] - Use this time difference to calculate the clock frequency.

[0080] - Compare with the desired clock frequency. If the measured value deviates from the desired value by more than 5%, return failure.

[0081] 3) Check the starting conditions: - Iterate through the samples until a starting condition is found. The starting condition is when SDA changes from high to low while SCL remains high.

[0082] - If no starting condition is found in any of the samples, return failure.

[0083] 4) Resolution address: - For each bit of the address (e.g., 7 bits): - Waiting for the rising edge of SCL.

[0084] - Read the SDA's status and add it to the address value.

[0085] - Waiting for the falling edge of SCL.

[0086] - Compare with the expected address. If they do not match, return failure.

[0087] 5) Parsing the R / W bits: - Waiting for the rising edge of SCL.

[0088] - Read the SDA status and store it as read / write bits.

[0089] - Waiting for the falling edge of SCL.

[0090] - Compare with the expected R / W bits. Return failure if they do not match.

[0091] 6) Check ACK: - Waiting for the rising edge of SCL.

[0092] - Read the status of SDA and check if it is low (ACK bit).

[0093] - Waiting for the falling edge of SCL.

[0094] - If SDA is high (i.e., there is no ACK), return failure.

[0095] 7) Parse the data: - For each byte of the expected data size: - For each digit (usually 8 digits): - Waiting for the rising edge of SCL.

[0096] - Read the SDA's status and add it to the current byte's value.

[0097] - Waiting for the falling edge of SCL.

[0098] - Compare with the expected data bytes. If they do not match, return failure.

[0099] - Check ACK (as described above).

[0100] 8) Complete the analysis: - If all the data can be successfully parsed and matched with the expected data, return success.

[0101] - Returns the storage exception data and the reason for the failure.

[0102] (2-6) Report Generation The test board's report generation module integrates the test cases and data parsing results to generate the final test report. For example, Table 3 shows the test report content: Table 3 Test Report Contents

[0103] like Figure 4 As shown below, taking the testing of a company's serial port server product as an example, the detailed process of using the technical solution of this embodiment is as follows: Device connection: Connect the RS232 serial port of the serial server to the three probes (TX, RX, GND) of the test board, and connect the RS232 interface of the control interface of the device under test on the test board to the RS232 interface of the control interface of the device under test. Parameter configuration: Input test cases through the host computer and transmit them to the test board, such as the test cases shown in Table 2; Start Test: The host computer triggers the development test signal. The test board first configures the parameters of the serial port of the device under test. After the configuration is completed, it controls the device under test to continuously send data.

[0104] Data acquisition and analysis: The test board captures the test data, performs protocol parsing according to the protocol parsing algorithm, and draws test conclusions.

[0105] Generate a report.

[0106] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for testing the serial communication protocol of an Internet of Things (IoT) communication device, characterized in that, include: Import the test cases and configuration commands of the device under test into the host computer via a script, and then send the test cases and configuration commands to the test board. Connect the test board to the device under test (DUT). The test board sends configuration information to the DUT to configure its parameters. The host computer sends a start test signal to the test board. The test board controls the DUT to output data according to the set parameters. The test board automatically receives the data from the DUT and performs the test. According to the test cases, the test board receives and parses the data from the device under test, records and outputs the test results of the test cases, until all test cases have been executed and the test is completed; The process of parsing the data from the device under test includes: the test board receiving cached data with timestamps, confirming the communication protocol type based on the imported test cases; selectively dividing the cached data based on the communication protocol type, including dividing cached data using the SPI protocol into SCK data, CS data, MOSI data, and MISO data, and dividing cached data using the I2C protocol into SCL data and SDA data; finding the idle state, start condition, and stop condition of the divided data, and parsing the cached data according to the communication protocol type, including: parsing UART protocol data. The analysis process is as follows: When the idle state coincides with the preset time, find the start bit and record the timestamp. Calculate the baud rate based on the expected UART parameters and the start bit. If the baud rate is within the error range, acquire and parse the data content. If the parsing result matches the expected result, acquire the check bit. If the check bit matches the expected check bit, acquire and parse the stop bit based on the expected number of stop bits. If the parsed stop bit matches the expected stop bit, the parsing is successful. If any of the above steps fails, the parsing fails. Obtain the parsing result, compare it with the expected result to determine whether the parsing was successful, and generate a test report.

2. The method for testing the serial communication protocol of an IoT communication device according to claim 1, characterized in that, The types of communication protocols include UART, SPI, and I2C.

3. The method for testing the serial communication protocol of an IoT communication device according to claim 2, characterized in that, The process of parsing cached data according to the type of communication protocol also includes: parsing SPI protocol data, specifically: finding the active edge of CS data, and determining the first active edge of the clock according to the expected SPI mode; after finding the first active edge, continuing to search for the next active clock edge; after finding the next active clock edge, calculating the clock frequency and comparing it with the expected frequency to determine whether the clock frequency is within the error range. If so, parsing the MOSI data and MISO data according to the clock signal to obtain the parsing result, comparing the parsing result with the expected result to determine whether the parsing is successful; if any of the aforementioned steps fails, the parsing fails.

4. The method for testing the serial communication protocol of an IoT communication device according to claim 2, characterized in that, The process of parsing cached data according to the type of communication protocol also includes: parsing I2C protocol data, specifically: using SCL data to find two consecutive rising edges, when the clock frequency is within the error range, parsing the address according to the queried starting condition, comparing the parsed address with the expected address, if the parsed address is accurate, then parsing the read and write bits, and after parsing the read and write bits, parsing the ACK, i.e. the acknowledgment bit, and comparing it with the expected ACK, if the ACK parsing result is correct, parsing the specific data content, and comparing the parsing result with the expected result to determine whether the parsing was successful.

5. A serial communication protocol testing device for Internet of Things (IoT) communication devices, characterized in that, It includes a host computer, a test execution module, and a device under test, wherein the test execution module is connected to both the host computer and the device under test. The test execution module includes a microcontroller, which includes a protocol parsing module, a protocol parsing algorithm library, and a report generation module. The host computer is used to import test cases and configuration commands for the device under test, and send the test cases and configuration commands to the test board. The test board is used to send configuration information to the device under test (DUT) to configure the parameters of the DUT; receive the start test signal sent by the host computer; control the DUT to output data according to the set parameters; automatically receive the data of the DUT and perform tests; according to the test cases, the test board receives and parses the data of the DUT, records and outputs the test results of the test cases until all test cases are completed. The protocol parsing module is used to receive cached data with timestamps and determine the type of communication protocol based on the imported test cases. Based on the type of communication protocol, the cached data is selectively divided, including: SPI protocol cached data is divided into SCK data, CS data, MOSI data, and MISO data; I2C protocol cached data is divided into SCL data and SDA data. The idle state, start condition, and stop condition of the divided data are identified. The cached data is then parsed according to the type of communication protocol, including: parsing UART protocol data, specifically: when the idle state matches the preset time, the start bit is found and the timestamp is recorded; the baud rate is calculated based on the expected UART parameters and the start bit; when the baud rate is within the error range, the data content is acquired and parsed; when the parsing result matches the expected result, the parsing bit is acquired; when the parsing bit matches the expected parsing bit, the stop bit is acquired and parsed based on the expected number of stop bits; parsing is successful when the parsed stop bit matches the expected stop bit; if any of the above steps fail, parsing fails. The parsing result is obtained and compared with the expected result to determine whether parsing was successful. The report generation module is used to generate test reports.

6. The IoT communication device serial communication protocol testing device according to claim 5, characterized in that, The test execution module also includes a test interface module, a level conversion module, a non-volatile memory, a board control interface, and a device under test control interface; The test interface module has physical communication interfaces with multiple serial port interface standards for capturing signals from the device under test. The level conversion module is used to provide the microcontroller with a usable level signal; The non-volatile memory is used to store test cases and test parameters; It is also used to store test process data and test results; The board control interface is used to interact with the host computer; The device under test (DUT) control interface is used to interact with the DUT.

7. The serial communication protocol testing device for IoT communication devices according to claim 5, characterized in that, The protocol parsing algorithm library includes various serial communication protocol parsing algorithms, including but not limited to UART protocol parsing algorithm, SPI protocol parsing algorithm and I2C protocol parsing algorithm.

8. The serial communication protocol testing device for IoT communication devices according to claim 7, characterized in that, The process of the UART protocol parsing algorithm includes: reading cached data, obtaining and parsing the idle state, finding the start bit and recording the timestamp when the idle state matches the preset time, calculating the baud rate based on the expected UART parameters and the start bit, obtaining and parsing the data content when the baud rate is within the error range, obtaining the parsing bit when the parsing result matches the expected result, obtaining the parity bit when the parity bit matches the expected parity bit, obtaining and parsing the stop bit based on the expected number of stop bits when the parsed stop bit matches the expected stop bit, and parsing is successful when the parsed stop bit matches the expected stop bit. If any of the above steps fails, parsing fails.

9. The IoT communication device serial communication protocol testing apparatus according to claim 7, characterized in that, The SPI protocol parsing algorithm includes the following steps: reading buffered data, dividing the signal line data into SCK data, CS data, MOSI data, and MISO data, finding the active edge of the CS data, and determining the first active edge of the clock based on the expected SPI mode; after finding the first active edge, continuing to search for the next active clock edge; after finding the next active clock edge, calculating the clock frequency and comparing it with the expected frequency to determine if the clock frequency is within the error range; if so, parsing the MOSI data and MISO data based on the clock signal to obtain the parsing result, comparing the parsing result with the expected result to determine if the parsing was successful; if any of the aforementioned steps fails, the parsing fails.

10. The IoT communication device serial communication protocol testing device according to claim 7, characterized in that, The I2C protocol parsing algorithm process includes: reading buffered data, dividing the signal line data into SCL data and SDA data, using SCL data to find two consecutive rising edges, and when the clock frequency is within the error range, parsing the address according to the queried starting condition, comparing the parsed address with the expected address, and if the parsed address is accurate, parsing the read and write bits, parsing the ACK after parsing the read and write bits, parsing the ACK (acknowledgment bit) and comparing it with the expected ACK, and if the ACK parsing result is correct, parsing the specific data content, and comparing the parsing result with the expected result to determine whether the parsing was successful.

11. The IoT communication device serial communication protocol testing device according to claim 5, characterized in that, The microcontroller also includes: The data capture module is used to capture protocol data; The timestamp module is used to add timestamps to protocol data; The data caching module is used for data caching.

Images