摘要：隨著WLAN(無線局域網(wǎng))的普及，各種接口的WLAN網(wǎng)卡層出不窮，像UART，SPI，USB等。為了驗證接口的功能、性能和兼容性是否符合需求，在此提出了一種支持UART&SPI接口的驗證工具。傳統(tǒng)的接口驗證采用手動驗證的方法，即手動修改UART接口的波特率或SPI接口的大小端等來達到遍歷所有用例的目的，傳統(tǒng)方法存在效率低，容易漏測測試用例等缺陷。而該工具通過命令通道完成上位機和下位機的協(xié)商，保持接口參數(shù)同步;數(shù)據(jù)通道驗證在該接口參數(shù)下的功能和性能，實現(xiàn)了接口的功能和性能驗證的自動化，大大提高了測試效率，保證測試用例的覆蓋率。該工具適用于多種平臺下的UART和SPI接口驗證。

0 引言

隨著WLAN的廣泛應用，越來越多的芯片廠商投入到WLAN芯片開發(fā)上。因此各種接口的WLAN芯片成為了各大廠商發(fā)展的主要方向。目前主流的接口有：USB，SDIO，UART，SPI等。

本公司設計了一款支持多接口、多協(xié)議的無線局域網(wǎng)802.11n(1T1R)的SoC芯片。該SoC芯片集成了SDIO，SPI，UART等接口。為了驗證各個接口是否能夠達到設計需求，需要對各個接口進行功能、性能和兼容性的測試。所謂接口驗證，是指以接口為測試對象，詳細測試接口功能和性能。本文中是指UART接口和SPI接口。對于UART接口，需要對接口的波特率、數(shù)據(jù)長度、奇偶校驗位、停止位、流控、異常錯誤等進行驗證。對于SPI接口，需要對接口的大小端、工作模式、工作速率等進行驗證。

1 接口單元驗證的必要性

1.1 接口單元驗證簡介

如圖1所示，是接口單元驗證的示意圖。測試板有兩個UART接口和一個SPI接口。下位機完成固件部分，也就是直接操作硬件;而上位機完成測試用例管理和接口驅(qū)動兩部分。

1.2 對接口進行單元驗證的原因

(1)驗證接口的功能是否實現(xiàn)。保證設備能夠正確枚舉，各種配置下數(shù)據(jù)收發(fā)通路暢通。

(2)對各個接口的性能有一個準確的把握。有了接口性能數(shù)據(jù)后，可以幫助在系統(tǒng)測試階段定位問題。在系統(tǒng)測試階段，性能瓶頸一方面來自于接口，一方面來自于WiFi。在接口驗證階段獲得這個數(shù)據(jù)后可以幫助分析和定位問題。

(3)在平臺兼容性測試中，由于平臺的兼容性主要與接口有關，與WiFi無關，如果把兼容性放到系統(tǒng)測試階段去做，無形中增加了定位問題的難度。

1.3 傳統(tǒng)接口驗證的方法及缺陷

傳統(tǒng)的驗證方法是將上位機與下位機分離開來。首先上位機修改參數(shù)，之后下位機修改參數(shù)，編譯固件、運行，上位機與下位機進行通信。上位機與下位機之間沒有協(xié)商，直接進行通信。以UART接口的功能驗證為例來說明一下接口驗證方法的缺陷。

UART的功能驗證主要是各種配置下(波特率、數(shù)據(jù)長度、奇偶校驗位、停止位的組合)是否能夠準確無誤地傳輸數(shù)據(jù)。如果按照這種測試方法的話，測試效率很低。另外一個方面，由于主觀因素的影響，采用手動的方法容易漏測測試用例。

綜上，傳統(tǒng)接口單元驗證方法的缺陷為：測試效率低;容易漏測測試用例。

2 接口驗證工具的設計

2.1 硬件架構

2.1.1 PC下的硬件結構

如圖2所示，描述的是PC環(huán)境下的UART接口的驗證硬件結構圖。

其中PCI通過JTAG接口控制測試板，完成固件的下載。PC2與測試板通過UART接口連接，UART0接口是命令接口，主要傳輸PC2對測試板的命令及測試板的響應;UART1是數(shù)據(jù)接口，主要傳輸PC2和測試板之間的數(shù)據(jù)。

2.1.2 嵌入式平臺下的硬件結構

如圖3所示，描述的是嵌入式平臺下UART接口和SPI接口的驗證硬件結構圖。

其中PCI通過JTAG接口控制測試板，完成固件的下載。PC2通過串口控制嵌入式平臺。在驗證UART接口時，連接測試板與嵌入式平臺的兩個UART口，UART0接口是命令接口，主要傳輸嵌入式平臺對測試板的命令及測試板的響應;UART1是數(shù)據(jù)接口，主要傳輸嵌入式平臺與測試板之間的數(shù)據(jù)。

在驗證SPI接口時，連接測試板與嵌入式平臺的UART0口及SPI接口。同樣地，UART0是命令接口，主要傳輸嵌入式平臺與測試板的命令傳輸;SPI是數(shù)據(jù)接口，傳輸嵌入式平臺與測試板之間的數(shù)據(jù)。

2.2 軟件結構

驗證軟件結構見圖4，其中DUT設備為驗證的對象。

(1)用例管理層

主要生成各種測試用例。對于UART接口來說，包括UART波特率、數(shù)據(jù)長度、停止位、奇偶校驗位等屬性組合的設置及高級設置項等。

對于SPI接口來說，主要包括SPI的各種模式、各種時鐘、大小端及上下行數(shù)據(jù)的測試用例的生成。

(2)配置接口層

依據(jù)配置程序與驅(qū)動程序命令/事件接口定義完成各種命令的發(fā)送，并做相應的事件處理。

(3)驅(qū)動接口層

依據(jù)配置程序與驅(qū)動程序命令/事件接口定義對配置程序發(fā)送的命令進行解析，同時對硬件的狀態(tài)信息進行響應。

(4)硬件接口層

主要負責驅(qū)動與固件接口操作，對DUT設備進行設置，對DUT進行寫命令/數(shù)據(jù)，或從DUT設備獲取狀態(tài)/數(shù)據(jù)信息。

3 接口驗證工具的實現(xiàn)

考慮到兼容各個嵌入式平臺(Linux系統(tǒng))，故整個上位機軟件工作在Linux系統(tǒng)下。從圖5可以看出，整個軟件的實現(xiàn)主要由配置程序、驅(qū)動程序及固件3部分組成。本文重點介紹配置程序及驅(qū)動程序部分。

3.1 配置程序

配置程序主要由測試用例管理和配置接口層兩部分組成，主要完成測試用例管理及測試用例的生成。

3.1.1 測試用例管理

測試用例管理部分主要完成測試用例的分發(fā)、定位以及測試結果的收集。為了兼容各個Linux版本，測試用例管理部分不采用界面的形式進行管理，而是采用命令行的形式運行。用例管理部分可以選擇單個或多個測試用例進行測試。例如：uart_test case1 case2是對第一、二個測試用例進行測試，uart_test all是對所有的測試用例進行測試。測試用例管理部分會根據(jù)測試用例ID自動定位到相應的程序執(zhí)行。圖5是測試用例管理部分的流程圖。

3.1.2 測試用例的生成

以UART接口為例，描述一個完整的測試用例。圖6描述的是一個UART接口的完整的測試用例。從途中可以清晰地看出配置程序是如何協(xié)調(diào)上位機與下位機之間的通信的。

本文提出的驗證工具與以往的驗證工具最大的區(qū)別在于配置程序可以協(xié)調(diào)上位機與下位機。上位機與下位機并不是完全分離的，而是由配置程序統(tǒng)一協(xié)調(diào)，分別給上位機和下位機下發(fā)命令修改參數(shù)及通信。

3.1.3 兼容性的實現(xiàn)

由于對SPI接口來說，要求兼容PC機和多個嵌入式平臺，所以在程序的設計上要考慮兼容性的問題。

兼容性問題需要考慮兩個方面：

(1)數(shù)據(jù)類型的重定義。

(2)采用分層設計的思想。

3.2 驅(qū)動程序

驅(qū)動程序主要包括驅(qū)動接口層和硬件接口層。其中驅(qū)動接口層主要完成將配置程序的命令或數(shù)據(jù)進行解析，通過接口發(fā)送出去，而硬件接口層主要負責驅(qū)動與硬件(固件)接口操作，負責對DUT設備進行設置，對待測設備進行寫命令/數(shù)據(jù)，或從DUT設備獲取狀態(tài)/數(shù)據(jù)信息。

3.2.1 UART接口驅(qū)動開發(fā)

UART協(xié)議比較簡單，本文不對UART協(xié)議進行介紹。由于在LINUX系統(tǒng)下，對串口有相當好的支持。Linux下把串口看作一個文件來處理，故對串口的讀寫操作相當于對文件直接進行讀寫操作。這樣我們可以直接調(diào)用系統(tǒng)函數(shù)如open，write，read，close等對串口進行操作。

需要注意的是，對串口的寫操作比較容易，但是讀操作存在著阻塞I/O的問題。在對串口進行讀取操作的時候，如果使用的是RAW模式，每個read系統(tǒng)調(diào)用將返回當前串行輸入緩沖區(qū)中存在的字節(jié)數(shù)。如果沒有數(shù)據(jù)，將會一直阻塞到有字符到達或者間隔時鐘到期，或者發(fā)生錯誤此時可采用異步讀取。所謂異步讀取，指的是先查詢串口，看串口是否可用，直到串口可用了再去讀就可以避免阻塞I/O的問題。

3.2.2 SPI接口驅(qū)動開發(fā)

(1)SPI概述

SPI的通信原理很簡單，它以主從方式工作，這種模式通常有一個主設備和一個或多個從設備，需要至少4根線，事實上3根也可以(單向傳輸時或者硬件復用兩根數(shù)據(jù)線)，也是所有基于SPI的設備共有的，它們是MISO，MOSI，SCK，CS。

MOSI為主設備數(shù)據(jù)輸出，從設備數(shù)據(jù)輸入;MISO為主設備數(shù)據(jù)輸入，從設備數(shù)據(jù)輸出;SCK為時鐘信號，由主設備產(chǎn)生;CS為從設備使能信號，由主設備控制。

(2)SPI驅(qū)動開發(fā)

在Linux下開發(fā)SPI驅(qū)動有兩種方式，一種是采用Linux自帶的SPI子系統(tǒng)，一種是采用字符設備驅(qū)動的形式。本文采用了字符設備驅(qū)動的形式。在Linux 2.6內(nèi)核中使用cdev結構體描述字符設備。cdev結構體如下所示。字符設備的主要工作是初始化、添加和刪除cdev的結構體，申請和釋放設備號，以及填充file_operations結構體的操作函數(shù)，實現(xiàn)file_operations結構體中的read()，write()和ioctl()等。

cdev結構體的dev_t成員定義了設備號，另一個重要成員file_operations定義了字符設備驅(qū)動提供給虛擬文件系統(tǒng)的接口函數(shù)。file_ operations結構體中的成員函數(shù)是字符設備驅(qū)動程序設計的主體內(nèi)容，這些函數(shù)實際會在應用程序進行Linux的open()，write()，read()，close()等系統(tǒng)調(diào)用時最終被調(diào)用。

Linux字符設備驅(qū)動主要由以下幾部分組成：

(1)字符設備驅(qū)動模塊加載與卸載函數(shù)

在字符設備驅(qū)動模塊加載函數(shù)中應該實現(xiàn)設備號的申請和cdev的注冊，對應的是insmod過程，而在卸載函數(shù)中應實現(xiàn)設備號的釋放和cdev的注銷，對應的是rmmod過程。

(2)字符設備驅(qū)動的file_operations結構體中成員函數(shù)

file_operations結構體中成員函數(shù)是字符設備驅(qū)動與內(nèi)核的接口，是用戶空間對Linux進行系統(tǒng)調(diào)用最終的落實者。

(3)加載字符設備驅(qū)動之后，在用戶空間建立一個設備節(jié)點，在用戶空間就可以對設備進行操作了，操作方式操作文件的方式相同。

3.2.3 驅(qū)動與固件的接口

驅(qū)動與固件之間的交互是通過自定義的“AT+”協(xié)議，協(xié)議交互流程見圖7。

AT+命令主要包括3個：“AT+”：判斷串口鏈路是否正常。如果正常，返回OK;不正常，返回error;“AT+set”：接口參數(shù)設置命令。如果參數(shù)設置完成，返回OK;不正常，返回error;“AT+send”：數(shù)據(jù)發(fā)送命令。如果數(shù)據(jù)發(fā)送/接收正確，返回OK;否則，返回error。

4 結語

本文介紹的工具適用于UART接口和SPI接口的功能、性能和兼容性測試，可實現(xiàn)測試的自動化。采用該測試工具，一方面提高了測試效率，大大節(jié)約了人力資源，時間和人力成本節(jié)約了50%以上;另一方面可以保證測試用例100%的覆蓋。

編輯：jq