引言

隨著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等對串口進行操作。

需要注意的是，對串口的寫操作比較容易，但是讀操作存在著阻塞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%的覆蓋。