嵌入式軟件開發(fā)人員已經(jīng)習慣于在基于微控制器的系統(tǒng)中工作在最低的、基本的硬件級別。擺弄和操縱位和字節(jié)是嵌入式軟件開發(fā)人員天生要做的事情。嵌入式軟件行業(yè)正在發(fā)生變化，這種變化要求嵌入式開發(fā)人員開始在更高的抽象層次上工作，這需要設(shè)計和創(chuàng)建 API(應用程序編程接口)來允許軟件被重用。讓我們來看看開發(fā)優(yōu)秀 API 的七個技巧。

　　1. 讓它成為一個迭代過程

　　在設(shè)計 API 或 HAL(硬件抽象層)時，不要假設(shè)第一次一切都會順利。沒有一個 API 可以統(tǒng)治所有這些，并且期望創(chuàng)建這樣的 API，尤其是在一次嘗試時，是一種失敗的設(shè)置。相反，從一個 API  草案開始，期望它在未來的迭代中會略有改變。通常在三個或四個項目的過程中，API 將穩(wěn)定到進一步變化很小甚至不存在的程度。

　　2. 檢查多個微控制器數(shù)據(jù)表

　　如果計劃是創(chuàng)建一個可在多個微控制器供應商之間使用的 API，開發(fā)人員必須查看的不僅僅是一個微控制器數(shù)據(jù)表。開發(fā)人員應該為多個微控制器檢查相同的外設(shè)，并列出所有常見和不常見的功能。通用功能應該被匯總到 API 中，因為它們無疑是行業(yè)標準功能，而不常見的功能只有在需要這些功能時才能在 API 擴展中實現(xiàn)。

　　3. 每個模塊使用不超過 10 個接口

　　人類的大腦只能始終如一地記住大約 10 到 12 條屬于一起的信息。嵌入式開發(fā)人員的目標應該是保持他們的 API 不超過大約 10 個接口。遠遠超出這個數(shù)字會讓人難以記住調(diào)用，還會使界面看起來很復雜，甚至可能會混淆理解。尋找使用控制和配置結(jié)構(gòu)重構(gòu)接口的方法。

　　4. 測試前置條件和后置條件

　　一個出色的 API 實現(xiàn)不會假設(shè)調(diào)用函數(shù)或應用程序已經(jīng)完成了它應該為函數(shù)正常工作的所有事情。開發(fā)人員應在 API 中使用斷言來測試是否滿足所有前置條件，甚至測試后置條件以確保 API 已成功執(zhí)行其功能。不要像許多開發(fā)人員那樣假設(shè)一切都已正確設(shè)置并且將正確執(zhí)行。防御性地設(shè)計和實現(xiàn)接口。

　　5. 邏輯命名約定

　　一個優(yōu)秀的 API 將具有邏輯命名約定，使開發(fā)人員能夠輕松識別和調(diào)用 API 接口。在 API 的前面使用神秘的字母通常會讓開發(fā)人員摸不著頭腦并質(zhì)疑該符號的含義。在命名約定中明確并遵循最佳實踐建議，例如從通用開始命名約定并朝著特定方向努力。

　　6.提供擴展接口的方法

　　目標是創(chuàng)建一個易于理解和使用的簡潔界面，同時包含開發(fā)人員在開發(fā)過程中需要的最常見元素。有時，嵌入式開發(fā)人員可能希望在微控制器中使用一些不常見的功能，例如每個微控制器可能沒有的 GPIO 硬件去抖動。在這些情況下，開發(fā)人員將希望確保他們的 API 中內(nèi)置了一種機制，允許擴展接口。這可以通過允許指向新接口結(jié)構(gòu)的指針或通過創(chuàng)建對 API 的寄存器訪問來實現(xiàn)，以允許創(chuàng)建低級操作和更高級別的接口。

　　7. 在 API 中構(gòu)建中斷處理

　　為了確保正確處理中斷，API 開發(fā)人員可以更輕松地處理 API 內(nèi)部的中斷，從而使中斷對 API 用戶來說是一個黑匣子。這意味著需要有一種機制用于將函數(shù)分配給更高級別的應用程序代碼中的中斷處理程序。一種方法是將回調(diào)注冊添加到 API 中，以便可以在應用程序代碼中為中斷分配其可執(zhí)行代碼。這允許 API 確保正確處理中斷，但也允許開發(fā)人員使用他們自己的自定義代碼覆蓋這些默認值。

　　結(jié)論

　　如果開發(fā)人員想要降低成本和縮短上市時間，現(xiàn)在幾乎需要開發(fā) API 和 HAL。微控制器已達到與早期 x86 微處理器相當?shù)膹碗s性、性能和功能水平。在當今系統(tǒng)如此復雜的情況下，必須設(shè)計 API 以最大限度地重用代碼。這七個技巧應該可以幫助希望重用自己的代碼的嵌入式開發(fā)人員更有能力開發(fā)自己的 API 和 HAL。