实现了接口功能和性能验证自动化的UART＆SPI接口验证工具设计

引言

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

本文设计了一款支持多接口、多协议的无线局域网802.11n（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部分组成。本文重点介绍配置程序及驱动程序部分。

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等对串口进行 *** 作。

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%的覆盖。