隨著手機內(nèi)RF芯片的集成度不斷增加，編程需求也在顯著增加。但另一方面，手機生命周期在日益縮短。解決復雜性增加和生命周期縮短之間的矛盾的一個方法是采用“硬件”應用編程接口(API)。本文討論開發(fā)API時應遵循的一些規(guī)則以及應避免的一些設計陷阱。

　　射頻IC的主要工作是調(diào)制與解調(diào)發(fā)射數(shù)據(jù)并接收想要的信號。隨著數(shù)字信號處理技術(shù)的出現(xiàn)，越來越多的射頻IC架構(gòu)把模擬功能和處理信號所需的數(shù)字信號處理功能塊整合在一起。但是，蜂窩標準的復雜性要求作為一個整體的蜂窩芯片必須具備靈活性，特別是對射頻IC而言。靈活性即意味著可編程能力。

　　獨立射頻IC的輸入構(gòu)造一直是串行外設接口(SPI)映射。圖(a)通常的SPI映射架構(gòu)。本質(zhì)上，可將該SPI映射方法看作接入射頻IC的一個“開關”和“旋鈕”陣列，典型情況下有若干個使能位(開關)和工作參數(shù)(旋鈕)。以PLL為例，它一般至少有一個啟動PLL的使能位，還可能有若干確定PLL輸出頻率的調(diào)節(jié)參數(shù)。

　　當控制IC(通常是數(shù)字基帶)開始對PLL進行編程時，它必須編寫參數(shù)和使能位。在基于SPI映射的接口架構(gòu)中，DBB固件需了解它要編寫的每一比特的地址和位置。它還必須了解SPI的構(gòu)造以便能正確計算所需參數(shù)。有時，這些位彼此間會有時序方面的關聯(lián)，為確保計算結(jié)果正確，必須審慎對待這種關聯(lián)。

　　由于所需編程的比特數(shù)以千計。在某些場合，射頻IC的不同子系統(tǒng)間存在關聯(lián)，即便技術(shù)文檔寫得非常清楚，DBB固件開發(fā)團隊也可能無法很好理解。即使當DBB固件開發(fā)團隊成功地把一款射頻IC整合進芯片組后，DBB固件也就因此與射頻IC的特性有千絲萬縷的聯(lián)系。采用防御式和分層級式編程方法，仍會存留無法徹底抹去的痕跡。從商業(yè)角度看，這意味著對單一軟件構(gòu)造組件通過另外一個渠道進行外包幾乎行不通，因為這樣做就必須維護兩個軟件構(gòu)造。此外，后續(xù)的射頻IC將需要改進或升級，這樣寄存器將無法嚴格兼容，維護起來困難重重。

　　在軟件領域，解決這些問題的傳統(tǒng)方法是抽象(abstraction)。抽象一般意味著對其它實體用來完成任務的一些算法進行收集。別的實體不關心低級別實體如何完成任務，它只要求一切都在預期的參數(shù)內(nèi)運行。別軟件使用的低級別程序集被稱為應用編程接口(API)。

　　對抽象的期望在一定程度上把一個系統(tǒng)平臺內(nèi)的分布式IC維系在一起。增加的抽象層使得無需了解數(shù)字基帶的物理邏輯細節(jié)，取而代之的是簡單發(fā)布一個命令——“啟動接收器”。這個命令還采用有更詳細描述的語句：“啟動該通道的接收器，實施AFC校正，并根據(jù)預期的信號水平在天線端設置增益(如圖(b)所示)”。

　　圖：(a) SPI映射架構(gòu)；(b) IC之間的消息傳遞。

　　當然，通過API的抽象不會降低系統(tǒng)團隊需對相關部分的參數(shù)和功能運作條件進行了解的需求。像處理任何復雜系統(tǒng)一樣，了解各種使用環(huán)境及與層設計進行溝通都很關鍵。全面理解所需的操作將提供更完善的硬件，并有助于規(guī)避(或起碼控制)過度工程化(overengineering)。

　　一旦理解了相關的分布式IC使用環(huán)境，就能設計出魯棒的API。在軟件中，API由功能組成。對硬件API而言，類似的意圖可能是通過接口傳送至射頻IC的命令?？梢杂靡环N直接明了的方式，自上而下地處理命令定義和命令參數(shù)，這將覆蓋70~80%的所需功能。

　　射頻IC的任務是發(fā)射和接收，因此，對于多模蜂窩收發(fā)器，需要用來實現(xiàn)以下任務的命令：使能和/或去使能GSM接收器；使能和/或去使能GSM發(fā)射器；使能和/或去使能WCDMA接收器；使能和/或去使能WCDMA發(fā)射器。

　　這樣就可以開始搭建API的構(gòu)架。每個可能的命令都提供別的意圖。現(xiàn)在，每個命令都需要某類參數(shù)化處理，以使他們更加有用。每個命令的一些意圖包括：想要的通道數(shù)；現(xiàn)有帶寬(如果無法從通道數(shù)導出)；AFC校正(基于系統(tǒng)，如果射頻IC在AFC校正中起作用)。每個命令將有其特定參數(shù)。一些命令專用參數(shù)可能包括：發(fā)射功率水平、工作時隙以及功率測試要去。