在一个实时内核中，设计一个快速响应的接口远不止将一些菜单组合在一起这么简单。用户接口展现了实时设计中它自身的多样性。
许多用户接口程序员通常以他们所使用的图形环境作为范式，譬如Microsoft Windows ，X，或者MS-DOS中的众多图形包的一个。这些工具包通常提供有一个主事件循环，由应用程序员去填充不同的回调函数。对应用程序员而言，大多数控制流程都被隐藏起来了。程序员并不需要知道和关心按键或者鼠标事件是如何被捕捉到并消抖，这些都是系统做的事情。但是，有时候，嵌入式程序员不得不面对这样一个现状: 自己设计的硬件装置没有被这些标准工具包中任何一个所集成进去。通常情况下，这些可用的商业的工具包并不会考虑用户输入在硬件层次上是如何组成的。更普遍的情况是，这些商业工具包根本就不能够在嵌入式平台上运行。
不管系统拥有一个窗口可视图形界面并由鼠标和键盘进行控制的接口，或者还是仅仅简单到类似于数字时钟的接口，接口设计的原则都是一样的。
除非另外说明，在这里我们假设我们的系统采用C语言开发，且运行在支持任务(tasking)和队列(queue)的RTOS上面。
许多设备输入需要连续不断的监测或者定期查询以保证不遗漏掉任何事件。考虑这样的一个系统: 按键按下的持续时间为250ms ，处理每一个按键事件需要花费500ms的时间。如果操作者连续快速的按下两个按键，则第二个按键可能根本就检测不到，这是因为，在处理器完成第一个按键事件响应处理并返回重新读取按键的时候，第二个按键已经释放了。由于两次按键的快速按下，而导致系统过载(overload)了。尽管事实上，在用户按键响应执行之前以及响应执行完毕之后CPU大部分时间都是在空转。
为了避免这样不可靠的现象出现，输入硬件必须设计成中断驱动，或者由一个专门的任务进行输入检测: 该任务仅仅只监测和记录用户事件，但是并不执行由这些事件触发的处理过程。在RTOS中，可以采用一个专门的任务，周期性的轮巡这些设备。轮巡的时间周期则由输入设备特性，响应效率需求，以及处理输入设备所需消耗的时间共同决定。
|
楼主
标题置顶
标题高亮
