嵌入式Linux系統下CC1101的驅動與應用

鄭翔，岳浩嶺

（杭州電子科技大學電子信息學院，杭州310018）

引 言

CC1101是TI公司推出的一款低于1GHz的高性能射頻收發器，設計旨在用于極低功耗RF 應用，其主要針對工業、科研、醫療（ISM），以及短距離無線通信設備（SRD）。CC1101在各高校電子類實驗室中得到了廣泛的應用，在市場上也有良好的應用前景。目前，從網絡資料及學術論文上來看，國內對于CC1101的應用有兩方面的不足：第一，CC1101在各類低端單片機有著廣泛應用，但是在嵌入式處理器上的應用卻相對較少；第二，在通信信號不穩定的情況下，需要考慮到“面向連接”的通信模式，即需要保證通信質量的可靠性。本文較為詳細地闡述了CC1101在ARM9處理器及嵌入式Linux系統下的開發過程，提出了一種簡單可靠的主從無線通信協議模型。

1 面向連接的通信協議模型

在CC1101的通信過程中，因距離、障礙物等其他環境因素的影響，發送的數據并不一定能被確認接收，即可能出現丟包現象。因此，有必要設計一個簡單的通信協議以保證CC1101通信過程的可靠性，避免丟包現象的出現。

在通信協議模型的設計上，借鑒了TCP協議“面向連接”的通信機制，簡單地說就是在每次發送之后都需要等待一個應答，以保證本次發送數據的正確接收。

為了清晰地闡述“面向連接”的通信過程，將通信雙方區分為server端與client端。在每次通信過程中，發送方為server，接收方為client，其主要通信過程如下：

①在server端保存一全局變量seqno（sequence number），seqno的作用是標識發送的數據報文在server端的編號，在每次發送數據后seqno都要增加，同時區分報文為SEND 與ACK 兩種狀態，SEND 標識本報文為正常發送報文，ACK 標識為應答報文。

②server端發送數據給client時，server端將要發送的數據主體與對應的seqno組成一個數據報文，并標識報文狀態為SEND，繼而調用CC1101發送接口進行數據發送。

③server端在發送后，啟動一定時器，等待由client端回應的應答報文。

若client端接收到server端發送的報文，則client端會發送相應的應答報文給server端，client端應答報文中的seqno要等于從server端接收的seqno，并且報文狀態標識為ACK。server端接收到應答報文后比較收到的seqno與自身的seqno是否相等，若相等，則說明本次發送成功，否則說明本次發送失敗，進行數據報文的重發。

若client端未接收到server端的報文，client端不會發送應答報文給server端，server端在定時器超時前無法接收到應答報文，則說明本次發送失敗，繼而進行報文重發，在超過重發次數后，通知server端數據不可達。

④client端的處理較為簡單，在接收到server端發送的SEND報文后，檢測其中的seqno，將其提取出來并構建ACK 報文，直接發送回server端。

圖1描述了server端面向連接發送的過程。

圖1 面向連接通信模型

2 CC1101在單片機上的驅動

在芯片的控制上，CC1101芯片通過SPI總線的方式與外部控制器通信，這種簡單的串行通信方式使得CC1101可以和大部分的MCU 直接相連，即使在沒有SPI控制器的MCU 上也可以采取I／O 口模擬SPI的方式來通信。而且從網絡資料上看，大部分驅動CC1101芯片的代碼也是采用通過I／O 口模擬SPI的方式，這種I／O 口模擬方式的優點在于屏蔽了不同類型MCU 在SPI控制器設置上的不同，將驅動代碼移植到各個MCU 時，只需要按照I／O 口的連接方式修改代碼中SPI對應的接口信號SCK、MOSI、MISO 和CSN。當然其缺點也很明顯，SPI通信有一定的時序要求，在I／O 模擬SPI時序時，不同MCU對應的驅動代碼在時序模擬這部分需要適配。

除了4線SPI總線對應的SCK、MOSI、MISO 和CSN引腳外，CC1101 具有兩個專用的可配置引腳（GDO0 和GDO2），這些引腳可以用來對MCU 產生中斷。例如，當設置IOCFG0.GDO0＿CFG＝0x06時，接收／發送一個數據包，在RX和TX模式下GDO0引腳會分別產生下降沿電平信號，可作為MCU 的外部中斷。

一個典型的CC1101與MCU連接的方式如圖2所示。

3 嵌入式Linux下CC1101的驅動

在嵌入式Linux系統的硬件平臺上，選擇的是三星公司的S3C2440／ARM9處理器，這款處理器在高校實驗室有著廣泛的應用；嵌入式Linux內核版本采用的是穩定的2.6版本。CC1101與S3C2440 的連接方式如圖3所示，本文采用的是S3C2440 的GPIO 模擬SPI時序的方法，CC1101的GDO0作為外部中斷引腳連接至S3C2440 的EINT15引腳。

圖2 CC1101與MCU連接典型電路

圖3 CC1101與S3C2440的連接

Linux下的設備可以分為字符設備、塊設備和網絡設備，在實際應用中CC1101一般只需要提供發送與接收接口，并且可以按照字節流讀取，所以本文將CC1101 歸類為字符設備。

字符設備開發過程中最主要的數據結構為fop（file＿operation）結構，它包括了一系列文件操作接口。和CC1101字符設備開發相關的主要部分包括CC1101 的初始化、CC1101的發送／接收接口，以及CC1101各種狀態寄存器修改接口等。需要實現上述fop結構中的接口包括：

①open：設置SCK、MOSI、CSN、GDO2對應的GPIO為輸出方式，MISO 對應GPIO 為輸入方式，GDO0對應的引腳為外部中斷（EINT15）方式，完成通過GPIO 模擬SPI初始化CC1101的工作，申請外部中斷資源，由于采用了中斷方式，在CC1101接收到數據時觸發中斷，在中斷程序中進行CC1101接收緩存數據的讀取，設置可讀取標志位rcv＿flag。

②write：CC1101的發送接口，用戶態應用程序調用write系統，調用發送數據。

③read：無阻塞地讀取CC1101 接收到的數據，重置可讀取標志位。

④poll：poll函數是為了配合用戶態的select系統調用，只有在上述可讀取標志位被設置的情況下，返回POLLIN。

⑤ioctl：用于設置CC1101的其他狀態，設置其內部寄存器。

⑥release：釋放中斷資源，關閉字符設備。

4 用戶態應用程序編寫

在上述CC1101內核驅動完成之后，即可以在用戶態程序中打開設備并使用它。為了實現第一部分介紹的面向連接通信過程cc1101＿link＿send，在每次發送數據之后，都要啟動一個定時器，等待由對端發送而來的ACK 報文，具體在Linux用戶態程序中采用了select系統調用。此系統最終調用內核態fop中的poll函數，select函數原型為：

readfds 表示讀文件集。在timeout 時間段內，若readfds讀文件集沒有變化，則select函數超時；readfds讀文件集有變化則表示CC1101收到數據，此時再調用read系統函數讀取CC1101接收的數據，比較seqno和報文狀態即可以完成上述的面向連接通信機制。

面向連接的發送接口cc1101＿link＿send部分代碼如下：

上述程序只是簡單地實現了前述的面向連接通信機制，當然，用戶可以參照現有的TCP／IP、ZigBee等成熟的通信協議，在應用程序層定制簡單實用的通信協議，定義與修改C1101通信的報文格式，如增加地址、命令字等，以完成其他更加豐富的功能。

5 系統測試

將CC1101內核驅動編譯成module模塊加載至嵌入式Linux系統中，并運行用戶態應用程序，圖4（a）左側顯示了發送超時的情形，可見在發送超時后會繼續發送直至最大發送次數，圖4（b）則顯示了正常的面向連接發送過程。經驗證，在面向連接的通信模型下CC1101可保證通信質量。

圖4 用戶態應用程序

結 語

為了解決CC1101通信質量不穩定的問題，提出了一種面向連接的通信模型。在嵌入式Linux系統下開發了CC1101的驅動，并基于上述的通信模型編寫了應用程序，驗證了驅動及應用程序的正確性。本文在一定程度上彌補了關于嵌入式Linux系統下應用CC1101資料不豐富的不足，也為CC1101的無線通信協議開發提供參考。

［1］廖建尚.ARM9和Linux的DS18B20驅動程序研究［J］.單片機與嵌入式系統應用，2013（4）：53-56.

［2］DanielP，Bovet.Understanding the Linux Kernel［M］.北京：中國電力出版社，2007.

［3］Jonathan Corbet.Linux Device Drivers［M］.北京：中國電力出版社，2006.

［4］Texas Instruments.CC1101 Low-Cost Low-Power Sub-1GHz RF TransceiverDatasheet［EB／OL］.［2013-08-05］.http：／／www.alldatasheet.com／datasheet-pdf／pdf／191432／TI／CC1101.html.

［5］Neil Matthew，Richard Stones.Linux程序設計［M］.北京：人民郵電出版社，2010.

［6］曹桂平.Linux內核網絡棧源代碼情景分析［M］.北京：人民郵電出版社，2010.