rs485串口调试软件,rpc接口测试工具

引言

随着WLAN的广泛应用，越来越多的芯片制造商投入到WLAN芯片开发中。 因此，各种接口的WLAN芯片成为各厂商发展的主要方向。 目前主流的接口有USB、SDIO、UART、SPI等。

本文设计了一种支持多接口、多协议的无线局域网802.11 n (1t1r ) SoC芯片。 该SoC芯片集成了SDIO、SPI、UART等接口。 要验证每个接口是否满足设计要求，必须测试每个接口的功能、性能和兼容性。 接口验证是指以接口为测试对象，详细测试接口的功能和性能。 在本文中，它是指UART接口和SPI接口。 UART接口需要验证端口的波特率、数据长度、奇偶校验、停止位、流控制、异常错误等。 对于SPI接口，需要验证接口的大小、操作模式、操作速度等。

1验证接口单元的必要性

1.1接口单元验证概述

如图1所示，是接口单元的验证的图像。 测试板有两个UART连接器和一个SPI连接器。 下位机完成固件部分，即直接操作硬件； 上位机完成测试用例管理和接口驱动两部分。

1.2为什么要对接口进行单元验证

)1)验证接口功能是否实现。 保证设备正确列举，各种配置下数据收发路径畅通。

)2)准确掌握各接口性能。 有了接口性能数据，它有助于在系统测试阶段确定问题。 在系统测试阶段，性能瓶颈同时来自接口和WiFi。 在接口验证阶段获取此数据有助于分析和确定问题。

)3)在平台兼容性测试中，平台兼容性主要涉及接口，而与WiFi无关，因此兼容性在系统测试阶段进行，无形中增加了定位问题的难度。

1.3传统接口验证的方法和缺陷

传统的验证方法是将上位机与下位机分离。 首先上位机修改参数，然后下位机修改参数，编译和运行固件，上位机与下位机进行通信。 上位机与下位机之间没有协议，直接进行通信。 以UART接口的功能验证为例说明接口验证方法的缺点。

UART的功能验证主要是能否在各种配置(波特率、数据长度、奇偶校验位和停止位的组合)中正确传输数据。 用这种测试方法，测试效率很低。 另一方面，由于主观因素的影响，用手动方法容易看漏测试用例。

综上所述，现有接口单元的验证方法的缺点是测试效率低； 容易看漏测试用例。

2界面验证工具的设计

2.1硬件体系结构

2.1.1 PC上的硬件配置

如图2所示，表示PC环境下的UART接口的验证硬件结构图。

其中PCI通过JTAG接口控制测试板，完成固件下载。 PC2和测试板通过UART接口连接，UART0接口是命令接口，主要传输PC2的命令和测试板对测试板的响应； UART1是一个数据接口，主要传输PC2和测试板之间的数据。

2.1.2嵌入式平台上的硬件配置

如图3所示，给出了嵌入式平台下UART接口和SPI接口的验证硬件结构图。

其中PCI通过JTAG接口控制测试板，完成固件下载。 PC2通过串行端口控制嵌入式平台。 验证UART接口时，连接测试板和嵌入式平台两个UART端口，UART0接口是命令接口，主要是针对嵌入式平台测试板的命令和测试板UART1是一个数据接口，主要用于在嵌入式平台和测试板之间传输数据。

验证SPI连接器时，将测试板和嵌入式平台上的UART0端口连接到SPI连接器。 同样，UART0是命令接口，主要传输嵌入式平台和测试板的命令传输； SPI是一个数据接口，用于在嵌入式平台和测试板之间传输数据。

2.2软件配置

验证软件的结构见图4。 其中，DUT设备是验证对象。

(1)用例管理层

主要生成各种测试用例。 UART接口包括UART波特率、数据长度、停止位和奇偶校验位等属性的组合设置和高级设置。

SPI接口的情况主要包括生成SPI的各种模式、各种时钟、大小终端和上下数据的测试用例。

(2)配置接口层

按照配置器和驱动程序命令/事件接口的定义完成各种命令的发送，并进行相应的事件处理。

(3)驱动接口层

根据配置器和驱动程序命令/事件接口的定义，分析配置器发送的命令并响应硬件状态信息。

)4)硬件接口层

主要负责驱动程序和固件的接口操作、DUT设备的设置、命令/数据写入DUT或从DUT设备获取状态/数据信息。

3接口验证工具的实现

考虑到与各个嵌入式平台(Linux系统)的兼容性，整个上位机软件在Linux系统上运行。 从图5可以看到，整个软件的实现主要由三部分组成：配置器、驱动程序和固件。 本文侧重于配置程序和驱动程序部分。

3.1程序配置

配置程序主要由测试用例管理和配置接口层两部分组成，主要完成测试用例管理和测试用例的生成。

3.1.1测试用例管理

测试用例管理部分主要完成测试用例的分发、定位以及测试结果的收集。为了兼容各个Linux版本，测试用例管理部分不采用界面的形式进行管理，而是采用命令行的形式运行。用例管理部分可以选择单个或多个测试用例进行测试。例如：uart_test case1 case2是对第一、二个测试用例进行测试，uart_test all是对所有的测试用例进行测试。测试用例管理部分会根据测试用例ID自动定位到相应的程序执行。图5是测试用例管理部分的流程图。

3.1.2 测试用例的生成

以UART接口为例，描述一个完整的测试用例。图6描述的是一个UART接口的完整的测试用例。从途中可以清晰地看出配置程序是如何协调上位机与下位机之间的通信的。

本文提出的验证工具与以往的验证工具最大的区别在于配置程序可以协调上位机与下位机。上位机与下位机并不是完全分离的，而是由配置程序统一协调，分别给上位机和下位机下发命令修改参数及通信。

3.1.3 兼容性的实现

由于对SPI接口来说，要求兼容PC机和多个嵌入式平台，所以在程序的设计上要考虑兼容性的问题。

兼容性问题需要考虑两个方面：

(1)数据类型的重定义。

(2)采用分层设计的思想。

3.2 驱动程序

驱动程序主要包括驱动接口层和硬件接口层。其中驱动接口层主要完成将配置程序的命令或数据进行解析，通过接口发送出去，而硬件接口层主要负责驱动与硬件(固件)接口操作，负责对DUT设备进行设置，对待测设备进行写命令/数据，或从DUT设备获取状态/数据信息。

3.2.1 UART接口驱动开发

UART协议比较简单，本文不对UART协议进行介绍。由于在LINUX系统下，对串口有相当好的支持。Linux下把串口看作一个文件来处理，故对串口的读写操作相当于对文件直接进行读写操作。这样我们可以直接调用系统函数如open，write，read，close等对串口进行操作。

需要注意的是，对串口的写操作比较容易，但是读操作存在着阻塞I/O的问题。在对串口进行读取操作的时候，如果使用的是RAW模式，每个read系统调用将返回当前串行输入缓冲区中存在的字节数。如果没有数据，将会一直阻塞到有字符到达或者间隔时钟到期，或者发生错误此时可采用异步读取。所谓异步读取，指的是先查询串口，看串口是否可用，直到串口可用了再去读就可以避免阻塞I/O的问题。

3.2.2 SPI接口驱动开发

(1)SPI概述

SPI的通信原理很简单，它以主从方式工作，这种模式通常有一个主设备和一个或多个从设备，需要至少4根线，事实上3根也可以(单向传输时或者硬件复用两根数据线)，也是所有基于SPI的设备共有的，它们是MISO，MOSI，SCK，CS。

MOSI为主设备数据输出，从设备数据输入;MISO为主设备数据输入，从设备数据输出;SCK为时钟信号，由主设备产生;CS为从设备使能信号，由主设备控制。

(2)SPI驱动开发

在Linux下开发SPI驱动有两种方式，一种是采用Linux自带的SPI子系统，一种是采用字符设备驱动的形式。本文采用了字符设备驱动的形式。在Linux 2.6内核中使用cdev结构体描述字符设备。cdev结构体如下所示。字符设备的主要工作是初始化、添加和删除cdev的结构体，申请和释放设备号，以及填充file_operaTIons结构体的操作函数，实现file_operaTIons结构体中的read()，write()和ioctl()等。

cdev结构体的dev_t成员定义了设备号，另一个重要成员file_operaTIons定义了字符设备驱动提供给虚拟文件系统的接口函数。file_ operaTIons结构体中的成员函数是字符设备驱动程序设计的主体内容，这些函数实际会在应用程序进行Linux的open()，write()，read()，close()等系统调用时最终被调用。

Linux字符设备驱动主要由以下几部分组成：

(1)字符设备驱动模块加载与卸载函数

在字符设备驱动模块加载函数中应该实现设备号的申请和cdev的注册，对应的是insmod过程，而在卸载函数中应实现设备号的释放和cdev的注销，对应的是rmmod过程。

(2)字符设备驱动的file_operations结构体中成员函数

file_operations结构体中成员函数是字符设备驱动与内核的接口，是用户空间对Linux进行系统调用最终的落实者。

(3)加载字符设备驱动之后，在用户空间建立一个设备节点，在用户空间就可以对设备进行操作了，操作方式操作文件的方式相同。

3.2.3 驱动与固件的接口

驱动与固件之间的交互是通过自定义的“AT+”协议，协议交互流程见图7。

AT+命令主要包括3个：“AT+”：判断串口链路是否正常。如果正常，返回OK;不正常，返回error;“AT+set”：接口参数设置命令。如果参数设置完成，返回OK;不正常，返回error;“AT+send”：数据发送命令。如果数据发送/接收正确，返回OK;否则，返回error。

4 结语

本文介绍的工具适用于UART接口和SPI接口的功能、性能和兼容性测试，可实现测试的自动化。采用该测试工具，一方面提高了测试效率，大大节约了人力资源，时间和人力成本节约了50%以上;另一方面可以保证测试用例100%的覆盖。