構建一個人機界面原型能夠幫助設計工程師在設計早期理解接口對設計的要求和接口的可用性。下面將探討一種當目標硬件還遠未實現時，在PC機上構建人機界面原型的方法。構建這類原型的主要目的有二。

1. 使同一個設計組中的其他成員能夠看到該設備的工作過程。當我們在紙上設計一臺交互式設備時，要判斷設計中所描述的交互性能否實際實現，需要很大的想象力。而如果構建一個工作原型，就會使情況清晰許多，并且允許更多的旁觀者來評論正在計劃中的接口設計得怎樣。很多時候，用接口原型進行試驗，還能幫助設計工程師決定真正設計出的硬件需要多少按鈕、多少LED、多少數字顯示器或文本顯示器。

2. 當硬件沒有工作時，利用接口原型來為人機界面編寫軟件。為達到這一目的，出現在PC顯示器上的接口原型必須采用C、C++或者其它適用于嵌入式開發的語言來控制 。對于其它部分，則可以假設C是用于最終目標硬件的語言。

然后大概考慮一下需要仿真的是哪部分軟件。在最簡單的情況下，軟件可用來打開或關閉一個LED，或者向一個小型字符顯示器輸出一個字符串。控制人機界面上的物理元件只是一項很普通的功能，所以能夠在PC機上編寫這種軟件的優點是微不足道的。因為開關一個LED可能只需要一行代碼，在一個LCD文本顯示器上顯示一個文本字符串也只需要調用一個10行或20行的函數。

真正困難的是如何編寫軟件來決定究竟是打開LED還是關閉LED，以及決定顯示什么字符串。例如，當一個被測傳感器的值持續超過警戒線一段時間，而一組使警戒有效的條件也滿足了之后，軟件也許應選擇打開LED。再如，當用戶按下一個按鈕來選擇菜單中的下一項時，軟件也許應查閱一個描述該菜單的字符串表和操作表，以決定下一個顯示的應該是哪一項。這種控制菜單之類的軟件，其代碼長度就會超過底層軟件。

在本例中，我們的目的是編寫一個文本顯示和LED控制的仿真軟件，以表示PC機屏幕的變化。我們可以編寫警戒檢查代碼和菜單控制代碼，使其既能運行在PC機上，又能運行在目標設備上。

這種仿真的方法并不新穎。但在為諸如PDA和游戲機之類并沒有自己的開發環境的目標設備上編寫軟件時，通常需要用到這種方法。

編寫仿真軟件所需的工具

用Visual Basic在PC機上顯示幾個按鈕和兩行文本并不困難，但當將該原型與C代碼接口時，就會顯得十分麻煩。

如今有許多針對嵌入式開發的原型編寫工具，用這些工具往往會迫使設計工程師依賴于它們的事件模型，從而導致設計過多地依賴這些工具。如果設計工程師遵從它們的接口設計風格，那么這些工具確實可以產生代碼，但它們并不是對所有平臺都具備足夠的靈活度，而且它們產生的代碼可能并不適合小型的微控制器。

我所采用的工具是Borland C++(后面將簡寫為CPB)。Borland C++并不是專門配合嵌入式系統的軟件編寫工具，但我發現它非常適合設計的需要，而且采用Borland C++不會將設計束縛在任何一個處理器或者任何一種軟件結構上。

CPB中有一組預定義的圖形組件，其中大多數并非針對嵌入式項目，而是針對桌面應用(類似下拉菜單)。但還是有一個小的子組件可用于我們本文所述的目的。象LED這樣的UI元素就可以用圖像來仿真。

CPB有三種版本：標準版、專業版和企業版。對于我們將要討論的接口而言，標準版已經足夠。

按鈕、滑動塊、標簽和其它UI元素均可通過drag-and-drop環境插入一個表格(一個簡單的對話窗口)中去。產生一個這樣的表格就會生成一個C++類的框架。例如，每當用戶點擊一個圖像或移動一個滑動塊時，都會產生一組事件，而該表格中的每個元素都有這樣一組事件與其對應。究竟需要對哪些事件作出反映則由程序員來選擇。這些響應就被寫成該表格所產生的類的成員函數。

如果前面板是由一個工業設計小組設計的，那么就會有整個顯示圖像可供利用。或者如果物理原型已經存在，那么一幅該物理原型的數字相片就可以用來作為背景。

我采用圖像目標(在CPB內也叫作Timage)來顯示大多數物理元件。因為采用了圖像目標就可以引入位圖，然后進行顯示。例如可以引入一個發光二極管的圖像。在該應用中，顯示了一個包含5個按鈕和4個LED的接口原圖，如圖1所示。背景圖像中LED處于關斷狀態。一旦軟件決定其中的一個LED應打開，那么這個發光LED圖像的可見屬性就被設為真，于是點亮的LED的圖像就覆蓋了不亮的LED圖像。

有了這種簡單的重疊多幅圖像的訣竅，我們就可以仿真一個物理顯示屏的其它部分。例如，假設我們采用CPB IDE來創建一個包含單詞“ALARM”的標注，并將這一元素命名為AlarmIndicator，那么我們就可以編寫一個函數來控制它：

面板表格中包含了我們仿真時所用到的所有圖形對象。Alarm-Indicator就是我們將一個標簽放到面板表格上之后為其分配的名字。當我們將該標簽通過拖拽到表格窗口中的方式加入該表格時，它就成為了該表格的一個數據成員。

在CPB中，顯示屏上的一個元素的所有屬性都可以作為表征該元素的類的公共數據成員。因此，Visible屬性只需進行一個簡單的分配操作就能改變。公共數據成員可以在程序中的任何地方通過分配而改變。在CPB中，各屬性也有其特殊狀態，允許在IDE中通過該狀態改變屬性。開發者可以點擊一個標注，并在屬性窗口設置Visible屬性。顯示的顏色和字體也可以通過類似的方法改變。

現在來看一個setAlarmState()程序，該程序用于驅動基于CPB的仿真。以下代碼為CPB專用代碼，在最終的目標上無法運行。不用多久，我們將不得不為目標接口編寫該函數的另一個版本，形式如下：

void setAlarmState(Boolean state)

{

if (state)

{

ledRegister |= 0x02;

}

else

{

ledRegister &= ~0x02;

}

}

有時，編程的風格會導致一些小函數造成函數調用開銷。在較小的系統中這一問題較受關注，而這些函數中有一些可以寫成宏或者內聯(inline)函數。我通常只在項目的最后階段才開始進行這類優化。

代碼的組織

如果我們已經編寫了兩個版本的setAlarm-State()函數，那么我們必須保證一次只編譯其中的一個。要達到這一目的，一種方法是一直采用CPB代碼，直到目標硬件設計好之后，再用目標專用的代碼代替其中所有CPB專用的代碼。如果我們這樣做，那么在我們開始目標硬件的開發工作之后，就無法再運行仿真了。讀者可能認為這不是什么問題，但事實上，即使硬件設計好之后，仿真也是有用的。

例如，仿真中基于PC的調試環境往往就比目標硬件的開發環境要好。因為目標硬件的下載速度可能較慢，或者每次修改軟件都必須重新燒錄一塊一次性可編程芯片。而且目標硬件的調試環境中可能也不支持單步調試和斷點調試。即使目標硬件的調試環境較好，相對而言，PC仿真還是有其它優勢。開發者可以將.exe文件通過電子郵件發送給不在同一工作地點的工作伙伴，以獲得他們的反饋信息。

一旦開發者決定要在整個項目的開發周期中同時保留兩個版本的函數，那么分隔它們就很容易。在CPB中的Project/Options下，可以定義宏。我通常會定義USING_CPB，然后在我的源代碼中，利用一個#ifdef來區分不同的函數版本。另一種區分函數版本的方法就是將目標代碼和仿真代碼存放在不同的文件中，但讓二者共享同一個頭文件，以保證二者采用同樣一組函數標記。

CPB環境是基于C++的一種環境，但許多嵌入式目標幾乎都不支持C。這時，開發者只能采用共享代碼中由交叉編譯器所支持的C++子集，這其實并沒有想象中的困難。解決該問題的方法之一就是針對嵌入式目標來編譯代碼，即使當前并沒有硬件可以運行這些代碼。這時那些在PC機上可用的而在目標硬件上則可能屬于非法的特性就顯得突出起來。例如，有些較小型的處理器就不支持遞歸。同時，在嵌入式編譯器上檢查軟件，還能快速地在程序中標出那些偶然被包含進目標可執行文件中的CPB專用代碼。我本人就發覺這種方法在跟蹤軟件的大小時非常有用，因為CPB庫過于龐大，會完全扭曲程序的大小，所以PC機中進行編譯時給出的軟件大小并不真實。

這里采用了三種類型的代碼。其中有些屬于CPB專用代碼，只能在PC機上編譯;有些屬于目標專用代碼，只能在目標上編譯;而其它的則屬于公共代碼，應該既能在PC機平臺上運行，也能在目標平臺上運行。在理想情況下，每個源文件應該都只包含一種類型的代碼。設計工程師的IDE或makefile應允許其選擇在每次創建可執行文件時需要包含哪些文件。

建議在命名文件時，將所有CPB專用的文件命名為.cpp文件，所有目標專用的文件和共享文件均取.c為擴展名。那么在目標環境中編譯時，就只需編譯擴展名為.c的文件，而不編譯擴展名為.cpp的文件。

如果設計工程師遵循以上風格，那么在CPB環境中編譯時還會遇到一個問題。CPB環境將.c文件假設為C代碼編寫的文件，而將.cpp文件假設為C++代碼編寫的文件。當從一個文件到另一個文件發生調用時，將會因 C++產生破損函數名的方式不同而產生鏈接錯誤。我們可以通過采用“extern C”構造來回避這個問題。但這樣有點麻煩，尤其當調用發生在從C到C++或從C++到C時。可以為Borland編譯器設置一個標志，告訴它，不論文件名的后綴是什么，均將其作為C++文件來編譯。遺憾的是IDE中沒有這樣的標志。于是我們只能手工編輯項目配置文件來實現這一功能。

代碼舉例

讀者可以在www.panelsoft.com/cpb 處找到一個可執行文件five.exe，文件中包含一行5個按鈕和一組LED。按下前4個按鈕中的任何一個都會打開相應的一個LED。第5個按鈕是RESET(復位)按鈕，按下該按鈕會關斷所有LED。 當然，在構造這樣一個項目時，并不需要進行仿真。但該例旨在說明，只要具備初始的接口界面圖象，那么仿真時，只需稍作努力就可得到與真實設備看起來相似的運行結果。同時，該例還說明，key.c模塊中包含的代碼既可在目標環境中運行，也可在仿真環境中運行，而且該代碼不會因目標環境和仿真環境這兩種平臺之間的差異而需要任何條件代碼才能運行。用于構造該應用的所有源代碼和初始位圖均可從該站點下載。

建立類似的仿真需要設計工程師具備一定的C++知識，學習CPB開發環境也需要一定的過程，當設計工程師從未用過這種面向對象的事件驅動環境時尤其如此。然而只要建立起一個仿真，那么其它工作只需按相同的步驟進行即可。設計工程師如果曾編寫過基于PC的程序，而且程序中用到了GUI，那么這一經驗會有助于對CPB的學習。我過去就曾利用這樣一個程序來完成過一個簡單的下載應用，實現與嵌入式目標的串行通信。

責任編輯：gt