面向嵌入式系統(tǒng)的自診斷API

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

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

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

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

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

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

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

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

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

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

自我診斷API

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

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

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

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

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

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

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

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

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

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

審核編輯 黃宇