CC2530, 各种智能家居通信技术比较
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, 各种智能家居通信技术比较的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： GTK学习心得
- 下一篇： GitHub, Google Code,