|
隨著手機內RF芯片的集成度不斷增加，編程需求也在顯著增加。但另一方面，手機生命周期在日益縮短。解決復雜性增加和生命周期縮短之間的矛盾的一個方法是采用“硬件”應用編程接口(API)。本文討論開發API時應遵循的一些規則以及應避免的一些設計陷阱。 射頻IC的主要工作是調制與解調發射數據并接收想要的信號。隨著數字信號處理技術的出現，越來越多的射頻IC架構把模擬功能和處理信號所需的數字信號處理功能塊整合在一起。但是，蜂窩標準的復雜性要求作為一個整體的蜂窩芯片必須具備靈活性，特別是對射頻IC而言。靈活性即意味著可編程能力。 獨立射頻IC的輸入構造一直是串行外設接口(SPI)映射。圖(a)通常的SPI映射架構。本質上，可將該SPI映射方法看作接入射頻IC的一個“開關”和“旋鈕”陣列，典型情況下有若干個使能位(開關)和工作參數(旋鈕)。以PLL為例，它一般至少有一個啟動PLL的使能位，還可能有若干確定PLL輸出頻率的調節參數。 當控制IC(通常是數字基帶)開始對PLL進行編程時，它必須編寫參數和使能位。在基于SPI映射的接口架構中，DBB固件需了解它要編寫的每一比特的地址和位置。它還必須了解SPI的構造以便能正確計算所需參數。有時，這些位彼此間會有時序方面的關聯，為確保計算結果正確，必須審慎對待這種關聯。 由于所需編程的比特數以千計。在某些場合，射頻IC的不同子系統間存在關聯，即便技術文檔寫得非常清楚，DBB固件開發團隊也可能無法很好理解。即使當DBB固件開發團隊成功地把一款射頻IC整合進芯片組后，DBB固件也就因此與射頻IC的特性有千絲萬縷的聯系。采用防御式和分層級式編程方法，仍會存留無法徹底抹去的痕跡。從商業角度看，這意味著對單一軟件構造組件通過另外一個渠道進行外包幾乎行不通，因為這樣做就必須維護兩個軟件構造。此外，后續的射頻IC將需要改進或升級，這樣寄存器將無法嚴格兼容，維護起來困難重重。 在軟件領域，解決這些問題的傳統方法是抽象(abstraction)。抽象一般意味著對其它實體用來完成任務的一些算法進行收集。高級別的實體不關心低級別實體如何完成任務，它只要求一切都在預期的參數內運行。高級別軟件使用的低級別程序集被稱為應用編程接口(API)。 對抽象的期望在一定程度上把一個系統平臺內的分布式IC維系在一起。增加的抽象層使得無需了解數字基帶的物理邏輯細節，取而代之的是簡單發布一個命令——“啟動接收器”。這個命令還采用有更詳細描述的語句：“啟動該通道的接收器，實施AFC校正，并根據預期的信號水平在天線端設置增益(如圖(b)所示)”。 圖：(a) SPI映射架構；(b) IC之間的消息傳遞。 當然，通過API的抽象不會降低系統團隊需對相關部分的參數和功能運作條件進行了解的需求。像處理任何復雜系統一樣，了解各種使用環境及與最底層設計進行溝通都很關鍵。全面理解所需的操作將提供更完善的硬件，并有助于規避(或最起碼控制)過度工程化(overengineering)。 一旦理解了相關的分布式IC使用環境，就能設計出魯棒的API。在軟件中，API由功能組成。對硬件API而言，類似的意圖可能是通過接口傳送至射頻IC的命令。可以用一種直接明了的方式，自上而下地處理命令定義和命令參數，這將覆蓋70"80%的所需功能。 射頻IC的任務是發射和接收，因此，對于多模蜂窩收發器，需要用來實現以下任務的命令：使能和/或去使能GSM接收器；使能和/或去使能GSM發射器；使能和/或去使能WCDMA接收器；使能和/或去使能WCDMA發射器。 這樣就可以開始搭建API的構架。每個可能的命令都提供高級別的意圖。現在，每個命令都需要某類參數化處理，以使他們更加有用。每個命令的一些意圖包括：想要的通道數；現有帶寬(如果無法從通道數導出)；AFC校正(基于系統，如果射頻IC在AFC校正中起作用)。每個命令將有其特定參數。一些命令專用參數可能包括：發射功率水平、工作時隙以及功率測試要去。 |
