嵌入式系统的人机界面原型设计谋略.docx

《嵌入式系统的人机界面原型设计谋略.docx》由会员分享，可在线阅读，更多相关《嵌入式系统的人机界面原型设计谋略.docx（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、嵌入式系统的人机界面原型设计谋略lijing导语：对构建人机界面原型时所采用的工具语言和代码编写风格，和不同语言编写的文件之间的接口问题进展了分析在目的硬件完成之前实现对人机界面的仿真，需要设计工程师在PC机上用软件构建人机界面原型。本文针对构建人机界面原型时所采用的工具语言和代码编写风格，和不同语言编写的文件之间的接口问题进展了分析，对仿真设计人员有较好的指导作用。构建一个人机界面原型可以帮助设计工程师在设计早期理解接口对设计的要求和接口的可用性。下面将讨论一种当目的硬件还远未实现时，在PC机上构建人机界面原型的方法。构建这类原型的主要目的有二。1.使同一个设计组中的其他成员可以看到该设备的

2、工作经过。当我们在纸上设计一台交互式设备时，要判定设计中所描绘的交互性能否实际实现，需要很大的想象力。而假如构建一个工作原型，就会使情况明晰很多，并且允许更多的旁观者来评论正在方案中的接口设计得如何。很多时候，用接口原型进展试验，还能帮助设计工程师决定真正设计出的硬件需要多少按钮、多少LED、多少数字显示器或者文本显示器。2.当硬件没有工作时，利用接口原型来为人机界面编写软件。为到达这一目的，出如今PC显示器上的接口原型必须采用C、C+或其它适用于嵌入式开发的语言来控制。对于其它局部，那么可以假设C是用于最终目的硬件的语言。然后大概考虑一下需要仿真的是哪局部软件。在最简单的情况下，软件可用来翻

3、开或者关闭一个LED，或向一个小型字符显示器输出一个字符串。控制人机界面上的物理元件只是一项很普通的功能，所以可以在PC机上编写这种软件的优点是微缺乏道的。由于开关一个LED可能只需要一行代码，在一个LCD文本显示器上显示一个文本字符串也只需要调用一个10行或者20行的函数。真正困难的是怎样编写软件来决定终究是翻开LED还是关闭LED，和决定显示什么字符串。例如，当一个被测传感器的值持续超过戒备线一段时间，而一组使戒备有效的条件也知足了之后，软件也许应选择翻开LED。再如，当用户按下一个按钮来选择菜单中的下一项时，软件也许应查阅一个描绘该菜单的字符串表和操纵表，以决定下一个显示的应该是哪一项。

4、这种控制菜单之类的软件，其代码长度就会超过底层软件。在本例中，我们的目的是编写一个文本显示和LED控制的仿真软件，以表示PC机屏幕的变化。我们可以编写戒备检查代码和菜单控制代码，使其既能运行在PC机上，又能运行在目的设备上。这种仿真的方法并不新奇。但在为诸如PDA和游戏机之类并没有自己的开发环境的目的设备上编写软件时，通常需要用到这种方法。编写仿真软件所需的工具用VisualBasic在PC机上显示几个按钮和两行文本并不困难，但当将该原型与C代码接口时，就会显得特别费事。如今有很多针对嵌入式开发的原型编写工具，用这些工具往往会迫使设计工程师依靠于它们的事件模型，进而导致设计太多地依靠这些工具。

5、假如设计工程师遵从它们的接口设计风格，那么这些工具确实可以产生代码，但它们并不是对所有平台都具备足够的灵敏度，而且它们产生的代码可能并不合适小型的微控制器。我所采用的工具是BorlandC+后面将简写为CPB。BorlandC+并不是专门配合嵌入式系统的软件编写工具，但我发现它非常合适设计的需要，而且采用BorlandC+不会将设计束缚在任何一个处理器或任何一种软件构造上。CPB中有一组预定义的图形组件，其中大多数并非针对嵌入式工程，而是针对桌面应用类似下拉菜单。但还是有一个小的子组件可用于我们本文所述的目的。象LED这样的UI元素就可以用图像来仿真。CPB有三种版本：标准版、专业版和企业版。

6、对于我们将要讨论的接口而言，标准版已经足够。按钮、滑动块、标签和其它UI元素均可通过drag-and-drop环境插入一个表格一个简单的对话窗口中去。产生一个这样的表格就会生成一个C+类的框架。例如，每当用户点击一个图像或者挪动一个滑动块时，都会产生一组事件，而该表格中的每个元素都有这样一组事件与其对应。终究需要对哪些事件作出反映那么由程序员来选择。这些响应就被写成该表格所产生的类的成员函数。假如前面板是由一个工业设计小组设计的，那么就会有整个显示图像可供利用。或假如物理原型已经存在，那么一幅该物理原型的数字相片就可以用来作为背景。我采用图像目的在CPB内也叫作Timage来显示大多数物理元件

7、。由于采用了图像目的就可以引入位图，然后进展显示。例如可以引入一个发光二极管的图像。在该应用中，显示了一个包含5个按钮和4个LED的接口原图，如图1所示。背景图像中LED处于关断状态。一旦软件决定其中的一个LED应翻开，那么这个发光LED图像的可见属性就被设为真，于是点亮的LED的图像就覆盖了不亮的LED图像。有了这种简单的重叠多幅图像的窍门，我们就可以仿真一个物理显示屏的其它局部。例如，假设我们采用CPBIDE来创立一个包含单词“ALARM的标注，并将这一元素命名为AlarmIndicator，那么我们就可以编写一个函数来控制它：voidsetAlarmStateBooleanstatePa

8、nelForm-AlarmIndicator-Visible=state;面板表格中包含了我们仿真时所用到的所有图形对象。Alarm-Indicator就是我们将一个标签放到面板表格上之后为其分配的名字。当我们将该标签通过拖拽到表格窗口中的方式参加该表格时，它就成为了该表格的一个数据成员。在CPB中，显示屏上的一个元素的所有属性都可以作为表征该元素的类的公共数据成员。因此，Visible属性只需进展一个简单的分配操纵就能改变。公共数据成员可以在程序中的任何地方通过分配而改变。在CPB中，各属性也有其特殊状态，允许在IDE中通过该状态改变属性。开发者可以点击一个标注，并在属性窗口设置Visibl

9、e属性。显示的颜色和字体可以以通过类似的方法改变。如今来看一个setAlarmState程序，该程序用于驱动基于CPB的仿真。以下代码为CPB专用代码，在最终的目的上无法运行。不用多久，我们将不得不为目的接口编写该函数的另一个版本，形式如下：voidsetAlarmStateBooleanstateifstateledRegister|=0x02;elseledRegister&=0x02;有时，编程的风格会导致一些小函数造成函数调用开销。在较小的系统中这一问题较受关注，而这些函数中有一些可以写成宏或内联inline函数。我通常只在工程的最后阶段才开场进展这类优化。代码的组织假如我们已经编写了

10、两个版本的setAlarm-State函数，那么我们必须保证一次只编译其中的一个。要到达这一目的，一种方法是一直采用CPB代码，直到目的硬件设计好之后，再用目的专用的代码代替其中所有CPB专用的代码。假如我们这样做，那么在我们开场目的硬件的开发工作之后，就无法再运行仿真了。读者可能以为这不是什么问题，但事实上，即使硬件设计好之后，仿真也是有用的。例如，仿真中基于PC的调试环境往往就比目的硬件的开发环境要好。由于目的硬件的下载速度可能较慢，或每次修改软件都必须重新烧录一块一次性可编程芯片。而且目的硬件的调试环境中可能也不支持单步调试和断点调试。即使目的硬件的调试环境较好，相对而言，PC仿真还是有

11、其它上风。开发者可以将.exe文件通过电子邮件发送给不在同一工作地点的工作伙伴，以获得他们的反应信息。一旦开发者决定要在整个工程的开发周期中同时保存两个版本的函数，那么分隔它们就很轻易。在CPB中的Project/Options下，可以定义宏。我通常会定义USING_CPB，然后在我的源代码中，利用一个#ifdef来区分不同的函数版本。另一种区分函数版本的方法就是将目的代码和仿真代码存放在不同的文件中，但让二者分享同一个头文件，以保证二者采用同样一组函数标记。CPB环境是基于C+的一种环境，但很多嵌入式目的几乎都不支持C。这时，开发者只能采用分享代码中由穿插编译器所支持的C+子集，这其实并没有

12、想象中的困难。解决该问题的方法之一就是针对嵌入式目的来编译代码，即使当前并没有硬件可以运行这些代码。这时那些在PC机上可用的而在目的硬件上那么可能属于非法的特性就显得突出起来。例如，有些较小型的处理器就不支持递归。同时，在嵌入式编译器上检查软件，还能快速地在程序中标出那些偶尔被包含进目的可执行文件中的CPB专用代码。我本人就觉察这种方法在跟踪软件的大小时非常有用，由于CPB库过于庞大，会完全扭曲程序的大小，所以PC机中进展编译时给出的软件大小并不真实。这里采用了三种类型的代码。其中有些属于CPB专用代码，只能在PC机上编译；有些属于目的专用代码，只能在目的上编译；而其它的那么属于公共代码，应该

13、既能在PC机平台上运行，也能在目的平台上运行。在理想情况下，每个源文件应该都只包含一种类型的代码。设计工程师的IDE或者makefile应允许其选择在每次创立可执行文件时需要包含哪些文件。建议在命名文件时，将所有CPB专用的文件命名为.cpp文件，所有目的专用的文件和分享文件均取.c为扩展名。那么在目的环境中编译时，就只需编译扩展名为.c的文件，而不编译扩展名为.cpp的文件。假如设计工程师遵循以上风格，那么在CPB环境中编译时还会碰到一个问题。CPB环境将.c文件假设为C代码编写的文件，而将.cpp文件假设为C+代码编写的文件。当从一个文件到另一个文件发生调用时，将会因C+产生破损函数名的方

14、式不同而产生链接错误。我们可以通过采用“externC构造往返避这个问题。但这样有点费事，尤其当调用发生在从C到C+或者从C+到C时。可以为Borland编译器设置一个标志，告诉它，不管文件名的后缀是什么，均将其作为C+文件来编译。遗憾的是IDE中没有这样的标志。于是我们只能手工编辑工程配置文件来实现这一功能。代码举例读者可以在panelsoft/cpb处找到一个可执行文件five.exe，文件中包含一行5个按钮和一组LED。按下前4个按钮中的任何一个都会翻开相应的一个LED。第5个按钮是RESET复位按钮，按下该按钮会关断所有LED。当然，在构造这样一个工程时，并不需要进展仿真。但该例旨在讲

15、明，只要具备初始的接口界面图象，那么仿真时，只需稍作努力就可得到与真实设备看起来相似的运行结果。同时，该例还讲明，key.c模块中包含的代码既可在目的环境中运行，可以在仿真环境中运行，而且该代码不会因目的环境和仿真环境这两种平台之间的差异而需要任何条件代码才能运行。用于构造该应用的所有源代码和初始位图均可从该站点下载。建立类似的仿真需要设计工程师具备一定的C+知识，学习CPB开发环境也需要一定的经过，当设计工程师从未用过这种面向对象的事件驱动环境时尤其如此。然而只要建立起一个仿真，那么其它工作只需按一样的步骤进展即可。设计工程师假如曾编写过基于PC的程序，而且程序中用到了GUI，那么这一经历会有助于对CPB的学习。我过去就曾利用这样一个程序来完成过一个简单的下载应用，实现与嵌入式目的的串行通讯。