在PC机上构建人机界面原型的方法和策略研究

在PC机上构建人机界面原型的方法和策略研究

构建一个人机界面原型能够帮助设计工程师在设计早期理解接口对设计的要求和接口的可用性。下面将探讨一种当目标硬件还远未实现时，在PC机上构建人机界面原型的方法。构建这类原型的主要目的有二。

1. 使同一个设计组中的其他成员能够看到该设备的工作过程。当我们在纸上设计一台交互式设备时，要判断设计中所描述的交互性能否实际实现，需要很大的想象力。而如果构建一个工作原型，就会使情况清晰许多，并且允许更多的旁观者来评论正在计划中的接口设计得怎样。很多时候，用接口原型进行试验，还能帮助设计工程师决定真正设计出的硬件需要多少按钮、多少LED、多少数字显示器或文本显示器。

在本例中，我们的目的是编写一个文本显示和LED控制的仿真软件，以表示PC机屏幕的变化。我们可以编写警戒检查代码和菜单控制代码，使其既能运行在PC机上，又能运行在目标设备上。

这种仿真的方法并不新颖。但在为诸如PDA和游戏机之类并没有自己的开发环境的目标设备上编写软件时，通常需要用到这种方法。

编写仿真软件所需的工具

如今有许多针对嵌入式开发的原型编写工具，用这些工具往往会迫使设计工程师依赖于它们的事件模型，从而导致设计过多地依赖这些工具。如果设计工程师遵从它们的接口设计风格，那么这些工具确实可以产生代码，但它们并不是对所有平台都具备足够的灵活度，而且它们产生的代码可能并不适合小型的微控制器。

我所采用的工具是Borland C++(后面将简写为CPB)。Borland C++并不是专门配合嵌入式系统的软件编写工具，但我发现它非常适合设计的需要，而且采用Borland C++不会将设计束缚在任何一个处理器或者任何一种软件结构上。

CPB中有一组预定义的图形组件，其中大多数并非针对嵌入式项目，而是针对桌面应用(类似下拉菜单)。但还是有一个小的子组件可用于我们本文所述的目的。象LED这样的UI元素就可以用图像来仿真。

CPB有三种版本：标准版、专业版和企业版。对于我们将要讨论的接口而言，标准版已经足够。

如果前面板是由一个工业设计小组设计的，那么就会有整个显示图像可供利用。或者如果物理原型已经存在，那么一幅该物理原型的数字相片就可以用来作为背景。

面板表格中包含了我们仿真时所用到的所有图形对象。Alarm-Indicator就是我们将一个标签放到面板表格上之后为其分配的名字。当我们将该标签通过拖拽到表格窗口中的方式加入该表格时，它就成为了该表格的一个数据成员。

现在来看一个setAlarmState()程序，该程序用于驱动基于CPB的仿真。以下代码为CPB专用代码，在最终的目标上无法运行。不用多久，我们将不得不为目标接口编写该函数的另一个版本，形式如下：

void setAlarmState(Boolean state)

{

if (state)

{

ledRegister |= 0x02;

}

else

{

ledRegister &= ~0x02;

}

}

代码的组织

如果我们已经编写了两个版本的setAlarm-State()函数，那么我们必须保证一次只编译其中的一个。要达到这一目的，一种方法是一直采用CPB代码，直到目标硬件设计好之后，再用目标专用的代码代替其中所有CPB专用的代码。如果我们这样做，那么在我们开始目标硬件的开发工作之后，就无法再运行仿真了。读者可能认为这不是什么问题，但事实上，即使硬件设计好之后，仿真也是有用的。

一旦开发者决定要在整个项目的开发周期中同时保留两个版本的函数，那么分隔它们就很容易。在CPB中的Project/Options下，可以定义宏。我通常会定义USING_CPB，然后在我的源代码中，利用一个#ifdef来区分不同的函数版本。另一种区分函数版本的方法就是将目标代码和仿真代码存放在不同的文件中，但让二者共享同一个头文件，以保证二者采用同样一组函数标记。

CPB环境是基于C++的一种环境，但许多嵌入式目标几乎都不支持C。这时，开发者只能采用共享代码中由交叉编译器所支持的C++子集，这其实并没有想象中的困难。解决该问题的方法之一就是针对嵌入式目标来编译代码，即使当前并没有硬件可以运行这些代码。这时那些在PC机上可用的而在目标硬件上则可能属于非法的特性就显得突出起来。例如，有些较小型的处理器就不支持递归。同时，在嵌入式编译器上检查软件，还能快速地在程序中标出那些偶然被包含进目标可执行文件中的CPB专用代码。我本人就发觉这种方法在跟踪软件的大小时非常有用，因为CPB库过于庞大，会完全扭曲程序的大小，所以PC机中进行编译时给出的软件大小并不真实。

这里采用了三种类型的代码。其中有些属于CPB专用代码，只能在PC机上编译;有些属于目标专用代码，只能在目标上编译;而其它的则属于公共代码，应该既能在PC机平台上运行，也能在目标平台上运行。在理想情况下，每个源文件应该都只包含一种类型的代码。设计工程师的IDE或makefile应允许其选择在每次创建可执行文件时需要包含哪些文件。

建议在命名文件时，将所有CPB专用的文件命名为.cpp文件，所有目标专用的文件和共享文件均取.c为扩展名。那么在目标环境中编译时，就只需编译扩展名为.c的文件，而不编译扩展名为.cpp的文件。

代码举例

读者可以在panelsoft.com/cpb 处找到一个可执行文件five.exe，文件中包含一行5个按钮和一组LED。按下前4个按钮中的任何一个都会打开相应的一个LED。第5个按钮是RESET(复位)按钮，按下该按钮会关断所有LED。 当然，在构造这样一个项目时，并不需要进行仿真。但该例旨在说明，只要具备初始的接口界面图象，那么仿真时，只需稍作努力就可得到与真实设备看起来相似的运行结果。同时，该例还说明，key.c模块中包含的代码既可在目标环境中运行，也可在仿真环境中运行，而且该代码不会因目标环境和仿真环境这两种平台之间的差异而需要任何条件代码才能运行。用于构造该应用的所有源代码和初始位图均可从该站点下载。

建立类似的仿真需要设计工程师具备一定的C++知识，学习CPB开发环境也需要一定的过程，当设计工程师从未用过这种面向对象的事件驱动环境时尤其如此。然而只要建立起一个仿真，那么其它工作只需按相同的步骤进行即可。设计工程师如果曾编写过基于PC的程序，而且程序中用到了GUI，那么这一经验会有助于对CPB的学习。我过去就曾利用这样一个程序来完成过一个简单的下载应用，实现与嵌入式目标的串行通信。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。