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

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

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

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

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

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

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

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

從數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)會(huì)帶來其他風(fēng)險(xiǎn)。嘗試將N字節(jié)寬的數(shù)據(jù)讀入一個(gè)小于N字節(jié)寬的程序變量將導(dǎo)致數(shù)據(jù)庫(kù)覆蓋內(nèi)存中的隨機(jī)位置。關(guān)鍵數(shù)據(jù)可能會(huì)被覆蓋（例如程序調(diào)用堆棧），從而導(dǎo)致崩潰。重寫數(shù)據(jù)庫(kù)運(yùn)行時(shí)結(jié)構(gòu)也可能會(huì)被覆蓋并導(dǎo)致數(shù)據(jù)庫(kù)損壞。

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

自我診斷API

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

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

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

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

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

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

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

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

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

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

審核編輯 黃宇