7
西门子模块6ES7322-1HF10-0AA0技术参数
在目标硬件完成之前实现对人机界面的,需要设计工程师在PC机上用软件构建机界面原型。本文针对构建机界面原型时所采用的工具语言和代码编写风格,以及不同语言编写的文件之间的接口问题进行了分析,对设计人员有较好的指导作用。
构建一个机界面原型能够帮助设计工程师在设计早期理解接口对设计的要求和接口的可用性。下面将探讨一种当目标硬件还远未实现时,在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,那么我们就可以编写一个函数来控制它:
void setAlarmState(Boolean state)
{
Panelbbbb->AlarmIndicator
->Visible = state;
}
面板表格中包含了我们时所用到的所有图形对象。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./cpb 处找到一个可执行文件five.exe,文件中包含一行5个按钮和一组LED。按下前4个按钮中的任何一个都会打开相应的一个LED。*5个按钮是RESET(复位)按钮,按下该按钮会关断所有LED。 当然,在构造这样一个项目时,并不需要进行。但该例旨在说明,只要具备初始的接口界面图象,那么时,只需稍作努力就可得到与真实设备看起来相似的运行结果。同时,该例还说明,key.c模块中包含的代码既可在目标环境中运行,也可在环境中运行,而且该代码不会因目标环境和环境这两种平台之间的差异而需要任何条件代码才能运行。用于构造该应用的所有源代码和初始位图均可从该站点下载。
建立类似的需要设计工程师具备一定的C++知识,学习CPB开发环境也需要一定的过程,当设计工程师**用过这种面向对象的事件驱动环境时尤其如此。然而只要建立起一个,那么其它工作只需按相同的步骤进行即可。设计工程师如果曾编写过基于PC的程序,而且程序中用到了GUI,那么这一经验会有助于对CPB的学习。我过去就曾利用这样一个程序来完成过一个简单的下载应用,实现与嵌入式目标的串行通信。



在计算机软件技术中,人机界面已经发展成为一个重要的分支。在MIS开发中,人机界面的重要性尤为**。笔者根据多年从事MIS开发的经验,浅谈一下MIS类软件人机界面设计时应遵循的原则。
一、 前言
随着计算机软硬件技术的发展,人机界面的重要性与日俱增。一些*指出:对于用户,人机界面就是系统本身。在计算机发展的早期,受计算速度、存储容量等条件的限制,用户一味追求运行速度与所占空间,致使程序员在开发软件时不得不绞尽脑汁,考虑如何使所开发的软件运行速度快、占用内存/外存小,故程序员在开发软件时无不把主要精力放在软件内部算法与数据结构上。
然而时过境迁,硬件技术的飞速发展,使计算速度与存储容量不再成为软件开发所担心的问题,用户关心的主要问题是能否比较容易地使用软件。换言之,人们的着眼点在于软件的易用性,而易用与否主要取决于人机界面的优劣。众所周知,在当今的硬件与软件环境下,一个MIS软件没有很好的界面设计就不能算是成功。因为不管它内部有多么精巧的技术,只要用户不愿意使用它,它的优越性就得不到发挥,它的价值和作用也无从谈起。
正因如此,人机界面研究已经从过去的从属地位上升为一个专门的领域,国内外均有很多学者从事这方面的研究。bbbbbbs操作系统的日臻完善,更给人机界面技术以强有力的支持。
二、 MIS人机界面设计的基本原则
1、 以通信功能作为界面设计的核心
人机界面的关键是使人与计算机之间能够准确地交流信息。一方面,人向机器输入时应当尽量采取自然的方式;另一方面,机器向人传递的信息必须准确,不致引起误解或混乱。另外,不要把内部的处理、加工与人机界面混在一起(人机界面程序只是通信),以免互相干扰,影响速度。
MIS设计时,针对每一个功能,都要按照I-P-O的模块化思想,使输入、处理与输出泾渭分明,充分体现人机界面的通信功能。这样设计出来的程序不但不易出错,而且易于维护,即使有了错误也很容易加以改正。
报表打印是MIS*的功能之一,而且打印之前常常需要计算。毕其功于一役并非明智之举。尽管这样做或许会节省一些运行时间,但对以后的维护较为不利。计算与打印分开设计,固然会增加一些时空开销,但考虑到可维护性,付出这一代价是完全值得的。
2、 界面必须始终一致
一致的人机界面不致增加用户的负担,让用户始终用同一种方式思考与操作。较忌讳的是每换一个屏幕用户就要换一套操作命令与操作方法。
bbbbbbs下的应用软件之所以倍受青睐,与其界面的一致性不无关系。例如,以问号图标表示帮助,以磁盘图标表示存盘,以打印机图标表示打印,等等。
3、 界面必须使用户随时掌握任务的进展情况
人机界面应该能够告诉用户软件运行的进度。特别是在需要较长时间的等待时,必须让用户了解工作进展情况,如已经完成了百分之几等。切不可让用户面对一个没有反应的屏幕,以致怀疑是否出现了死机现象。
目前,bbbbbbs下的应用软件无论大小,其安装程序几乎均做到了这一点。开发MIS软件时,这一点很值得借鉴。
4、 界面必须能够提供帮助
决不可以认为使用程序的用户都是*,*提供帮助。有关的提示、信息、说明应该放在随手可得的位置。
一个优秀的MIS软件应该提供在线求助功能,甚至提供使用向导,这无疑会给用户带来大的方便。使用**链接技术将使求助功能锦上添花。在多媒体环境下,以语音提示作为操作向导,不会干扰屏幕信息,是一个较佳的选择。
5、 宁可让程序多干,不可让用户多干
多数MIS软件的数据输入量较大。对于一些相对固定的数据,不应让用户频频输入(特别是汉字),而应让用户用鼠标轻松选择。例如,人事管理系统中?quot;文化程度系相对固定的数据,其值一般取小学、初中、高中、大专、大本、硕研、博研等。录入这类数据之前,MIS软件应在相应位置弹出一个列表框,待用户以鼠标点击,而不应让用户每次都输入这些汉字。
汉字输入与西文输入的状态切换虽说是举手之劳,但频繁进行状态切换令人颇感厌烦。若能够在程序中实现自动切换,无疑是深受用户欢迎的。
MIS软件开发完毕后,交付给用户使用时,开发人员往往要求用户记录软件的出错情况。这不能不说是强人所难,因为此举增加了用户的额外负担。开发者应编写一个错误实时记录程序,自动记录何日、何时、何程序出了何种错误。
总之,所开发的MIS在使用过程中,应使用户的数据输入量降至较低限度,同时使用户的干预尽量少。实践证明,用户干预愈少,MIS系统的满意程度愈高。
6、 输入画面尽可能接近实际
如果某个电算会计软件的凭证录入画面是表格式的,一屏可录入多条记录,而且与实际凭证一模一样,甚至连颜色都无异,用户在终端上录入凭证,佛用笔在纸上填写凭证,那么,一种亲切感会油然而生。试想,哪个用户不愿意使用呢?相反,如果一屏只能录一条记录,录入一条凭证要操作数屏,那么结果是可想而知的。
7、 具有较强的容错功能
误操作、按键连击等均有可能导致数据误录。巧妙地进行程序设计,可以避免此类因素造成的错误。例如,录入学生成绩时,我们可以对其范围进行限定,使用户无法输入0-100以外的数据;录入学生年龄时,不妨根据实际情况将范围限制在15-20之间。
三、 人机界面设计中的矛盾及解决办法
设计人机界面时,经常会遇到灵活性与一致性的权衡问题。原则上,对某一软件来说,用户的思维方式应当是一致的,操作与控制的方式也应当是一致的。只有这样,才能减轻用户使用软件的困难,使用户不知不觉地进入统一的思维框架,从而正确地、顺利地应用这个软件。但这只是问题的一个方面。另一方面的问题是,用户是多种多样的,它们有各自的习惯与爱好,应当让他们有一定的灵活性,能够自由地选择某些功能的操作方式。
例如,出于方便,有人喜欢使用头键选择下拉菜单中列出的某项功能,有人则偏偏习惯于使用快捷键,因为它们非常快捷。设计软件时,我们不妨使鱼与熊掌兼得。
再如,对于人机界面的色彩,有人从提高工作效率着眼,喜欢鲜艳悦目的彩色界面;有人则则从保护视力出发,宁愿要黑白的。开发MIS软件时,程序员不妨给用户选择颜色的余地。
四、 结束语
在MIS软件的开发中,人机界面的重要性已经提到议事日程上来,其优劣已是衡量软件质量的重要标准之一。