IP网络终端系统方案与设计Word格式.docx
《IP网络终端系统方案与设计Word格式.docx》由会员分享，可在线阅读，更多相关《IP网络终端系统方案与设计Word格式.docx（20页珍藏版）》请在冰豆网上搜索。
可以让开发者将操作系统的功能和内存需求定制成每一个应用所需的系统。
开发者可以利用它来实现从简单的单个独立设备到复杂的、网络化的多处理器系统。
●QNX：
QNX是一个实时的，可扩充的操作系统，它遵循POSIX.1（程序接口）和POSIX.2（Shell和工具）、部分遵循POSIX.1b（实时扩展）。
它提供了一个很小的微内核以及一些可选的配合进程。
其内核仅提供4种服务：
进程调度、进程间通信、底层网络通信和中断处理，其进程在独立的地址空间运行。
所有其它OS服务，都实现为协作的用户进程，因此QNX内核非常小巧（QNX4.x大约为12Kb）而且运行速度极快。
这个灵活的结构可以使用户根据实际的需求将系统配置成微小的嵌入式操作系统或是包括几百个处理器的超级虚拟机操作系统。
●PalmOS：
3Com公司的PalmOS在PDA市场上占有很大的市场份额，它有开放的操作系统应用程序接口（API），开发商可以根据需要自行开发所需要的应用程序。
目前已经有总共3500多个应用程序可以运行在PalmPilot上，其中大部分应用程序均为其他厂商和个人所开发，使得PalmPilot的功能得以不断增多。
这些软件包括计算器、各种游戏、电子宠物、地理信息等等。
在开发环境方面，可以在Windows95/98，WindowsNT以及Macintosh下安装PalmPilotDesktop；
PlamPilot可以与流行的PC平台上的应用程序如Word，Excel等进行数据交换。
●OS-9：
Microwave的OS-9是为微处理器的关键实时任务而设计的操作系统，广泛应用于高科技产品中，包括消费电子产品，工业自动化，无线通讯产品，医疗仪器，数字电视/多媒体设备中。
它提供了很好的安全性和容错性。
与其他的嵌入式系统相比，它的灵活性和可升级性非常突出。
●LynxOS：
LynxReal-timeSystems的LynxOS是一个分布式、嵌入式、可规模扩展的实时操作系统，它遵循POSIX.1a、POSIX.1b和POSIX.1c标准。
LynxOS支持线程概念，提供256个全局用户线程优先级；
提供一些传统的，非实时系统的服务特征；
包括基于调用需求的虚拟内存，一个基于Motif的用户图形界面，与工业标准兼容的网络系统以及应用开发工具。
●Linux：
Linux在嵌入式领域获得了飞速发展，目前正在开发的嵌入式系统中，49%的项目选择Linux作为嵌入式操作系统。
Linux之所以能在嵌入式系统市场上取得如此迅速的发展，与它自身的优良特性有着不可分割的关系：
免费、开放源码，丰富的软件资源；
功能强大的内核，性能高效、稳定，多任务；
支持多种体系结构，如X86、ARM、MIPS、ALPHA、SPARC等；
完善的网络通信、图形、文件管理机制；
支持大量的周边硬件设备，驱动丰富；
大小、功能都可定制；
良好的开发环境，不断发展的开发工具集；
广泛的软件开发者的支持；
价格低廉。
从我们IP2000网络终端的需求和目前网络终端的市场来分析，目前我们公司已有的产品IP1000采用Linux+Microwin这种方式已基本实现网络终端的需求，只是在界面的美观程度和系统速度上比同类型的较为突出的实达netterm860终端有所不足，但从系统的角度和开发进度以及成本的角度考虑，重新引进一种新的嵌入式操作系统，以上介绍的几种EOS引进的门槛成本太高，且需要较长时间消化和熟悉，移植到我们的硬件平台也需要长时间的过程，综合考虑，我们还是决定在博利思提供的Linux内核的基础上构筑我们的IP2000的OS，并准备对内核作如下改进：
●优化framebuffer代码，并在原有256色的基础上增加16色支持
●修改ttyS0/1的设备驱动，解决目前IP1000存在的所有由于串口造成的问题
2、GUI设计
通过对目前几种基于Linux的嵌入式GUI的详细分析，较好的嵌入式GUI通常结合面向对象方法采用多层独立设计，具有以下结构：
●设备相关层（driver）
在这一层的功能应该是将系统中与设备和操作系统平台的具体细节屏蔽起来。
它利用实际的设备驱动程序接口或者OS系统调用来与硬件设备交互，这些硬件设备主要包括screen、mouse和keyboard等。
我们使用设备对象（deviceobject）的概念来描述一类设备，每一个对象描述了一类实际设备的属性和方法。
比如，screen设备对象就描述了screen设备的各种属性（屏幕尺寸、分辨率、像素深度、像素格式、逻辑显存首地址等等）和基本方法（打开和关闭显示器、设置调色板、返回屏幕属性、读写像素点等等）。
对于同一类设备在不同驱动或者平台上的具体情况则以设备对象实例来描述，比如screen类型的设备，我们可能让它工作在Linux上，通过framebuffer或者SVGALib驱动来操作它。
他们的对象类相同，但是类的属性和方法的实现不一样。
中间层看到的只是该类设备的可选的对象实例，不用关心底层是如何操作的（也就是对象的方法是怎样实现的）。
最底层实际上是以设备对象的方式为中间层提供了一个抽象的设备驱动界面。
为了移植更容易，最底层应尽量简洁，只实现最基本的设备功能函数。
可以看到，当系统要移植到另外的平台上时，我们只要按照各类设备对象的定义实现相对较少的函数就能建立新的设备对象实例并让中间层选择他们就可以了。
●设备无关层（engine）
这一层的功能是提供一个可以为各种应用层共享的与设备无关的核心图形引擎，其中的主要工作就是实现各种图形函数和输入设备的功能函数。
对于中间层，它向下看到的是各类设备对象，向上则是要提供一个抽象的核心图形界面，使得上面的应用层对它所使用的到底是什么设备对象不用去理会。
很显然，这一层根据不同的设备和平台选择相应的设备对象实例来实现核心图形引擎。
由于每类设备的各个实例拥有同样的对象类型定义，所以中间层基于设备对象所实现的功能是不会因为设备和平台的更改而受影响的。
同时，中间层把消息驱动机制、窗口管理机制交给应用层去完成，因此，对于各类型的应用层（Win32或者是X-Windows），中间层完成的功能都是通用的。
●应用层（API）
这一层的功能是按照应用的具体要求为应用程序提供适当的应用层用户界面。
当应用程序不需要窗口系统的时候，用户自定义图形界面将十分简单，甚至可以什么都不做而直接使用中间层提供的抽象核心界面。
如果用户需要完善的多任务窗口系统，比如是类Win32的，可以使用抽象核心界面来实现其应用程序编程接口（API）以及窗口和消息机制等。
嵌入式GUI的体系结构的抽象参考模型如下:
目前采用此套结构的比较成熟的嵌入式GUI有Microwindow和MiniGUI两种GUI平台，Microwindow平台提出较早，并且经过多年的实践，已经比较成熟，目前国内的众多嵌入式系统厂商包括联想、中软、红旗、桑夏科技、华恒等都采用Micorwindow作为基础开发自己嵌入式GUI，但因为该项目缺少强有力的核心代码维护，代码质量参差不齐，因此在另外一种GUIQt/Embedded发布以来，它就长时间停留在了0.89Pre7版本,近几年来发展缓慢；
MiniGUI项目起源于清华大学一个采用嵌入式Linux系统的工业控制系统项目，开发之初借鉴了Microwindow的一些经验，但后来在发展速度上超过了Microwindow（MiniGUI已是1.2.0版本,但Microwindow至今还是0.89pre版本），由于两者都是自由软件项目，开放源代码和所有文档，可作为我们IP2000网络终端的GUI设计的参考选择，我们可以在其中一种的基础上构筑我们自己的GUI平台。
由于IP2000网络终端有多任务功能需求，因此我们的GUI设计必须能够满足适应多任务的需求，通过对已有的两种GUI进行预研，我们发现，GUI的多任务设计通常有两种方法：
●采用C/S结构
C/S结构是天然的多任务，在Sever端专门负责监控外部事件和随之的消息传递和分发，Client完成消息的处理，各个Client之间互不干扰和影响。
采用这种方法实现多任务支持的有Microwindows的Nano-x方案和MiniGUI，但两种GUI实现的机制有很大差别，MicroWindows为了追求和XWindow的兼容，采用了传统的基于Unix套接字通讯方式的C/S系统结构，这样大量的数据在客户/内核/服务器之间传递，增加了系统负荷，占用了更多系统资源，降低了系统的图形效率，并不适应于CPU速度较慢和系统资源有限的一般嵌入式场合。
而MiniGUi吸取了Microwindows的经验，采用了独特的体系结构，它的最初版本采用线程机制来实现C/S结构，这样所有的应用程序都运行在同一个地址空间，大大提高了程序之间的通信效率，但这种结构也导致了系统整体的脆弱，如果某个线程因为非法的数据访问而终止运行，整个进程都将受到影响，不过，这种体系结构对关键的实时控制系统来说，还是非常适合的，后期发展的MiniGUI-Lite版本则作了一些改进，在独立多进程和系统效率之间作了一些综合，采用套接字和共享内存结合的方式支持多进程，并且提供前后台进程的切换，通过共享内存机制提供全局资源的共享，以便减少实际内存的消耗，但好像MiniGUI的图形引擎不是直接建立在内核framebuffer驱动上，而要由如Libggi或Svgalib等更高一级的图形库支持，并且由于MiniGUI采用了独特的接口设计，其应用程序的可移植性很差，而MicroWindows的Nano-x方案则采用XWindow的兼容接口设计，大大方便了许多基于XWindow的应用程序的移植和代码复用。
●采用GUI上下文共享的方法
通常在单任务GUI基础上开发图形界面应用有如下图左边的系统流程，
应用程序通过调用GUI的API实现相应功能，而这些函数有自己的上下文，并且这些上下文主要是通过数据空间的形式（data&
BSS）来保持的。
由于消息系统的同步功能，如果在同一进程中创建并使用多个窗口，也不会造成GUI的冲突。
例如，可以在一个进程中构造记事本和计算器，两个窗口都可以正常地运行，因为任一时刻只有一个窗口接受消息队列的消息分发并处理（使用或改变GUI上下文）——这种同步是由消息系统来保证的。
假如把GUI使用的上下文和应用其它部分的上下文分开，一个应用完全是可以正常运行的。
如果把这种方法应用到多任务的系统，如果各个任务独有自己的GUI上下文，则不能解决一些系统公共的设备例如鼠标、键盘、输入法等事件的检测、转换、分派以及系统庞大等许多问题（在C/S结构中是由Sever来完成这个工作的）。
由此只能在各个任务之间共享GUI上下文，同步访问的方法来实现多任务，但在这种方法下，可能出现上图右部的状况，两个应用的GUIAPI接口函数会不可预知地改写GUI的上下文，会造成严重冲突，为了避免这种情况，通过OS的锁机制来实现在不同进程间实现同步地访问GUI上下文，则可实现不同进程有秩序地协同作，达到多任务的目的，通常通过采用了嵌入式Linux中常用的一些工具，包括ld脚本、ld、nm、objcopy、awk、objdump等把ELF文件各部分抽取出来、并重新定位，用共享内存函数把指定的内存映射到固定的地址的方法，把抽取的GUI上下文装载到固定位置的方法来实现共享。
共享GUI上下文的各进程运行时结构如下图所示：
其中sharedata&
BSS就是GUI的上下文。
采用这种方法来设计GUI多任务支持的有博利思公司为我们公司IP1000多任务版网络终端设计GUI，该GUI是在Microwindows的基础上改进后的设计，事实上，这种设计方法也是借鉴了MiniGUI-Lite版本的一些技术，用一个主进程作为虚拟Sever处理所有的外部事件，完成消息转换后完成消息的分发并完成窗口维护和管理，同时负责用户进程的启动（用fork的方式复制子进程，因而主进程和所有用户进程之间皆为父子关系，各用户进程之间则互为兄弟进程），各用户进程则接受并完成消息处理。
主进程和用户进程通过共享内存的方式来实现GUI上下文共享和通讯，并且采用主进程附加调度的方式：
在LINUX内核进程调度的基础上再建立应用调度，任意时刻只让其中一个用户进程运行（Running状态），其他用户进程则让其进入Sleep-on状态，主进程并用消息分发的主动权采用消息驱动的机制完成各用户进程间的调度，并实现前后台时间片的主动分配，这种方法不仅可实现共享GUI的访问冲突，同时也提高系统的效率――决不使空闲的用户进程占用宝贵的CPU时间片资源，但这种方法的缺点也是显而易见的。
对于我们GUI的设计，我们进行了较长时间的预研，并对Microwindows/Nano-x和MiniGUI的多任务机制进行了较为详细的剖析，觉得两者实现多任务的C/S结构对于我们的arm7500硬件平台并不适合，由于C/S结构系统效率较低，在我们这种硬件平台资源的基础上，性能远远不能达到我们的功能需求，鉴如此，我们决定在IP1000多任务版本GUI的基础上，开发IP2000的GUI，主要是完善在IP1000开发过程中已发现的缺陷，并增加如下功能的支持：
●对Microwindows桌面和窗口管理进行完善，使整个桌面和窗口管理与windows风格更加类似，从而为IP2000设计出更好的人机界面：
多窗口操作，图标的拖动，窗口最大、最小化操作等
●参照MiniGUI改进Microwindows图形引擎的一些算法，提高GUI的效率
●增加业务窗口下拉菜单的支持（参考MiniGUI菜单组件设计）
●增加国际标准化汉字系统：
支持16x16（大字符集）、24x24汉字库（GB2312）多种汉字字体
●字符显示驱动增加16色支持
●寻找替代单消息队列共享的进程间通讯机制，避免某个用户进程崩溃导致整个系统崩溃。
3、仿真设计
设计目标
●降低模块间的耦合关系
●减少中间层
●方便各个平台的移植
设计方法
●将IP1000的仿真程序进行整合，按模块封装成API。
●针对几个关键点进行技术改进，争取最大程度地发挥系统和硬件平台的优点。
●在纵向的层次上只有相邻的两层有调用和被调用的关系，相同的层次可以调用和被调用。
仿真结构设计
仿真层
仿真driver层
microwin
全局模块、命令分析模块
键盘模块
显示模块
打印模块
外设模块
通讯模块
自检模块
键盘仿真driver
显示仿真driver
打印仿真driver
外设仿真driver
通讯仿真driver
自检仿真driver
NVR操作
键盘API
显示API
打印API
串口API
网络API
NVRAPI
中文输入法
模块说明
1）、仿真全局模块，包括：
●初始化Gblint的数据
●改变汉字通讯码的显示拼字入口
●设置输入/输出入口（将终端仿真软件从功能上分为输入、输出两大部分）
●复位通用命令分析器
●根据参数初始化串口
●恢复、保存、缺省NVR参数
2）、命令分析
使用有限状态自动机来解析命令序列。
3）、键盘模块
仿真上层：
●处理控制码（ESC、CAN、BS、CR、XON、XOFF）
●处理ASCII码
●处理本地功能键
●处理用户自定义序列键
●处理缺省功能键
●汉字译码并发送
仿真driver层：
将系统发来的键盘消息WM_KEYDOWN、WM_KEYUP转换成终端所需的键码（高字节扫描码＋低字节Ascii码）
GUI层：
●在键盘有数据时，更新键盘状态，分发键盘事件。
●将原始码转换成终端所需的键码
●如果是输入法相关键且输入法有效，进输入法处理；
否则向上层发WM_KEYDOWN或WM_KEYUP消息。
4）、显示模块
将显示从操作对象上可以分为5个部分：
屏幕、光标、字符显示、滚屏、图形。
●根据通讯方式的不同，TTY显示一个国标码/ASCII码/ID码/CNC码。
●能在光标的当前位置以当前属性和字符集显示一个ASCII字符
●屏幕开关显
●背景色设置
仿真driver层：
●初始化显示。
主要是创建光标、设置光标的属性、显示光标、设置屏幕行数和列数。
●光标控制：
设置光标属性、位置
显示光标属性、位置
移动光标
得到光标的位置和光标左右的字符。
清除光标
支持多个光标
GUI层：
●光标驱动：
创建光标、释放（清除）光
光标属性（点/线、固定/闪烁/消隐）支持
●屏幕驱动
开/关显、节电模式支持
分辨率、背景色设置支持
●字符显示驱动
西文、汉字、汉字左半、汉字右半显示支持
自造汉字显示支持
字符属性（上/下/左/右划线、高/低亮/正常、倍高/宽、显示/消隐）支持
●滚屏驱动
向上滚屏、向下滚屏支持
显存数据操作支持
●图形驱动
点、线、圆等基本图形操作支持
5）、打印模块
仿真上层
●选择打印机
●打印机字库打印
●终端字库打印
●正常打印拷贝屏幕
●自动打印屏幕上的一行
●透明打印
●条码打印一个字符
●退出打印
●打印出错时弹出模态窗口，显示提示信息，用键盘或鼠标选择Y/N来决定继续打印/退出打印。
●得到当前行列的VRAM地址
●打印字符属性处理
●将显示点阵转换成打印点阵
●打印一个字符（串）到设置的打印端口。
最多查询打印端口0x7ff次，若就绪就送打印，若打印机错退出。
●打印测试
GUI层
●后台打印字符缓冲区支持
●并口支持
6）、外设、通讯
外设模块和通讯模块的程序结构以及两个模块之间的关系如下图所示：
外设通讯
串口通讯网络通讯
串口API网络API
外设模块仿真上层：
●打开/关闭端口
●打开/关闭密码键盘、读密码键盘的数据向主机发送
●辅串口、透明打印等命令分析
●向辅串1~n输出数据
●读辅串口数据向主机发送
●串口拷屏
●串口打印一个字符
通讯模块仿真上层：
●通讯初始化
●通过主通讯口（主串口或网络口）以非阻塞方式从主机读数据。
●通过主通讯口（主串口或网络口）以阻塞方式从主机读数据。
●写一个字节数据到主通讯口（串口或网络口）
●写一串数据到主通讯口（串口或网络口）
外设模块仿真driver层：
●串口通讯初始化
●向主串、辅串输出数据
●从主串、辅串读数据
●设置串口参数
●串口复位
●串口测试
网络模块仿真driver层：
●网络通讯初始化
●ping功能支持
●打开/关闭一个Telnet会话
●从一个Telnet会话中读数据
●向一个Telnet会话中写数据
外设模块GUI层：
●打开/关闭串口
●从串口读数据
●往串口发送数据
●读取串口参数
网络模块GUI层：
●打开/关闭一个网络联接
●从网络读数据
●通过网络发送数据
6）、输入入法模块
输入法放嵌入GUI层，并支持输入法挂接接口设计。
●切换输入状态
●切换输入法
●取得输入键的Ascii码，查表取得相应的汉字内码，把汉字的内码发
送给提示行，用数字键选择汉字
●自造汉字和短语输入支持
●提供修改默认输入法的API
7）、NVR模块
●读取/保存终端参数
●读取/保存自造短语
●读取/保存自造汉字
GUI层:
●读NVR到缓冲区
●保存缓冲区到NVR
●从缓冲区中读数据
●NVR校验读
●NVR校验写
●读取自造短语、自造汉字
9）、自检模块
●键盘测试
●并口测试
●网络测试
●循环自检
●演示测试
●报告自检结果
一、流程设计
在以上设计的基础上，我们采用SDT方法作如下基于消息驱动机制数据流程的详细流程设计（图见基于消息驱动机制数据流程设计）：
如上图所示我们可取得如下结论：
1、流程设计的几个基本原则：
●消息循环的速度必须足够快，也就是说从事件的检测――－>
完成消息的转换――>
进入消息队列――>
从消息队列取出分发――>
相应消息回调函数处理完成――>
事件检测这整个循环必需在某个限定时间内完成，才不会造成事件丢失和消息处理滞后，应用不能有长时间的某个消息处理流程。
●由于整个应用系统共享一个消息队列，所有消息处理在不非法操作造成系统崩溃的基础上都必须能够正确返回，否则某次消息的处理会造成消息循环停止，造成系统停止。
2、性能分析：
我们的传统终端810C/910/920等型号和IP1000/2000都是采用CLPS-7500硬件平台，分析两者的流程，我们可作出如下图所示对比分析，为了支持图形界面、多任务、网络，我们不得不在我们的系统中引入OS、GUI，随之而来的则是许多中间流程的引入，使我们整机效率和处理速度等性能的降低，所以我们IP2000功能指标如刷屏、滚屏、处理速度等所能达到的终极目标就是采用同类型CPU的传统终端，一般来说，达到80％左右当属正常。
一般来说，可考虑如下角度优化影响性能指标的流程：
●频繁在内核态和用户态之间
升级会员 