实时程序（共6篇）
实时程序 篇1
0 引言
嵌入式Linux是主流的开源嵌入式实时操作系统之一，易于开发和移植，可扩展性强，但是标准Linux内核由于自身结构设计的原因，不提供对强实时性能的支持。本文首先从Linux内核结构分析入手，研究了Linux内核实时性能，对比分析了几种内核实时化方案，选择采用实时应用程序接口RTAI对Linux进行实时化改造。
1 Linux内核实时性能分析
Linux操作系统是类Unix操作系统，其架构有两大特点：用户空间/内核空间结构、宏内核结构。
1.1 用户空间/内核空间的系统结构
Linux采用用户空间/内核空间的系统架构，用户程序以进程的方式运行于用户空间，每个进程拥有相互独立的地址空间，这样用户进程在用户空间中相互是不可见的，减少了相互干扰的可能，大大降低了用户程序的编写难度。控制和支撑用户程序运行的操作系统中的各个管理模块如内存管理、进程管理、进程通信和文件系统等均位于内核空间，内核空间采用统一的地址空间，从而可以提高管理模块之间的切换速度。
用户进程在用户空间运行，内核各个管理模块为用户进程提供各种需要的服务，这是一个典型的“客户/服务器”的模型。服务的提供是通过系统调用来实现的，为了方便开发者编程，Linux操作系统把这些系统调用服务以用户程序接口 (API) 的方式提供给用户。
1.2 宏内核结构
如图1所示，宏内核 (M i c r o-K e r n e l) 是与微内核 (Monolithic-Kernel) 相对应的概念。传统的宏内核由于内核庞大，一般设计成纵向分层的结构，与进程运行相关的各个管理和支撑模块以分层的方式存在于内核空间;而微内核则不同，采用了横向分层的结构，并且与进程运行相关的各个管理和支撑模块以用户进程的方式横向分层于用户空间。微内核结构相对于传统的宏内核结构有组成灵活、配置方便和便于调试的优点，被广泛的应用于嵌入式实时操作系统的设计。Linux操作系统在进行内核设计时引入了可卸载模块管理机制，因而Linux虽然是宏内核结构，但在内核中的各个模块是采用与微内核相似的水平分层方式的，十分便于修改和裁减以适用于嵌入式实时系统。
2 Linux内核实时化方法研究
2.1 基于单内核实时化方案
对标准Linux内核进行直接修改，优化Linux实时性能。最主要是提高时钟精度，解决中断屏蔽和内核态不能被抢占等问题。目前标准内核实时化改造系统主要有：Kurt-Linux, RedLinux, Linux/RK, Linux-SRT等等。
2.2 基于双内核实时化方案
在原来Linux内核基础上增加一个实时内核，所有实时任务都在实时内核上运行，而Linux内核作为该实时内核中优先级最低的一个任务，通过调度执行。基本原理如下：在双内核系统下，原Linux内核被作为实时内核空闲状态下的一个任务，当没有其它实时任务需要执行时才执行Linux内核。实时内核修改了原Linux内核的开关中断等函数，从而使得Linux内核不能阻塞中断。当Linux内核关闭中断时，实时内核将阻止对硬件中断的真正关闭，而只是将其记录下来。而当一个硬件中断到达时，实时内核将截获该中断，并决定如何处理该中断。如果该中断有实时处理程序，则该实时程序将被调用。如果没有实时处理程序，或者实时处理程序表明将与Linux内核共享中断，则该中断将被标记为等待处理状态。如果Linux请求响应中断，那么所有的在等候处理状态的中断参与竞争，然后相应的Linux的中断程序将被调用。由此可见，无论Linux内核处于何种状态，均不可阻止实时任务的执行，系统的中断响应时间和实时任务的响应时间均由实时内核来保证，因此完全可以实现一个硬实时的系统。采用双内核方案思想的主要有RT-Linux和RTAIㄢ
单内核和双内核两种方案采用不同的方法对Linux的实时性能进行了优化，下面从实时性能、核心代码可维护性、实时任务编程模式和核心代码重用性四个方面对两种方案进行深入地分析研究。
2.2.1 实时性
对于单核系统方案，实现了内核可抢占，从而提高内核的实时响应性能。但中断响应时间以及任务响应时间等实时指标仍是难以确保的，主要原因是内核代码极其庞大，测试的时候很难保证能够跟踪到核心的每一条执行路径，测试结果也只能反映在一定条件下的情况，所开发的工具也无法覆盖到所有的情况。由此可见，其实时性尤其是最差情况下的实时性是难以保障的，因此这种方案主要适用于软实时系统，对硬实时系统来说并不太适合。
2.2.2 核心代码可维护性
采用单核系统方案增加了核心代码的编程人员的负担，不仅仅是现有的代码需要进行修改以支持可抢占性，而且新开发的代码也面临同样的问题。编写一个完全可抢占的代码相对于编写不可抢占型代码而言是比较困难的，其中还需要进行详细的性能测试以保证低的内核延时，显然这一切都使得核心代码维护的难度进一步提高。而采用双核系统方案，核心代码的维护就要容易很多。实时内核的代码与原核心代码基本上是无关的，因此核心代码的升级和修改并不需要考虑可抢占性和延时等问题，这样就大大降低了核心代码维护的难度。
2.2.3 实时任务编程模式
采用单核系统方案，实时任务的编程模式与非实时任务基本上相同，因为核心可抢占型方案仅仅是对内核的修改而与应用程序无关。实时应用程序可以使用所有的系统调用和标准代码，既可以提高实时性，又基本上不用修改原有的应用程序，只需要增加一些必要的实时代码，如设置进程实时调度策略及优先级等，这对于实时任务编程人员来说无疑是非常方便的。
2.2.4 核心代码重用性
由于单核系统方案主要在内核调度等代码上进行修改，因此完全可以在实时环境下保留核心原有的几乎所有功能，如内存管理、文件系统、网络等等，因此没有必要为提高这些部分的实时性而重写代码。但双核系统则不同，实时内核不能完全不加限制的直接调用原有的核心功能，如需要实现实时网络通信，实时任务不能直接调用原有的网络功能，必须重新开发一套适用于实时内核环境的网络代码，工作量比较大。
3 采用实时应用程序接口RTAI方案来增强Linux内核的硬实时性能
操作系统可适应域环境ADEOS (Adaptive Domain Environment for Operating System) 的目标是为操作系统提供一个灵活的、可扩展的自适应环境，在这个环境下多个相同或者不同的操作系统可以共存，共享硬件资源。ADEOS是在已有的操作系统下插入一个软件层，通过向上层多个操作系统提供某些原语和机制而实现硬件共享。但是ADEOS并不对硬件的使用强加任何的限制，上层的操作系统仍然可以自由操作硬件，而不会因为ADEOS的存在而有任何的约束。ADEOS除了可以实现操作系统对系统资源的共享之外，还可以用于新的操作系统的开发、操作系统内核的调试、跟踪等。目前，ADEOS是基于Linux内核实现的，主要的应用是在Linux的实时化方面，使基于Linux的系统能满足硬实时的要求。在基于ADEOS的系统中，每个操作系统都在独立的域内运行 (域内不一定都是操作系统，也可以是完成其他功能的软件实体) ，每个域可以有独立的地址空间和类似于进程、虚拟内存等软件抽象层，而且这些资源也可以由不同的域共享。在基于ADEOS的系统中，存在着四种类型的交互，如图2所示。A类交互是各个域对硬件的直接操作，包括访问内存和设置硬件等操作，如同ADEOS不存在一样;B类交互是双向的，一方面是ADEOS接收硬件产生的中断和异常;另一方面是ADEOS直接控制硬件;C类交互指当ADEOS接收到硬件中断后，会执行相应域的中断服务程序;D类交互指域内的操作系统可以主动向ADEOS请求某些服务，如请求共享其他域中的资源、请求授权域优先级等，通过D类交互，可以实现各个域之间的通讯。
ADEOS是基于Linux实现的，系统的启动和初始化工作都可以交由Linux完成，之后再进行ADEOS的初始化工作。ADEOS功能既可以直接编译进内核，也可以作为一个内核模块在系统运行时动态加载。Linux内核作为ADEOS的一个特殊的域存在，称之为根域 (Root Domain) ，ADEOS的很多功能都是依靠根域实现的。图3是基于ADEOS的RTAI方案的逻辑结构图，表示了RTAI, Linux和ADEOS三者之间的相互关系。系统中RTAI域的优先级高于Linux域，当ADEOS拦截到硬件的物理中断之后，先调度RTAI对该中断进行处理，执行中断相关的实时任务，只有当没有实时任务和中断需要处理的时候，才会调度Linux运行，这就保证了的中断响应速度和实时任务不受影响，从而提供了实时系统的可确定性。
基于ADEOS的RTAI系统可以划分成硬件平台、ADEOS、RTAI、Linux内核和Linux应用程序五大部分，可以把各个部分之间的关系归为9类：
关系1表示实时任务如何与RTAI提供的实时任务接口相互作用。实时任务都是以Linux内核模块方式实现的，要实现一个实时任务，在模块初始化的时候调用RTAI的任务创建函数初始化实时任务相关的数据和环境，指定定时器的运行模式 (单触发模式或周期模式) ，初始化定时器，然后开始执行任务。当没有加载任何RTAI的实时任务模块的时候，RTAI的任务调度和时钟中断都不会启动。关系2表示实时任务通过RTAI提供的管道 (FIFO) 和共享内存与Linux用户空间中的进程进行通信，通过这种方式，实时任务获取的实时数据就可以传递到用户空间让非实时进程对数据进行后续的处理。关系3表示RTAI本身的实现需要用到Linux内核提供的某些功能。例如，RTAI本身是以Linux内核驱动模块的形式存在的，这就需要用到Linux内核的动态内核模块加载功能;另外，RTAI目前的内存管理模块在初始化时是使用Linux的内存分配接口分配足够的内存。关系4表示Linux内核和Linux用户空间应用程序之间的关系。关系5表示RTAI和ADEOS之间的交互。最新的RTAI版本3.5是基于ADEOS实现的，RTAI实现了ADEOS内的一个域，这个域的优先级高于Linux内核所在的根域，可以保证所有的RTAI中断和实时任务都不会受Linux本身的影响，从而确保快速的中断响应和实时任务的按时完成。关系6表示RTAI和底层硬件之间的交互。当外部事件触发了实时任务之后，实时任务在处理的过程中一般要对外部设备执行某些操作，例如控制采集卡进行数据采集、控制步进电机等。关系7, 8, 9表示Linux, ADEOS和硬件平台之间的关系。
摘要：嵌入式Linux是主流的开源嵌入式实时操作系统之一, 易于开发和移植, 可扩展性强, 但是标准Linux内核由于自身结构设计的原因, 不提供对强实时性能的支持。本文首先对Linux内核进行了分析, 指出其内核实时性能不强的原因, 研究了Linux内核实时性能, 对比分析了几种内核实时化方案, 采用ADEOS的实时应用程序接口RTAI实时化方案对嵌入式Linux进行了实时化改造, 增强其对硬实时性能的支持。
关键词：嵌入式,实时应用程序接口,Linux内核实时性
参考文献
[1]倪继利.Linux内核分析及编程[M].北京:电子工业出版社.2005.
[2]杜睿.嵌入式Linux实时技术研究[D].沈阳航空工业学院硕士学位论文.2007.
[3]Karim Yaghmour (2001) .Adaptive Domain Environment for Operating System.
实时程序 篇2
通用实时系统RTX是美国IntervalZero (前身为Ardence) 公司开发的Windows平台的硬实时系统, 可以为用户提供优秀的实时控制性能、高效的可扩展性及稳定性, 是迄今为止在Windows平台上唯一基于软件的硬实时解决方案。RTX提供了对IRQ、I/O、内存的精确控制, 以确保实时任务执行时具有100%的可靠性。RTX与Windows系统无缝地结合在一起 , 可以利用Windows系统的各种优势, 包括大量标准的API函数、高效的内存管理机制以及各种Windows下的通用资源。利用IPC信息共享与同步机制 , 可以实现RTX和Windows之间的数据通信。RTX的时钟分辨率可以达到100纳秒, 定时器周期最低可以做到1000、500、200、100微秒。
在工业控制领域, 设备与设备之间的通信一般有TTL、RS232、GPIB、RJ45等, RS232是其中常见且使用广泛的一种通信方式, 因其简单易用, 在设备之间短距离通信时, 一般都采用RS232。
在下文中, 将结合一个实例讨论在RTX实时系统下RS232串口通信的程序设计方法, 程序的开发运行环境为: Windows XP SP3、RTX8.1.2、VS2008、PC机串口及串口交叉线。
2 RS-232C 串口通信
PC机一般使用8250或16550作为串行通信的控制器, 使用9针或25针的接插件将串行口的信号送出。其信号定义如表1所示, 这些信号在通信过程中可能会被全部或部分使用, 最简单的通信仅需TXD、RXD和SG即可完成, 其他的握手信号可以做适当处理或直接悬空。
PC机支持1-4个串口 , 即COM1 -COM4, 其基地址在BIOS数据区0000:0400-0000:0406中描述 , 对应地址分别为3F8、2F8、3E8、2E8, COM1和COM3使用中断4, COM2和COM4使用中断3。串口通信控制器的控制寄存器定义如表2所示。
(1) 接收缓冲寄存器 (RBR) 和发送保持寄存器 (THR)
RBR暂存从线路上接收到的有效字符 , 等待本地读取。THR暂存等待发向线路的数据。它们共用同一I/O地址, 在半双工工作环境下, 互不干扰。
(2) 中断识别寄存器 (IIR)、中断允许寄存器 (IER) 及FIFO控制器 (FCR)
IIR为只读寄存器 , Bit6:7用来指示FIFO的状态 , 为00时无FIFO, 此时为8250或16450芯片, 为01时有FIFO但不可以使用, 为11时FIFO有效并可以正常工作。Bit3用来指示超时中断 (16550/16750)。Bit0用来指示是否有中断发生。Bit1:2标识具体的中断类型 , 这些中断具有不同的优先级别 , 其中LSR中断级别最高, 其次是数据就绪中断, 然后是发送寄存器空中断, 而MSR中断级别最低。
IER控制是否允许中断, Bit0为1时允许接收到数据时产生中断, Bit1为1时允许发送保持寄存器空时产生中断, Bit2为1时在LSR变化时产生中断, Bit3为1时在MSR变化时产生中断。如表3所示。
FCR可写但不可以读, 该寄存器用来控制16550或16750的FIFO寄存器。Bit0置1时允许发送和接收FIFO工作。Bit1和Bit2置1时分别用来清除接收和发送FIFO。清除接收和发送FIFO并不影响移位寄存器。Bit1:2可自行复位, 无需使用软件对其清零。Bit6:7设定产生中断的级别, 发送/接收中断将在发送/接收到对应字节数时产生。
(3) 线路状态寄存器 (LSR)
LSR为只读寄存器, 发生错误时Bit7为1, 发送保持和发送移位寄存器均空时Bit6为1, 发送保持寄存器空时Bit5为1, 线路状态为0时Bit4为1, 帧格式错时Bit3为1, 奇偶校验错时Bit2为1, 超越错时Bit1为1, 接收数据就绪时Bit0为1。如表4所示。
(4) 线路控制寄存器 (LCR)
LCR用来设定通信所需的一些基本参数。Bit7为1时DLL和DLM有效, 为0时THR、RBR和IER有效。Bit6为1时将发送端置为0, 使接收端产生一个“间断”。Bit3-5设定是否使用奇偶校验以及奇偶校验的类型, Bit3为1时使用校验, Bit4为0是奇校验 , 为1是偶校验 , Bit5强制校验为1或0, 并由Bit4决定具体为0或1。Bit2设定停止位的长度, 为0使用1位停止位, 为1则根据数据长度的不同使用1.5或2位停止位。Bit0:1设定数据长度。如表5所示。
(5) 波特率因子寄存器 (DLL, DLM)
DLL与DLM组成一个16位寄存器, 存放一个波特率因子 (分频值 ), 对振荡时钟进行分频 , 以得到用户需要的波特率。如表6所示。计算方法:
波特率因子 = 振荡时钟 / (波特率 *16)
( 6) Modem控制寄存器 ( MCR) 和Modem状态寄存器 (MSR)
MCR寄存器可读可写 , Bit4为1时进入环路测试模式。Bit3-0用来控制对应的管脚。如表7所示。MSR寄存器的高4位分别对应MODEM的状态线, 低4位表示MODEM的状态线是否发生了变化。
3 程序设计
软件分为两个部分: 用户界面部分和串口通信部分。用户界面部分由Windows程序实现, 串口通信部分由RTX程序实现, Windows程序和RTX程序之间的通信通过共享内存实现。
软件使用方法: 将两个程序放在同一个目录下, 启动Windows程序, 在程序界面上点击“启动串口”按钮即可启动RTX程序, 点击“发送信息”按钮即可进行串口通信。软件结构框架如图1所示, 软件运行截图如图2所示, 双机串口直连示意图如图3所示。
4代码实现
4.1 Windows用户界面程序
Windows用户界面程序完成与用户的交互, 通过共享内存与RTX程序进行通信, 设计步骤如下:
4.1.1创建项目
启动VS2008, 新建一个基于MFC对话框程序的项目, 项目名称设为“ComWin”, 不勾选“使用Unicode库”, 其他设置默认, 单击“完成”按钮完成项目创建。
4.1.2设置项目属性
添加对RTX API的支持, 在附加包含目录中添加:
"f:Program FilesIntervalZeroRTXinclude"
在附加库目录中添加:
"f:Program FilesIntervalZeroRTXlib"
4.1.3添加RTX头文件和导入库
在文件ComWinDlg.cpp中, 添加代码如下:
4.1.4添加全局变量和线程函数
在文件ComWinDlg.cpp中, 添加共享内存数据结构定义及显示串口信息的线程函数定义, 代码如下:
4.1.5初始化对话框
在文件ComWinDlg.cpp中的对话框初始化函数里, 添加用户界面初始化, 代码如下:
4.1.6“启动串口”按钮消息响应
在文件ComWinDlg.cpp中, 添加“启动串口”按钮消息响应, 创建共享内存、创建显示信息线程和启动RTX程序, 代码如下:
4.1.7“发送消息”按钮消息响应
在文件ComWinDlg.cpp中, 添加“发送消息”按钮消息响应, 将要发送的信息写入共享内存的发送缓冲区, 代码如下:
4.1.8退出系统消息响应
在文件ComWinDlg.cpp中, 添加退出系统消息响应, 关闭共享内存, 代码如下:
4.2 RTX串口通信程序
RTX串口通信程序完成串口数据的发送和接收, 通过共享内存与Windows用户界面程序通信, 设计步骤如下:
4.2.1将串口从Windows设备转换为RTX设备
打开RTX Properties, 选择“hardware”标签, 在“Devices”下点击“Settings”按钮, 选择硬件COM1, COM2, …, 点击右键, 选择“Add RTX INF Support”, 点击“Apply”按钮, 然后点击“Device Manager”按钮, 在设备管理器上更新COM端口的驱动, 不要使用自动选择, 必须手动选择RTX Support Driver。这样通信端口就被添加在RTX下面。
4.2.2创建项目
启动VS2008, 新建一个Rtx Application程序的项目, 项目名称设为“ComRtx”, 在应用向导的Application Settings页中, 选择“ASCII”和“Mulitithreaded C Run-time support”, 在应用向导的Program Settings页中 , 勾选“Provide a program framework”, 其他设置默认, 单击“完成”按钮完成项目创建。
4.2.3添加全局变量和线程函数
在文件ComRtx.c中, 添加共享内存数据结构定义、接收/ 发送线程函数定义和串口参数定义, 代码如下:
4.2.4入口函数main
在文件ComRtx.c中的main函数里, 打开共享内存, 初始化串口, 创建发送和接收线程, 然后进入循环等待, 退出时关闭线程和共享内存句柄。代码如下:
4.2.5发送线程
发送线程将共享内存中发送缓冲区的数据通过串口发送出去, 代码如下:
4.2.6接收线程
接收线程将从串口接收到的数据保存到共享内存的接收缓冲区, 代码如下:
下面分别给出Windows用户界面程序和RTX串口通信程序的实现代码。
5 结语
讨论了在RTX实时系统下, PC机的RS-232串口通信的程序设 计方法 , 并使用VS2008编写了程 序实例 , 在RTX8.1.2、Windows XP SP3下使用双机串口直连测试通过。
摘要：讨论在RTX实时系统下,PC机的RS-232串口通信程序设计方法。使用VS2008编写程序实例,在RTX8.1.2、Windows XP SP3下使用双机串口直连测试通过。
实时程序 篇3
PCI总线是一种与CPU无关的32/64位地址数据复用总线, 工作频率为33 MHz/66 MHz, 它支持突发传输, 具有即插即用、电源管理等功能[1,2]。PCI总线以其优良性能和可适应性成为现代微机的主流总线[3]。在开发PCI设备的过程中, 需要为PCI设备写驱动程序。Windows驱动程序模型 (WDM) 是Microsoft公司力推的全新驱动程序模式, 它支持PnP、电源管理和WMI等技术[4,5]。在Windows操作平台上, WDM已成为主流的驱动模型[6]。这里主要介绍根据工程背景开发的基于PCI总线的实时测频卡的WDM驱动程序设计。
1 实时测频卡硬件系统结构
实时测频卡的主要功能是实时测定信号频率, 实时识别信号调制方式。系统的电路框图如图1所示。外部待测信号通过SMA接口进入实时测频卡的ADC。ADC输出的数字信号在FPGA中缓存后进入DSP。在DSP内对信号进行粗估, 然后通过EMIF接口把转化为频率和相位控制字的粗估结果发给DDC。DDC做出调整后, 通过FPGA把移频和降采样后的信号输入给DSP。DSP依据粗估结果和DDC的数据进行实时测频。测频完毕后, 通过PCI总线向PC机发出中断信号。PC机响应中断, 读取DSP内指定位置内存处的测频数据。为简化PCI接口电路设计, 选用带有PCI接口电路的DSP芯片TMS320C6416。
2 TMS320C6416的PCI接口介绍
实时测频卡通过TMS320C6416的PCI接口和主机进行通信。该接口符合PCI 2.2规范, 能提供33 MHz总线时钟, 32 b数据宽度, 可达到峰值132 MB/s的数据带宽。PCI接口包括配置寄存器、I/O寄存器和存储器映射寄存器[7]。图2给出了部分PCI配置寄存器。配置寄存器的主要功能如下[8]:
(1) 设备的识别、控制和状态指示。将供应商ID域、设备ID域、版本域、配置头类型域、分类代码域这五个域用于识别设备。所有的PCI设备必须设置这些域, 配置软件可利用它们来确定系统中可用的PCI总线设备。对于TMS320C6416芯片而言, 供应商ID为104CH;设备ID为A106H;其他三个域随不同的应用会有所改变。命令寄存器为发出和响应PCI总线命令提供粗略的控制。状态寄存器用于记录PCI总线有关操作的状态信息。
(2) 中断引脚寄存器的功能。01H～04H值对应于PCI中断请求引脚INTA #～INTD #。
(3) 基地址寄存器的功能。其功能是为PCI设备指定存储空间。PCI存储空间分为独立寻址的Memory空间和I/O空间两类。Memory空间适用于设备功能寄存器较多或数据流量较大的场合, I/O空间适用于设备功能寄存器较少或数据流量较小的场合。PCI接口拥有3个基地址寄存器BAR用于保存指向PCI存储空间的指针。图2为部分PCI配置寄存器。
① Base 0基地址寄存器 (BAR0) 。确定一个4 MB可预取的PC机内存地址空间。将DSP存储空间中不同的4 MB空间都映射到PC机内存相同的4 MB空间中。由DSP页寄存器 (DSPP) 设置该区域在DSP存储空间中的映射位置;用BAR0访问DSP内部的RAM和外挂的通过EMIFA和EMIFB访问的存储器空间。访问时每次最多只能读取DSP存储空间的4 MB内容, 并且需要定义DSPP寄存器, 以指定访问空间的起始地址。访问支持数据突发传输模式。这种映射方式只适用于DSP处于从模式。
② Base 1基地址寄存器 (BAR1) :确定一个8 MB不可预取的访问区间。对DSP芯片而言, 其访问地址固定在0180000H～0200000H的范围内。用BAR1来访问DSP内部所有的操作命令控制寄存器。
③ Base 2基地址寄存器 (BAR2) :定义一个16 B的PC机I/O空间, 用于访问PCI的I/O寄存器。BAR2加偏移00H, 访问主机状态寄存器HSR;BAR2加偏移04H, 访问主机对DSP控制寄存器HDCR;BAR2加偏移08H, 访问DSP页寄存器DSPP。
3 WDM概述
WDM (Windows Driver Model) 是一种遵循即插即用协议的内核模式驱动程序, 它是微软的全新驱动程序模式, 旨在通过提供一种灵活的方式来简化驱动程序的开发, 在实现对新硬件支持的基础上, 减少并降低必须开发的驱动程序数量和复杂性。在WDM中, 采用图3所示的分层驱动程序体系结构[6]。
在WDM模型中, 每个硬件设备至少有两个驱动程序:总线驱动程序和功能驱动程序。总线驱动程序由操作系统实现, 它在最底层直接与设备打交道, 负责管理硬件与计算机的连接;负责发现总线上所有的设备, 并检测设备何时添加到总线上或何时从总线上删除。设备功能驱动程序在上层通过与低层驱动程序打交道, 进行硬件操作, 以实现PCI设备的功能。中间还可以有类过滤驱动程序或设备过滤驱动程序用于修改和监视IRP (I/O请求包) , 实现数据的过滤或转换。一般在特殊的情况下才需要编写。在实际开发中, 只需要开发一个设备功能驱动程序即可。
WDM还引入了功能设备对象 (Functional Device Object, FDO) 与物理设备对象 (Physical Device Object, PDO) 来描述硬件。一个PDO对应一个真实的硬件, 一个硬件只允许有一个PDO, 却可以有多个FDO。在驱动程序中直接操作的不是硬件而是相应的PDO与FDO。当应用程序与WDM 驱动程序进行通信时, 系统为每一个用户请求打包, 形成一个I/O请求包 (IRP) 结构, 将其发送到驱动程序, 并通过识别IRP中的PDO来区别是发送给哪一个设备。IRP从驱动程序堆栈栈顶进入, 每层驱动再把I/O请求划分成更简单的请求, 以传给更下层的驱动执行, 最底层的驱动程序在收到IRP后, 通过硬件抽象层HAL与硬件发生作用, 从而完成I/O请求工作。内核通常通过发送IRP来运行驱动程序中的代码。
4 测频卡WDM驱动程序实现
在微软公司DDK工具的支持下, Compuware NuMega公司提供Driver Studio工具包中的DriverWorks将WDM驱动程序编写所需的对内核及对硬件的访问封装成类库, 加上驱动程序代码生成向导DriverWizard, 极大地简化了驱动程序的开发难度[9]。本文选择DriverWorks作为WDM驱动程序的开发工具。
测频卡驱动程序的主要功能是为用户读取所测信号的频率参数, 包括载频、调制方式、码元速率等。同时用户还能通过驱动程序发送命令对测频卡的工作方式进行控制。由此可知, 驱动程序要重点处理好硬件访问和中断处理工作。
4.1 I/O访问
类KIoRange封装了对I/O端口的操作。本卡中PCI配置寄存器中的Base 2基地址寄存器定义了I/O空间。在OnstartDevice例程中取得I/O资源, 并初始化, 其函数实现如下:
完成初始化后, 可以用成员函数inb, inw, ind从I/O端口读一个 (多个) 字节、字、双字的数据;outb, outw, outd向I/O端口写一个 (多个) 字节、字、双字的数据。
4.2 内存访问
在Windows系统中, 内存分为分页内存和非分页内存。在WDM驱动程序中, 对于硬件的内存映射一般需要用非分页内存。因为在一些较高级别的例程中, 使用分页内存会造成系统产生缺页中断, 从而引起死锁。使用非分页内存无需太多的转换, 非常安全, 效率也高。类KMemoryRange封装了对PCI设备映射内存的操作。类KMemoryRange成员函数的读/写操作同类KIoRange。由PCI配置寄存器中的Base 0和Base 1基地址寄存器分别定义了两个内存空间。在OnstartDevice例程中取得内存资源并初始化, 其函数实现如下:
4.3 中断处理
中断处理一般需要声明两种类实例:Klnterrupt和KDeferredCal1。Kinterrupt类用于实现硬件中断处理;KDeferredCall类用于实现延时过程调用。首先创建一个Klnterrupt类实例mIrq, 将此实例作为设备类的成员变量, 然后创建一个KDeferredCall类实例mDpcForIrq。mIrq对应的中断服务例程和mDpcForIrq对应的延时过程调用例程也需要在实例中声明。这两个实例mIrq和mDpcForIrq都是在OnstartDevice例程中初始化的, 代码如下:
中断服务例程的处理时间应尽量短, 对于一些耗时, 但不需要立即处理的任务, 中断服务程序会调用一个低于中断服务程序DIRQL级别的延迟过程调用程序DPC, 在DISPATCHLEVEL上完成处理, 这个级别上的限制较少, 函数调用也相对比较方便。在中断服务例程中, 首先判断中断是否是自己设备产生的, 若不是, 返回FALSE;若是, 进行必要的处理, 请求一个DPC (延时过程调用) , 然后返回TRUE。关键代码如下:
在延时过程调用例程DpcForIrq中, 读取所测信号的频率参数:
5 驱动程序与应用程序之间的通信
虽然驱动程序是为设备的硬件层编程服务的, 但同样需要提供和应用程序进行通信的能力, 从而最终达到应用程序控制设备的目的。应用程序与驱动程序之间的通信通过调用Win32 API来实现, 应用程序用Creatfile函数通过已经定义的设备接口来获取驱动程序文件句柄, 然后将文件句柄作为其他Win32 API函数的一个参数, 对驱动程序的进行数据操作。调用DeviceloControl进行数据量较小的, 如控制指令传输或端口、寄存器访问;调用ReadFile, WriteFile等函数进行数据量较大的传输, 如内存读/写等[10]。驱动程序与应用程序的通信有DeviceControl异步完成、共享Win32事件通知两种方式。Win32事件通知是由应用程序创建了一个事件后, 设置事件的状态为Unsignal, 然后直接将该事件句柄传递给驱动程序, 等待驱动程序发送事件通知。驱动程序通过类Kevent获取这个事件的一个对象指针后, 在IRQL≤DISPATCHLEVEL级别的例程中设置事件信号状态为Signal来通知应用程序进行后续处理[11]。
6 结 语
基于上述的硬件结构和驱动程序设计方法, 成功开发了一款实时测频卡, 在实际中得到了很好的应用, 板卡工作正常, 达到了预期效果。实践证明, DriverWorks是一款功能强大, 使用方便的驱动程序开发工具, 利用它可以方便快捷地构造PCI设备的驱动程序框架, 大大加快了开发周期, 提高了开发效率。
摘要：介绍实时测频卡的硬件结构及DSP芯片TMS320C6416中PCI接口部分的配置寄存器;简述WDM驱动程序的体系结构和基本原理。重点介绍采用Driver Works工具开发WDM驱动程序的方法;详细分析驱动程序设计过程中:I/O端口和内存的映射与访问, 中断处理, 以及驱动程序与应用程序之间的通信。实践证明, 采用自带PCI接口的DSP芯片可以简化设备PCI接口的软硬件复杂度, 降低开发成本, 同时与开发工具Driver Works相结合, 可以大大加快开发周期, 提高开发效率。
关键词：PCI,WDM,Driver Works,设备驱动程序,DSP
参考文献
[1]李贵山, 陈金鹏.PCI局部总线及其应用[M].西安:西安电子科技大学出版社, 2003.
[2]刘晖.PCI系统结构[M].4版.北京:电子工业出版社, 2001.
[3]尹勇, 李宇.PCI总线设备开发宝典[M].北京:北京航空航天大学出版社, 2005.
[4]Chris Cant.Windows WDM设备驱动程序开发指南[M].孙义, 马莉波, 国雪飞, 等译.北京:机械工业出版社, 2001.
[5]张惠娟, 周利华.Windows环境下的设备驱动程序设计[M].西安:西安电子科技大学出版社, 2002.
[6]武安河.Windows 2000/XP WDM设备驱动程序开发[M].2版.北京:电子工业出版社, 2005.
[7]李方慧, 王飞, 何佩琨.TMS320C6000系列DSPs原理及应用[M].2版.北京:电子工业出版社, 2003.
[8]Texas Instruments Inc.TMS320C6000 DSP Peripheral Com-ponent Interconnect (PCI) Reference Guide[Z].2007.
[9]Compuware Corporation.Using DriverWorks[Z].1998.
[10]魏先民.PCI总线高速数据采集卡及其驱动程序设计[J].微计算机信息, 2008, 24 (1) :85-86.
[11]孙健, 贾民平, 许飞云.基于PCI总线的数据采集卡WDM驱动程序开发[J].机电工程, 2007, 24 (12) :99-101.
实时程序 篇4
在社会经济快速发展的推动下,高层建筑的建设越来越多。而随着楼层的增加,建筑物的稳定性和安全性成为了人们关注的焦
为了能够实时获取建筑物的监测结果,对监测系统数据处理的自动化和实时化提出了新的要求
本文结合建筑物监测的特点,根据极坐标实时差分技术为核心的数据预处理方法设计并实现监测系统实施处理程序,该系统在使用中能够根据监测方案的要求定义监测的点组、频率、周期,软件自动对每周期的实时监测数据进行平差处理,获取最终的点位三维变形量、变形曲线以及多样的监测成果,指导施工的安全进行或者保证工程的安全运营。
本文首先介绍了该项目中建筑物的监测方案,然后根据监测方案对软件进行了设计并结合多种编程技术实现了实施数据处理程序,最后对系统进行了工程应用。
1 建筑物监测原理
1.1 监测点布设方案
由于该建筑物还处于施工阶段,所以应该根据工地现场情况设计和调整监测方案。在监测区域现有3个观测墩作为施工监测的控制点,在建筑物上布设多个监测点(如图1所示)。在此项目中,采用极坐标法进行测量。
图1 观测方案示意图Fig.1 Observation plan diagram
1.2 差分数据处理原理
由于施工工地条件的限制,在本系统中主要采用差分技术对数据进行处理。应用多重实时差分技术必须保证测站点与参考系处于一个稳定的状态,因为测量得到的基准点数据将作为目标点差分改正的基准
差分数据处理包括距离差分改正、高差的差分改正和方位角的差分改正,差分改正完成后就可以用改正后的距离、角度等值来计算监测点的三维坐标。
关于差分改正的具体技术原理,在文献
设
式(2)中,(X0,Y0,Z0)为测站点三维坐标值。
如果以第一周期变形点坐标值(Xp1,Yp1,Zp1)作为初始值,那么各变形点相对于第一周期的累计变形量ΔXp、ΔYp、ΔZp计算公式如式(3)所示:
2 程序设计与实现
2.1 程序开发平台
本系统以Microsoft Visual Studio 2010作为编译器,采用SQlite数据库,配合NPOI技术联合开发。Visual Studio 2010具备.NET Framework 4.0和Microsoft Visual Studio 2010 CTP(Community Technology Preview),支持开发面向Windows的应用程序,并且还支持多种数据库。
为了确保数据组织、存储及调用的高效和准确性,使用SQlite作为本系统的数据库。SQlite是一款轻型的数据库,是遵守ACID的关系型数据库管理系统,它的设计目标是嵌入式的,目前已在很多嵌入式产品中使用,它占用资源非常的低,在嵌入式设备中,可能只需要几百KB的内存就够了。它能够支持多种操作系统,同时能够跟很多程序语言相结合,比如C#、PHP、Java等,还有ODBC接口,同样比起Mysql、Postgre SQL这两款开源世界著名的数据库管理系统来讲,处理速度较快。使用SQlite数据库方法比较简单,只需要引用SQlite的一个动态链接库文件System.Data.SQlite.dll。为了实现图表显示和报表输出功能,系统还使用了基于.NET的开源图标类库Zed Graph和支持Excel、Word等OLE2文档读写功能的NPOI技术。
2.2 数据处理模块设计
数据处理模块是在数据采集的基础上的连续开发,数据采集部分主要是控制智能全站仪按照需求自动、周期性采集数据并按照相应的限差参数控制数据采集的质量。数据处理部分则是对采集到的合格数据进行处理,实时得到变形量。根据业主要求,数据处理模块不仅能够实时显示其变形量,而且能够显示其日变化量、周变化量及任意时间区间的变化量。此外,最后还应该按照规定格式输出Excel报表作为测量成果提交。图2所示为数据处理模块总框架图。
图2 数据处理模块框架图Fig.2 Data processing module frame
2.3 程序实现
在程序设计和算法原理等基础上,结合SQlite数据技术、开业图标类库Zed Graph技术及支持Excel、Word等OLE2文档读写功能的NPOI技术,利用C#语言在Microsoft Visual Studio.net平台开发实现了该软件。
该程序可以实时显示监测点的变形曲线,而且可以根据用户需求选择任意时间区域内的变形曲线。另外程序依据NPOI技术实现了Excel报表输出功能,可以根据用户需求输出日报表、周报表、月报表及任意时间区域的报表,并且按照规定格式输出原始观测数据手簿。
3 工程应用
在数据处理模块开发完成后即与数据采集部分构成了一个完整的自动变形监测软件,该软件用于广州某超高层建筑物施工监测中。该建筑物拟建成高度500余米,建筑物占地面积两万余平方米。按照第1节中所述,在建筑物相应特征部位布设监测点,监测点上均安装有合作目标棱镜,测量仪器为徕卡TM50智能全站仪,数据采集由软件控制智能全站仪完成,数据采集部分设有限差检核机制,用户可以根据需求选择相应的限差,也可以自定义输入限差,以保证数据采集的质量。
数据采集完成后数据处理模块会根据差分技术原理首先对数据进行预处理,然后以第1期数据为基础,计算后面各期相对于第1期的变形量并通过变形曲线直观显示,用来指导工程管理人员制定下一步的工作计划。软件提供变形点的变形曲线及二维点位变化图,该结果可以为施工安全提供必要的保障。如图3所示分别为监测点X方向((a))、Y方向((b))、Z方向((c))的变形曲线,同时图中右上角部分为点位变化轨迹图,可以通过该图判断点位的变形趋势。
图3 变形曲线显示界面Fig.3 The display interface of deformation curve
该程序中数据处理程序主要是利用了差分改正的方法,为了验证该数据处理方法的可靠性,在监测站和监测点部位安置气象站,且每次观测前对仪器进行归零校准操作,然后对采集到的原始数据进行温度气压改正并计算变形量,将其结果与本文中差分改正结果进行比对,结果显示两种方法反映出的变形趋势一致,变形量最大差值在±1mm以内,可以满足项目的监测要求。
4 结语
本文的主要创新点是利用多种编程技术实现了超高层建筑物实时监测数据处理程序,该数据处理程序不仅能够控制测量机器人按照相应要求进行数据采集,而且能够对监测数据进行实时处理并且直观地显示其变形曲线,为工程管理人员提供参考,大大提高了工作效率。通过工程实际应用,表明该程序不仅能够稳定运行满足工程的需要,而且具有良好的可操作性和适用性,为建筑物施工提供了有力的保障。
摘要：本文介绍了高层建筑物施工监测方案,提出了以差分技术为基础的数据预处理方法并基于此原理利用SQlite数据库技术和ZedGraph图像显示技术编写了数据处理程序。该数据处理程序是在数据采集程序基础上开发,与数据采集模块完美结合,可以实时显示监测点的变形曲线及点位轨迹图,指导工程管理人员和施工人员开展进一步工作,保障了施工安全有序的进行。
关键词：超高层建筑,差分技术,变形曲线,实时监测
参考文献
[1]独知行,靳奉祥,冯遵德.高层建筑物整体变形监测及分析方案[J].工程勘察,2000,(2):55~57.Du Zhixing,Jin Fengxiang,Feng Zunde.The overall deformation monitoring and analysis solution of high-rise building[J].Geotechnical Investigation&Surveying,2000,(2):55~57.(in Chinese)
[2]梅文胜,张正禄,黄全义.测量机器人在变形监测中的应用研究[J].大坝与安全,2002,(5):33~35.Mei Wensheng,Zhang Zhenglu,Huang Quanyi.Research on application in deformation monitoring with georobot[J].Dam and Safety,2002,(5):33~35.(in Chinese)
[3]独知行,靳奉祥,吴庆忠.高层建筑物整体形变的GPS监测[J].工程勘察,2002,(4):45~49.Du Zhixing,Jin Fengxiang,Wu Qingzhong.The overall deformation GPS monitoring of high-rise building[J].Geotechnical Investigation&Surveying,2002,(4):45~49.(in Chinese)
[4]花向红,于中伟,蔡华.建筑物倾斜与沉降监测结果综合分析[J].地理空间信息,2009,(2):120~121.Hua Xianghong,Yu Zhongwei,Cai Hua.Analysis of construction’s safety and construction declivity survey[J].Geospatial Information,2009,(2):120~121.(in Chinese)
[5]丁宁,孙英君,崔健等.高层建筑物变形监测数据处理与分析[J].测绘科学,2011,36(5):93~95.Ding Ning,Sun Yingjun,Cui Jian et al.Data analysis of foundation settlement of high-rise high-rise buildings[J].Science of Surveying and Mapping,2011,36(5):93~95.(in Chinese)
实时程序 篇5
随着高级编程语言和操作系统在越来越多种类的CPU构架上的应用，系统应用程序变得越来越大，越来越复杂。并且实际应用大多对于程序的设计周期、可靠性都具有很高的要求。基于传统的嵌入式实时操作系统的软件设计，虽然可使程序的实时性能得到提高，但是并行程序设计过程中存在着更多的竞争状态，而且这些竞争状态极难被发现。如何能够找到一种符合软件工程学的程序设计方法成为每个嵌入式软件工程师所面临的问题。
传统的实时操作系统虽然可以完成任务管理，但是往往代码量较大，任务切换要求复杂，完全摒弃编译器提供的程序调用机制，采用任务堆栈机制，接口程序设计要求高，实现任务切换时占用资源较大，不适合应用于8位和16位总线构架的CPU上。
另一方面，基于UML的实时框架程序设计方法对于当今的高复杂性、短开发周期的商业环境来说变得越来越重要。主要是因为UML语言是可执行的，所以根据UML建立的系统行为模型可以生成可执行代码，从而节约了从抽象模型到手工编写可执行代码的费时、费力的工作量[1]。但是所有的UML代码生成工具是为类似PC上应用而设计的，不适合应用于中小型的CPU，且售价昂贵。
如果将RTOS的实时性与UML模型设计的直观性、安全性和便捷性相结合，应用于中小规模的CPU芯片无疑会给深度嵌入式系统开发带来更多的手段。
1 实时UML框架程序设计平台（QP）简介
QP是使用实时抢占式任务管理内核、基于UML状态图的软件设计方法的轻量级软件平台[2]，是一种新式操作系统[3]。QP软件平台结构如图1所示由以下4个部件组成。
1.1 任务管理内核（QK)
QK也采用了类似其他商业内核的优先级的抢占机制以保证关键任务得到实时执行。但是QK实现抢占的原理有别于任何一种操作系统。QK采用的是Moore状态机的“运行到结束”的机制，因此当系统还在忙于处理前较低优先级事件时，当较高优先级的事件到来时，系统将新事件存储在消息队列中，直到低优先级事件完成后，再执行新事件[2]。QK的实现原理不同于传统RTOS的堆栈操作，仅使用C语言编译器的中断服务程序(ISR)机制就可完成。也就是QK的移植完全不需要插入额外的汇编语句。所以，任务切换时没有额外的开销，执行速度快，相当于子程序调用[1]。当然如果使用其他RTOS的任务管理功能也能代替QK，稍候在QP到TMS320LF2407的接口程序设计部分介绍。
1.2 基础框架平台
该框架平台完成了驱动事件管理功能、状态机架构管理和实时任务管理功能。
实时UML框架序设计平台(QF)中任务是由能实现轻量级UML状态机和用来接收触发事件的消息队列组成。因此基于实时UML框架的任务具有UML状态机的特点[1]。QF将任务分为激活状态和休眠状态，QF根据触发事件和任务优先级对其进行管理。实际工作时任务间采用异步的事件发送和接收机制进行通信。任务使用消息队列接收其他活动对象的事件消息;同时，不同任务产生的事件也会利QF投送给其他订阅该消息的任务。对于触发事件的交换，排队，收集，销毁等工作则由QF统一完成[3]。可见，任务间通过QF框架进行间接通信，实现了事件松耦合。因此，基于QF的程序设计可以采用模块化的设计方法，给设计过程中方案的修改和设计后期的软件维护提供了极大的方便。正像使用UML的自动设计工具软件进行程序设计的过程一样，使用QF的程序设计也遵循以下过程：使用UML语义进行模型设计，根据QP平台代码转换方法将UML模型转化为源代码。
总之，基于QF的程序设计实现了可视化程序设计和“自动”代码生成的目的;另外，在嵌入式系统中也可以将QF当作为一个软件总线，将QF的接口移植到其他OS之上，以隐藏下层硬件和软件的差异[3]。
1.3 状态机部件（QEP)
上节提到的QF任务的状态机的特性是由状态机部件(QEP)完成的。QEP是一个简化的轻量级的UML状态机部件，实现了状态机的状态转换触发事件响应等功能。QEP提供了两种状态机类型：层次化状态机(HSM)和平面状态机(FSM)[1,3]。
1.4 跟踪调试器（QSPY)
QSPY使用缓存机制采集系统内运行状态，事后在空闲任务时再编码输出，再有在整个QP平台中QSPY调试插件有机的与系统关键运行环节有机的结合在一起，因此基于QSPY的调试可以获得更多的系统的信息的同时又不会过多地干扰程序的正常运行。在这一点上比传统RTOS中的跟踪调试器更领先一步[1]。
2 QP到TMS320LF2407的接口移植
QP存在C和C++版本[3]。基于C语言版本的精简版QP平台的代码量可以在4 KB左右，可以轻易的放入到大多数的小规模CPU的片上存储器中。并且该平台的实现原理如上节所述可以使用C编译器实现[4]，因此移植工作量极少，仅需几十行的C语言程序就可完成。显然在诸如TMS320LF2407的中小型的CPU上更适合使用基于C的版本。QP移植主要的工作集中在改写qep_port.h,qf_port.h,qf_port.c,qk_port.h和qs_port.h这4个文件。
2.1 QEP的接口移植
QEP完成了状态机的实现机制。配置和移植QEP需修改qep_port.h头文件中关于各种数据类型和主要参数的定义。其中主要的有Q_ROM,Q_ROM_VAR和QEP_SIGNAL_SIZE三个宏定义。Q_ROM宏是用来定义常变量到程序存储区域的，比如使用较大的表或数组等常数时不希望占用RAM资源时，将其定义在程序区，可以使用Q_ROM宏。定义方法根据不同的编译器而不同，比如在Keil C51中Q_ROM被定义为code关键字。Q_ROM_VAR宏用来定义如何采用指针类型取程序存储器变量。QEP_SIGNAL_SIZE宏用来定义信号宽度，通常为1,2或4。针对TMS320LF2407的硬件结构特点定义了8位、16位和32位有符号和无符号数的类型。
2.2 QF的接口移植
QF的移植主要集中在对于状态机和任务管理方面。在qf_port.h中根据实际的软件需求修改状态机实现相关的定义，例如触发事件的类型、事件队列的深度和事件缓存的容量。QF中事件初始位置存放在事件缓存区中，所有的任务间的事件传递使用指针方式进行，从而有效地减少了事件传递对内存的开销。任务管理方面定义了最大任务数、中断嵌套相关的定义以及任务切换的机制。
在pf_port.c中需要编写有关诸如QF平台开始和退出代码，如无特殊需要这些函数可以使用空函数代替。QP平台中对于程序的运行关键位置使用了断言手段进行约束，在平台运行异常时会给出诊断信息。在pf_port.c的Q_assert_handler()函数可以返回平台错误信息。
2.3 QK的接口移植
QP平台的任务调度机制在QK中完成。因此QK的移植需要根据TMS320LF2407的编译工具进行接口函数的设计。所有调度相关的定义在qk_port.h头文件中。其中主要的是中断相关的定义，如：开关中断的机制和中断响应程序的进入和退出机制等。
QK中使用QK_INT_KEY_TYPE,QK_INT_LOCK(key_),QK_INT_UNLOCK(key_)三个宏接口定义了中断开关机制。其中QK_INT_KEY_TYPE定义了中断嵌套时中断优先级传递参量类型。QK_INT_LOCK(key_)定义了关中断的机制，QK_INT_UNLOCK(key_)定义了开中断的机制。在TMS320LF因为在TMS320LF2407的C编译器中没有直接对ST0、ST1寄存器进行操作的方法[4,5]，此处使用嵌入汇编实现中断使能和中断禁止功能[6]。还有，在TMS320LF2407中具有中断优先级管理器，因此中断传递参数类别QK_INT_KEY_TYPE在本移植中不用定义。
QP中中断服务程序相当于最高优先级的任务，因此中断的进入动作QK_ISR_ENTRY()和退出动作QK_ISR_EXIT()需要特殊规定：QK_ISR_ENTRY(pin,ISR_PRIO)：首先是，将当前QK优先级保存到变量pin上;然后将当前QK的优先级ISR_PRIO改变为最高优先级别;最后使能中断。QK_ISR_EXIT(pin)中断服务程序退出动作的过程是：关中断，清中断寄存器结束中断标记，从变量pin中恢复以前的优先级，调用QK的任务切换函数进行任务调度。
需要注意，TMS320LF2407中断有2种类型：一种由事件管理模块管理，不需要使用程序清中断标志位，如定时器，计数器，PWM等设备;另一种需要任务清中断标记，如串行外设接口(SPI)、串行通信接口(SCI)、CAN总线等。所以在中断退出时需要分别处理，一般在BSP中进行。
2.4 QS的接口移植
QS完成了软件系统运行信息的收集和输出功能。QS移植需要修改qs_port.h文件。其中定义了系统信息缓存区的深度，定义了在空闲时系统信息的输出方式等。
3 基于QP的航天相机控制器控制软件的实例
通过上节所述的构建过程QP平台被移植到了TMS320LF2407上，下面通过某航天相机控制器的控制软件的设计实例说明基于QP的软件架构设计[7]过程和实际运行结果。
3.1 基于QP的航天相机控制器的软件设计
基于QP平台的软件设计过程完全采用UML的图形可视化方法。使用用例图分析软件任务、需求。使用类图描述软件架构。使用活动图或顺序图描述软件结构中的对象间的消息交换细节。使用顺序图与状态图描述软件系统对象间的行为转换[8]。如图2中描述了航天相机控制器软件总体架构的状态转换图[9]。
其中分为4个状态，正常工作时系统在程控模式和正常模式间转换，触发信号为程控结束和E5.4信号。在正常模式内部又有工况参数轮询和摄像2种模式，通过相应的触发信号系统在两种状态间转换。另外E5.1.1到E5.1.7信号为内部转换触发信号。
3.2 软件源程序的生成
在QP中有关状态机的所有的要素，如状态、层次状态、状态转换、输入事件触发和输出事件触发均可以对应为固定的源代码，在将活动对象转化为源代码时几乎无需编程人员的参与。例如，对于状态机中的状态，QP中使用带有事件参数指针的函数来表示，其返回值指向另一个QP状态。对于信号的传递采用指针消息队列来表示[10]。
3.3 控制器软件的测试结果
由于使用了QS动态调试手段，所以可以在最为接近全速运行的状态下收集软件运行信息。如图3所示控制器采集模拟量工况参数场景的实测各个触发事件发生的时间信息，时间刻度为1μs。
如图3中所示模拟量遥测任务在t1时刻执行，采集系统内的模拟量参数。采集完成后在t2时刻向系统“发布”数据信号量。在t4时刻“订阅”了数据信号的数据合成任务得以执行。在数据合成任务以某种方式对数据打包编码后，在t5时刻向系统“发布”打包后的数据消息。最后通讯任务在t6时刻，将打包数据通过数据链路输出。对于模拟遥测任务，t1为任务执行的起始时刻，t3为任务结束时刻，任务执行时间可由下面表达式(1)来描述。
将图3中的时间代入式(1)，可得到遥测任务的执行时间。
根据上面的测量方法可以统计一个软件运行周期内所有任务的执行时间，下表是本相机控制器软件在2 s的运行周期内，常规工况下，所有任务执行时间的统计结果。
通过上表可见，QP平台完成了软件中各个任务的管理工作，但是QP平台对于系统资源的占用时间极少。另外采用速率单调调度[1](RMS)算法可以看到本应用软件是完全可调度系统。通过上面讲述的工作后，证明整个系统已经能够正常运行，移植成功。
4 结论
综上，QP下的程序设计完全是基于可视化的UML状态图方式，因此提高了程序设计的效率，缩短了设计周期，并且减少了不确定的、无法预测的状态从而加强了软件的安全性;QP的实现原理有别于传统的RTOS，因此QP具有紧凑的代码结构，代码量小，QP的代码量非常少，即使是在所有的功能都被使能的情况下也只有4 K左右[1]，更适合于深度的嵌入式系统。
因此，在完成了QP平台在TMS320LF2407上的构建的同时也证明了基于实时UML状态机的应用软件是完全可以在中小型CPU上运行的。
摘要：为了能够同时在16位或8位中小型CPU上使用实时操作系统和基于UML的可视化图形程序设计方法进行应用程序设计,在此详细讨论了将一种新式嵌入式实时UML框架程序设计平台移植到TMS320LF2407上全部过程,通过状态机部件、基础框架、任务管理内核和跟踪调试器的移植证明了这种平台在中小型CPU上运行的可行性、便捷性和高可靠性等优点。最后,通过航天相机控制器应用程序设计实例中各个任务线程的执行时间测量结果及可调度结果进一步验证了该平台的实用性。
关键词：RTOS,框架式程序设计,TMS320LF2407,平台移植
参考文献
[1][美]DOUGLASS B P.嵌入式与实时系统开发:使用UML、对象技术、框架与模式[M].柳翔,译.北京:机械工业出版社,2005.
[2]Quantum.Platform programmer’s manual[EB/OL].[2006 1120].http://www.quantum leaps.com.
[3][美]Miro Samek.嵌入式系统的微模块程序设计:实用状态图C/C++实现[M].敬万均,陈丽蓉,译.北京:北京航空航天大学出版社,2004.
[4]刘和平,王为江.TMS320LF2407 DSP C语言开发应用[M].北京:北京航空航天大学出版社,2003.
[5]Texas Instuments.TMS320C2x/C2xx/C5x optimizing c compiler user's guide[R].US:Texas Instuments,1999.
[6]Texas Instuments.TMS320F/C240 DSP controllers peripheral li brary[R].US:Texas Instuments,2002.
[7]柳翔.嵌入式与实时系统开发:使用UML、对象技术、框架与模式[M].北京:机械工业出版社,2005.
[8]RUMBAUGH James.The unified modeling language reference manual[M].New York:Addison Wesley Professional,2004.
[9]刘辉,李云飞.嵌入式航天CCD相机控制器研制模板[J].现代电子技术,2011,34(11):63-69.
[10]刘辉.嵌入式空间遥感相机控制器设计方法与实现[D].长春:中国科学院长春光学精密机械与物理研究所,2010.
实时程序 篇6
目前, 国内大多数高校都开设了面向非计算机专业学生的程序设计类课程, 不同高校只是所开设程序设计课程的语种以及开设范围有所差异, 多数高校会结合不同专业的需求, 开设多门程序设计课程。我校结合不同专业的需求, 开设面向非计算机专业学生的程序设计类课程主要有《VB程序设计》、《Delphi程序设计》和《C/C++程序设计》3门课程。
1 现状分析
程序设计类课程是实践性很强的课程, 学生不仅需要掌握程序设计的理论知识, 还必须经过大量的实践训练, 以培养其程序设计的思维能力和运用编程解决相关专业领域问题的能力, 而这些能力的培养, 主要源于实验课的教学。然而, 从程序设计类课程的多轮实验教学情况来看, 总体的教学并不十分理想, 主要表现在以下几个方面:
(1) 实验教学被视为理论教学的辅助手段, 通常是以验证和加深理解课堂理论知识为目的, 而忽视学生的编程设计能力培养, 导致学生程序设计和调试能力很差。
(2) 学生对实验缺乏积极性和主动性, 实验前准备不充分, 课内没有完成的实验下课不会继续完成。
(3) 由于学生人数众多, 指导教师不可能及时了解每一个学生的实验完成情况。另外, 实验成绩的评价主要是评阅实验报告, 不仅工作量大, 而且部分学生的实验报告存在抄袭和敷衍的现象, 不能反映学生的真实水平。
为了培养学生的程序设计能力, 极大地激发学生学习程序设计的积极性, 针对程序设计类课程实验的特点, 在实验课中引入“实验评测系统”, 对学生完成的程序进行现场收集和自动评分, 从而实时掌握学生实验完成情况, 不仅将教师从低层次的批改实验报告的繁重工作中解脱出来, 而且大大提高学生的学习主动性和积极性。通过实践检验, 实验课程改革取得良好的效果。
2 项目特点
2.1 研制可视化程序评测方案, 组建“实验评测系统”
为了及时、准确地反馈学生的程序设计作业, 同时减轻教师手工评阅学生程序的繁重工作, 把更多的精力投入到教学环节中, 借鉴开放源程序的Cena评测系统, 并根据本校实验教学环境及学生程序评测的需求, 对系统进行功能扩充, 设计了可视化程序的评分程序, 从而实现对Visual Basic程序、Delphi程序以及C/C++程序进行程序代码收集、程序评测、统计分析等功能, 满足程序设计类课程实验教学需求。该评测系统具有如下功能特点:
(1) 通过局域网自动收取学生程序, 普通计算机即可满足需求, 无需功能强大的服务器, 教师在教师机可以查阅学生的源代码;
(2) 能够实现对VB程序、Delphi程序以及C/C++程序按“测试点”进行自动评测, 通过控制台可以实时、准确地了解学生的实验情况;
(3) 能准确测出学生程序的运行时间和内存使用量, 并可加入对运行时间和内存使用的限制;
(4) 自动找出学生程序错误的原因, 并指出出错的具体位置;
(5) 可对评测结果进行统计分析, 并可将评测结果以各种样式打印或导出。
2.2 改革实验教学模式, 实时全面掌握学生的实验情况
在程序设计类课程的实验教学的传统方式中, 教师按照实验教材布置相应的上机题, 提前将实验过程中可能遇到的问题进行讲解, 对解题思路加以提示, 之后学生独自上机编程, 遇到问题请教师分别解答。但这种实验教学模式在教学中存在以下问题: (1) 学生过分依赖老师的解答; (2) 老师重复解答类似的问题。
为了解决这些问题, 通过引入“实时检测, 及时反馈”的多媒体双向实验教学模式。在实验课中引入“实验评测系统”在实验过程中实时收集各个学生的编写的程序, 通过评测系统快速评测每位学生的程序, 查看和统计来实时掌握学生在完成实验题目过程中存在问题, 然后通过“大屏幕”和凌波教学软件对实验中存在的共性和典型问题予以集中指导和答疑。
“实时检测, 及时反馈”的多媒体双向实验教学模式的优越性:
(1) 教师无需在实验过程中奔波于学生之间, 只有在教师机就可以实时查阅学生的源程序, 发现学生的实验问题。
(2) 通过实验评测平台可以及时地统计出学生在实验中存在的共性和典型问题, 然后通过“大屏幕”和凌波教学软件予以集中指导和答疑, 从而避免对每个学生进行重复性的解答, 减轻教师低层次重复性工作, 提高实验指导效率。
(3) 通过实验评测平台可以及时了解到实验项目完成情况, 包括完成的人数、正确率以及错误情况等信息, 教师就可以根据这些信息适当调整后续实验题的难度和数量。
3 革新实验考核方案, 调动学生实验的积极性和主动性
合理的实验考核方案, 有利于提高学生学习的积极性和主动性, 有利于提高学生的解决实际问题能力和创新素质培养。传统的实验考核是教师在实验课后根据学生提交的源代码和实验报告, 通过人工评阅的方式给出成绩。在这种考核模式下, 学生抄袭实验报告、复制源代码情况严重, 而且教师每次实验要批改大量纸质实验报告, 不仅工作量大, 而且难以定量评价学生程序的质量。显然, 这种考核方式严重打击了学生的积极性, 不利于对学生创新能力的培养, 阻碍他们独立思考的兴趣和努力钻研知识的热情。
为此, 不再延用传统人工评阅方式, 对每个实验项目按知识要点分配分值, 为每个实验项目配置评分程序和测试数据, 在实验课结束前10分钟对所有学生的提交的程序进行快速评测, 然后生成该次实验的评测结果Exce报告, 报告中详细记录每位学生的得分情况以及每题完成情况。这种实验考核方案不仅将教师从低层次的批改实验报告等繁杂的工作中解脱出来同时增强了批改的准确性, 降低教师重复性、简单性工作量, 教师专注于教学设计和教学方法及教学效果上, 集中精力思考如何上好每一堂课, 不断精华课程内容, 不断推进教学改革;而且在分数驱动下, 大大提高了学生的实验积极性和主动性, 实验出勤率达到98%以上, 提高学生了动手编程能力。
4 取得的成效
实验评测平台首次在全校2011级《VB程序设计》、《Delphi程序设计》和《C/C++程序设计》课程的实验教学中全面使用, 并取得巨大成功, 实验课出勤率达99%以上。该平台的应用大大激发了学生的实验兴趣, 提高学生学习的积极性和主动性, 培养学生的自学能力和动手编程能力;同时把教师从繁重的代码评阅和报告批改中解脱出来, 把更多的时间投入到教学环节中。
通过程序设计类实验教学改革与实践, 全校每年将有近4500名学生受益, 激发学生的学习兴趣, 培养学生的自学能力, 促进学生从“依赖型”向“独立型”学习角色转换, 切实提高学生的编程能力、分析问题和解决问题的能力, 为学生运用计算机解决本专业领域的问题打下良好的基础。
5 改进方向
目前, 我们的评测系统只是针对每位老师上实验课时所在的实验室范围, 仍然存在一个实验班的学生位于不同的实验室, 而老师必须在不同的实验室去部署、收集学生的实验结果的情况;另外, 对于不同实验班级的学生, 即便是同一位老师讲授课程, 对同一个问题的求解也不尽相同, 如何让学生间有更好的交流、比较, 从而进一步激发他们学习的动力也是下一步需要改进的一个方向;随着校园网规模和功能的逐步完善, 如何更好地利用这个平台, 使得学生实验课的作业 (作品) 延续到他的课余生活中, 通过课外的交流与实践进一步巩固课堂上所有的计算机技能, 真正做到学以致用, 发挥计算机在学生专业知识学习所起的作用。本成果是校高等教育教学改革重点项目《福建农林大学本科专业公共基础类课程教学内容和课程体系改革与实践》的分课题《计算机公共基础类课程教学内容和课程体系改革与实践》 (011904073) 的主要研究成果。
摘要：高校计算机公共基础课的设置是为了培养尤其是非计算机专业学生逻辑思维和逻辑推理的能力、分析问题和解决问题的能力、创新意识和创新能力。在程序设计类课程教学过程中十分注重实践能力的培养, 但是传统的实验教学方式存在诸多不足, 针对这些问题, 我们引入了实时评测系统来改进实验课程效果。
关键词：实时评测系统,非计算机专业,课程实验
参考文献
[1]朱利娜.注重加强非计算机专业大学生计算机应用能力的培养[J].高等教育研究学报, 2007.
[2]崔益安, 李潇晨.项目教学法在非计算机专业计算机课程教学中的应用[J].当代教育论坛, 2010.