邁向嵌入式系統的自診斷API
隨著嵌入式系統需求的增長和開發周期的縮小，開發人員越來越多地集成商業應用程序編程接口（API）或軟件工具的功能集合發布者提供在應用程序中使用該工具的功能。程序員選擇這些預先構建的庫，而不是手動編寫所需的功能。常見示例是通信，消息傳遞，數據庫和用戶界面庫。這些“中間件”API在便利性，可移植性，生產力和上市時間方面提供了諸多益處。但是，這些庫通常還存在引入破壞性和極難發現的編程錯誤的風險。這種風險源于商業API的實施方式。包含API的軟件功能幾乎總是數據結構無知。通過使用void指針在API庫和應用程序之間傳遞數據，他們處理數據而不“知道”他們運行的數據類型。

然而，創建API的潛力它捕獲了更廣泛的編程錯誤，并減少了API學習曲線的啟動，內置于C ++和C語言中。通過利用每個ANSI C/C ++編譯器的函數參數類型檢查能力，可以創建一個數據感知的編程接口，從而實現自診斷。 C/C ++作為首選的嵌入式系統開發環境不斷發展，因此基于環境固有功能的任何改進都具有廣泛的適用性。

數據管理通常是核心應用程序需求，以及許多商業數據庫API在解決嵌入式系統的性能和占用空間要求的同時，我們已經開始滿足這一需求。

從歷史上看，數據庫SDK已經為數據庫提供的服務提供了預定義的靜態編程接口。對于嵌入式系統，這些API中的大多數都是導航的，具有排序，存儲和檢索數據的功能，同時一次瀏覽數據庫的內容。開發人員必須學習這樣一個數據庫來完成一項任務，一般都是積極的，或者至少是中立的：雖然API提供了一個可以增加項目時間的學習曲線，但這種記憶在未來的項目中可能會有用。人們普遍期望這個API幾乎可以處理任何類型和組織的數據。

然而，一個重要的缺點是，對于預定義的數據庫函數庫來說，能夠管理任何數據庫定義的數據，接口必須忽略所有數據的類型。換句話說，數據庫編程接口必須將數據視為不透明或未鍵入的數據。簡單來說，數據庫庫無法知道公司，人員，網絡節點，傳感器，高速公路或任何其他特定類型的信息是從數據庫讀取還是寫入數據庫。編程接口只能知道正在寫入一些數據。

為了實現這一點，所有這些數據庫都使用void指針在數據庫庫和應用程序之間傳遞數據。 void指針是一個C/C ++語言程序變量，可以合法地指向任何類型的數據。無效指針是什么叫做un-typed？正如其名稱所暗示的那樣，它沒有類型。

沒有類型，C/C ++編譯器和數據庫運行時都不能對它們執行任何驗證。這開啟了編程錯誤的可能性，這些錯誤源于將指針傳遞給錯誤類型的數據。這種錯誤的后果包括數據庫中的無意義數據到損壞的（不可用的）數據庫到崩潰的程序。

編寫函數參數時出錯的結果將導致數據庫運行時放置將數據放入數據庫中不適合的位置（例如，將數據放入數據庫為模型數據指定的位置）。充其量，這會導致亂碼存儲在數據庫中。更糟糕的是，數據庫運行時可能會嘗試超出程序堆棧的末尾并導致內存沖突（即崩潰）。

從數據庫中讀取數據會帶來其他風險。嘗試將N字節寬的數據讀入一個小于N字節寬的程序變量將導致數據庫覆蓋內存中的隨機位置。關鍵數據可能會被覆蓋（例如程序調用堆棧），從而導致崩潰。重寫數據庫運行時結構也可能會被覆蓋并導致數據庫損壞。

引入錯誤有多容易？實際上，通過切割和粘貼代碼塊的省力實踐，這種錯誤很快就會進入代碼。任何與void指針相關的編輯錯誤，無論是傳遞指向錯誤主機程序變量的指針，還是傳遞指向已分配不足內存的指針，編譯器或中間件都無法檢測到。無論錯誤類型如何，使用void指針傳遞數據條C/C +編譯器和中間件運行時它們檢測錯誤的能力。糾正這些類型的錯誤的努力從最小到最大不等。

自我診斷API

創建更好的數據庫API的潛力？一個捕獲這樣的編程錯誤，并減少API學習曲線啟動？自從80年代首次將函數原型引入C和C ++以來，已經存在：通過利用每個ANSI C/C ++編譯器的函數參數類型檢查能力，創建一個數據感知的編程接口，從而實現自診斷。/p>

函數原型是函數的“簽名”。函數原型聲明函數的名稱，函數的參數（參數）數，每個參數的數據類型以及函數返回值的數據類型。如果函數的實際使用與其簽名不匹配，編譯器將發出錯誤消息，并且必須先糾正違規代碼，然后才能成功編譯程序。

利用現代ANSI C/C ++編譯器的函數原型設計功能要求我們放棄舊的想法，即數據庫編程接口必須是程序員學習的靜態函數庫，然后應用于每個可能的數據庫設計。相反，編程接口必須特定于每個數據庫設計，因此了解每個特定數據庫的數據類型。換句話說，填充模型記錄以強制要求程序員傳遞模型信息的數據庫函數的唯一方法是，該接口是從模型所參與的數據庫設計派生的，也是特定的。

McObject的eXtremeDB是一種用于嵌入式系統的內存數據庫系統（IMDS），它展示了如何將自診斷API應用于嵌入式系統中間件。 eXtremeDB有一個用于通用任務的小型靜態API（打開并建立與數據庫的連接，開始和結束事務等）。但是，大多數接口??關于填充，搜索和讀取數據庫定義中動態生成的數據的部分。

eXtremeDB數據庫用戶使用輸入到文本文件中的eXtremeDB數據庫定義語言（DDL）來描述數據庫。編譯器mcocomp處理此DDL，驗證其語法，如果沒有錯誤，則生成開發人員在其應用程序項目中包含的 .c和 .h文件。 .c和.h文件定義該唯一數據庫的編程接口。

在生成的文件中有函數原型（.h文件）和實現（.c文件）創建，搜索和讀取由數據庫設計者定義的每種類型的類和索引。每個接口都是針對特定數據元素和操作的特定用途的;因此，在接口定義中考慮了元素的類型。

eXtremeDB還建立在利用ANSI C函數原型的基礎上，提供了包含大量（和可配置）運行的數據庫庫的開發人員版本-time檢查函數原型無法檢測到的其他類型的編程錯誤，例如嘗試使用事務范圍之外的對象的句柄，或者使用無效的事務句柄。

直觀的界面可以在項目的開始階段提高程序員的工作效率，并延長軟件的使用壽命。與基于模糊靜態編程接口的非描述性代碼相比，進入項目的維護程序員發現閱讀和理解函數要容易得多。

為每個項目出現一個新界面，非常簡單的規則管理它的產生和使用。掌握生成和使用此類API的基礎知識可以提供比學習靜態中間件API的100到250個功能更強大，更靈活的“生活工具”。

作者：Steven T. Graves，總裁兼首席執行官，McObject LLC，Issaquah，WA

審核編輯 黃宇