http://antkillerfarm.github.io/

CC2530配置紅外載波

CC2530是德州儀器公司推出的用于物聯網領域的基于8051架構的芯片，支持Zigbee、紅外等多種無線通訊方式。本文僅對紅外相關的寄存器配置做一個簡單說明。

1.配置時鐘

配置時鐘需要配置CLKCONCMD寄存器。但是需要注意的是OSC、TICKSPD和CLKSPD存在就低不就高的特點，所以如果稍有不慎，最終Timer輸出的頻率就不正確了。

2.配置pin復用

pin復用分為3個級別：

1）是GPIO，還是外設？（使用PnSEL選擇。）

2）外設布局。（為了方便使用，每個外設都有兩套布局，可用PERCFG選擇。）

3）外設復用選擇。（如果有兩個外設，在第2步之后，仍然共用1個pin，則用P2DIR選擇究竟用誰。注意只有P0的外設可以選，P1是不行的。）

3.配置IR載波

這一步主要是根據載波頻率計算相關寄存器的值，主要是TxCCn（其中x表示Timer x，n表示Channel n）的值。

1） 計算Timer 3的值，以38KHz載波為為例：

32000000 / 38000 = 842.1053只是計量單位變為載波周期而已。

這個值是無法直接用8位的寄存器表示的，因此需要首先4分頻，也就是

842.1053 = 4 * 210.5263

所以T3CC0=211，如果需要占空比50%的載波的話，T3CC1=105。

這樣實際生成的載波頻率為：

32000000 / 4 / 211 = 37914.7

2）計算Timer 1的值。

這里需要注意的是，這里T1CCn中配置的值，不再以Timer tick為單位，而是以載波周期為單位。以NEC編碼的邏輯1為例，載波周期為560us，整個周期為2.25ms。因此：

37914.7 / (1 / 0.00056) = 21.23

37914.7 / (1 / 0.00225) = 85.31

所以T1CC0=85，T1CC1=21

3）配置其他寄存器

IRCTL=1，打開載波模式。需要注意的是，只要載波模式打開，Timer 1的計量單位就變為載波周期，但只有Channel 1，會調制上載波信號。其他的channel只是計量單位變為載波周期而已。

還有要仔細配置相關的Timer中斷，如果沒有必要的話，最好把中斷都關上。畢竟即使沒有中斷處理程序，中斷還是要消耗CPU的運算資源的。

4) timer調制模式

T1CCTLn.CMP一般選擇4 - Clear Output on Compare-Up,Set on 0。

但是信號發送的最后幾幀，需要特殊處理。主要的原因是：對TxCCn的修改不是立即生效，而需等待下一次中斷，但對于T1CCTLn.CMP的修改卻是立即生效的。這兩者的差異有時會造成意想不到的結果。

CC2530雙串口工作

CC2530雖然有兩個UART，但是所有的示例中都只用到了UART0。而網上使用UART1的例子多數是實驗性的代碼，沒有用到ZStack框架。因此對于真正的Zigbee應用來說，如何使用UART1仍是一個難題。

通過閱讀ZStack的代碼，可以發現UART1的使用之所以困難，主要有以下幾方面的問題：

1.Pin復用。由于Pin默認是用于GPIO的，因此要想使用UART1首先要配好相關的Pin。這個可以參考那些從零做起的實驗性代碼，這些代碼主要聚焦于如何配置寄存器，而不是ZStack。

2.ZStack中使用HAL_UART_DMA和HAL_UART_ISR用于指定串口的端口和驅動類型。但由于宏的值是唯一的，因此并不能兩個UART都采用DMA或者ISR。但是一個UART用DMA，另一個用ISR實際上是可以的。這也是最簡單的同時使用雙串口的方法。

3.如果簡單的配置HAL_UART_DMA和HAL_UART_ISR，可能會鏈接失敗。從提示可知是驅動所占的RAM超過了系統的RAM所致。這時需要縮小兩個串口的緩沖區的大小，即修改HAL_UART_DMA_RX_MAX和HAL_UART_ISR_RX_MAX的大小。

4.如果繼續深入代碼的話，可以發現HAL_UART_DMA和HAL_UART_ISR的唯一性，并不是兩個串口不能同時DMA的關鍵。問題的關鍵在于，HAL UART的代碼中，DMA和ISR都只有一套數據結構。因此如果采用兩套數據結構的話，理論上是可以雙串口DMA或ISR的。

5.那么問題就來了，既然可以這樣做，為什么TI不去做呢？一句話還是資源的問題。雙串口會導致每個串口的緩沖區尺寸減小。同時DMA雖然有5個通道，但一個串口就要用掉兩個（收發各一個）。按照ZStack默認的配置，DMA 0沒有用，DMA1、2用于AES，只有DMA3、4用于串口。因此實際上TI是不推薦雙串口同時工作的。

CC2530按鍵事件流程

CC2530的按鍵事件是由GPIO的中斷觸發的。所有的GPIO都可以作為按鍵事件的中斷源。但CPU的中斷向量有限，只有3個中斷向量P0INT、P1INT和P2INT可用于GPIO中斷。在中斷處理程序中，讀取PxIFG寄存器可獲得究竟是哪個GPIO產生的中斷。

1.寄存器

P0IEN—-中斷控制器的中斷開關。

IEN1.P0IE—-CPU中斷的開關。

IRCON—中斷是否pending。

P0IFG—中斷發生時，獲取究竟是哪個GPIO產生的中斷。

PICTL—上升沿還是下降沿觸發中斷。

2.軟件流程

P0INT_VECTOR

halKeyPort0Isr

halProcessKeyInterrupt

HAL_KEY_EVENT

HalKeyPoll

HalKeyRead

HalKeyConfig/OnBoard_KeyCallback

OnBoard_SendKeys

KEY_CHANGE

以上的流程是針對中斷式按鍵消息，輪詢式的按鍵消息，從HAL_KEY_EVENT開始。系統在開機時自動執行一次HAL_KEY_EVENT的處理函數，然后發起下一次的定時查詢請求。如此一直循環下去。

3.向框架添加一個新的按鈕觸發源

HAL代碼中已經有HAL_KEY_SW_6_PORT等一系列的宏，并定義了KEY_SW_6的行為。照著KEY_SW_6的樣子添加新的按鍵即可。

CC2530 Target類型

CC2530EB—Evaluation Board

CC2530USB

CC2530ZNP—Zigbee Pro Network Processor

從各方面的信息綜合來看，這應該是指三種不同類型的板子。

CC2530的競爭對手

目前已知的有Ember公司的EM250、atmel公司的產品、microchip公司的產品。國內的廣州致遠，也就是周立功，也有同類產品（采用NXP JN5168模塊）。

CC2530 Option的幾點解釋

這里以IAR 8.10為例，說明一下菜單Project->Options里有哪些可選的內容以及它們的含義。由于可供選擇的內容非常多且雜，這里僅列舉個人實際使用到的幾點常用功能。

如何確定設備類型？

General Options->Target->Device information->Device

這個常用于根據已有軟件代碼，反查設備型號。在代碼移植的時候很有用。

printf & scanf

General Options->Library options

嵌入式設備由于硬件功能有限，常需對軟件代碼進行裁剪，以恰好滿足需要為最終目標。具體到printf和scanf函數，亦可根據需要選擇不同的功能集合。

VLA

C/C++ Compiler->Language->C dialect

可變長數組（variable length array，簡稱VLA）在我看來，是C99標準的最大福利。這一點VC至今都不支持，鄙視之。。。

輸出的二進制文件的格式

Linker->Output->Format

大的來說可分為兩類：

1.Debug版本。也就是選擇“Debug information for C-APY”選項。如果需要在IAR中，打斷點調試的話，必須選擇這個選項。

2.Release版本。選擇“Other”選項。

這里說一下使用TI公司的SmartRF Flash Programmer燒寫這兩種類型文件的方法。

Release版本比較簡單，直接選擇“Erase and program”即可。

Debug版本需要首先選擇“Read flash into hex-file”，然后再選擇“Erase and program”。如下圖所示：

網上有些人由于不曉得這一步，而得出Debug版本無法燒寫的結論，這是不正確的。

輸出二進制文件的flash布局

在項目的生成路徑下，不僅有存放二進制文件的Exe文件夾，還有個List文件夾。在List文件夾下有個.map文件，包含了很多的鏈接信息。

空中升級

CC2530的空中升級可以使用以下兩種方法：

1.OTA（Over The Air）。這是zigbee聯盟制定的標準。具體到CC2530，就是需要添加ZCL的支持。

2.OAD（Over Air Download）。TI專有的空中升級文件的技術，比OAT更早面市。這也是TI官方的技術人員推薦的方法。

其實兩者的原理都差不多。

并非所有的CC2530設備都能空中升級，TI官方的說法是要想升級需要滿足以下條件之一：

1）有外接FLASH存儲空間。

2）沒有外接FLASH的設備，其image的大小 < (片上FLASH空間 - bootloader空間) / 2。

從第2個條件不難看出，空中升級的原理是將新的image下載到flash空閑區域，然后用新的image替換老的image。

但由于即使最優化的Zstack協議棧也至少有140KB，而CC2530最多只有256KB，因此第2個條件實際上是不可能滿足的。

各種智能家居通信技術比較

名稱概況優點缺點

Zigbee	基于IEEE 802.15.4的一種近程（10米~100米）、低速率（250Kbps標稱速率）、低功耗的無線網絡技術。	具有低復雜度、低功耗、低速率、低成本、自組網、高可靠、超視距的特點。	協議Profile比較復雜，導致廠家的各自為政，產品兼容性較差。
Z-Wave	由丹麥公司Zensys所一手主導的無線組網規格。	Z-wave聯盟的成員均是已經在智能家居領域有現行產品的廠商，產品兼容性好。	技術把持在Zensys手中，產業鏈較封閉，芯片可選余地不大，漸趨式微。
KNX	Konnex協會提出的家庭、樓宇自動化的有線解決方案。	歷史悠久，功能豐富，標準完善，廠商支持度比較高。在西歐和北歐比較流行。	雖然新的標準中可以使用868 MHz的RF進行無線傳輸，但總的來說，還是個有線方案。適合樓宇建筑時的預裝，而不適合后期的智能改造。
BlueTooth Low Energy（BLE）	基于IEEE 802.15.1的的低功耗無線通訊技術。	只是協議升級，無需硬件升級，可充分利用現有手機的藍牙功能，快速部署智能終端。	不支持網狀網絡，不支持多跳。因此要求傳輸雙方都必須在無線信號可直接到達的范圍之內。這一點直接限制了傳輸的距離。BLE 4.1之后，雖然可以自組Mesh網，但硬件須升級。
SUB 1G	1GHz以下的ISM無線通訊技術。	傳輸距離可達2~100km。	協議棧依賴芯片廠商提供。更像一種通訊方式，而非通訊解決方案。
Low Power Wifi	低功耗的wifi技術，有兩個變種：普通型和802.11ah。	傳輸速度高。普通型兼容現有wifi設備。802.11ah穿透性好。	功耗仍然比Zigbee和BLE大一個數量級。
Thread	Google在IEEE 802.15.4的基礎上構建的6LowPan方案。	由于MAC層和Zigbee相同，因此具備Zigbee的大多數優點，且協議更友好（設計思想接近IPV6）。	不兼容現有設備，市場前景有待觀察。
UWB(Ultra Wideband)	一種無載波通信技術，利用納秒至微微秒級的非正弦波窄脈沖傳輸數據。	UWB能在10米左右的范圍內實現數百Mbit/s至數Gbit/s的數據傳輸速率。	尚處于試驗階段，沒有成功的產品。
電力載波	基于電力線傳輸的有線通訊協議。	無須布線，傳輸速度高（500Mbps），距離遠（500m）。	不適合無電力線的場景。
NB-LTE & NB-CIoT	都是蜂窩無線通信網向物聯網進軍的產物。前者由Nokia、Ericsson和Intel提出，而后者由華為提出。	號稱與現有LTE網絡兼容，但2015年9月才推出，具體規格不詳。

總結

以上是生活随笔為你收集整理的CC2530, 各种智能家居通信技术比较的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。