(计算机应用技术专业论文)嵌入式板级支持包通信平台研究与实现.pdf_第1页
(计算机应用技术专业论文)嵌入式板级支持包通信平台研究与实现.pdf_第2页
(计算机应用技术专业论文)嵌入式板级支持包通信平台研究与实现.pdf_第3页
(计算机应用技术专业论文)嵌入式板级支持包通信平台研究与实现.pdf_第4页
(计算机应用技术专业论文)嵌入式板级支持包通信平台研究与实现.pdf_第5页
已阅读5页,还剩56页未读 继续免费阅读

(计算机应用技术专业论文)嵌入式板级支持包通信平台研究与实现.pdf.pdf 免费下载

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

华中科技大学硕士学位论文 i 摘 要 计算机技术的飞速发展使嵌入式系统得到了广泛的应用,板级支持包(bsp: board support packet) 作为嵌入式系统开发和调试的重要工具, 其通信功能尤其重要。 随着板级支持包通信方式逐渐向多样化方向发展,设计独立的通信平台,提供统一 的通信接口,将有助于增强系统可扩展性和可移植性,缩短系统的研发周期。 在分析常见 b s p 与宿主机通信方式的基础上, 实现了一个分层式、模块化的通信 平台。通信平台通过标准的接口向板级支持包和主机软件提供通信服务,屏蔽了通 信设备硬件操作细节,增强了上层软件的可靠性及独立性。通信平台由设备端通信 模块和主机端通信模块两大部分组成。 设备端通信模块为板级支持包提供通信接口。整体架构通过分层式设计,分为 设备抽象层和设备驱动层。设备抽象层为上层应用程序提供了一套标准的、与设备 无关的通信接口,并且通过文件描述表、设备描述表和驱动描述表建立了从通信接 口到设备驱动的映射。 主机端通信模块利用面向对象的设计方法,实现了一个通信类库,包括通信接 口父类和派生的通信子类。通信接口父类定义了通信的标准接口,通信子类通过继 承及重载方法实现具体的通信操作。 在实现上述通信模块的基础上,搭建了测试环境,对通信平台的功能和性能进 行了测试及改进。最终的测试结果表明,通信平台可以为板级支持包和主机软件提 供高效、可靠的通信服务。 课题的研究成果为嵌入式板级支持包及主机软件提供了一个具有良好可移植性 和可扩展性的通信平台。分层式的设计思想使得板级支持包和主机软件之间的通信 更加可靠、高效;同时,模块化设计使通信平台可以方便移植到不同的硬件平台之 上,为进一步的研究工作提供了保障。 关键字:嵌入式系统,板级支持包,通信平台,设备抽象层 华中科技大学硕士学位论文 ii abstract embedded system has been widely used with the rapid development of computer technology, bsp(board support packet),as the important tools for development and debug of embedded system,communication function is more and more important. as bsp s communication method develope towards versatile direction, designing individual communication platform, providing uniform interface will benefit enhancing expandibility and portability, and reducing development period. after the analysis of communication mode between usual bsp and host, this article implements a layer- stepping and modularized communication platform, which provide communication service for bsp and host software, and mask hardware operation details of communication device, as a result, the reliability and independence of upper_layer software are enhanced. the platform is made up of two parts: communication module of device and communication module of host. the module of device provides interface function for bsp, the whole architecture is divided into two layers: device abstract layer and device driver layer. the device abstract layer provides a set of standard communication interface functions unrelated with specific device, which is mapped to device drivers by file table,device table and driver table. the module of host is a class library that includes communication interface class and subclasses, designed by the object- oriented method. the interface class defines standard interface of communication, the subclasses realize communication operations. after the implementation of modules above, test environment is constructed, the function and performance of platform are tested and improved. the test result indicates that communication platform can provide high efficient and reliable service for bsp and host software. research of this issue provides a communication platform with good portability and expandability for embedded bsp. thoughts of step- layerring make the communication between bsp and host software more reliable and efficient; modularized design make it easy to port the platform to different system, and guarantee the more research work. key words: embedded system, bsp, communication platform, device abstract layer 独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研 究成果。尽我所知,除文中已经标明引用的内容外,本论文不包含任何其他个人或 集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和集体,均已在 文中以明确方式标明。本人完全意识到,本声明的法律结果由本人承担。 学位论文作者签名: 日期: 年 月 日 学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定,即:学校有权 保留并向国家有关部门或机构送交论文的复印件和电子版,允许论文被查阅和借阅。 本人授权华中科技大学可以将本学位论文的全部或部分内容编入有关数据库进行检 索,可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。 保密,在_年解密后适用本授权书。 不保密。 (请在以上方框内打“”) 学位论文作者签名: 指导教师签名: 日期: 年 月 日 日期: 年 月 日 本论文属于 华中科技大学硕士学位论文 1 1 绪论 1.1 课题背景 嵌入式系统开发初期,硬件驱动测试和开发、核心引导和装载、目标板与主机 通讯和控制等将是开发的主要任务1。板级支持包(bsp)是一套能够独立运行于硬 件开发板的小型系统,它将负责目标板的初始化和提供对板上硬件操作的支持2- 4, 为操作系统及应用软件的开发提供一个良好的开发调试环境5- 6。 目前,bsp 与主机通信主要有串口、网口或 usb接口三种方式。串口的优点是 简单,易于实现,而且 pc 机上一般都有一个或多个串口,缺点是通信速度较慢,不 利于大批量数据的传输(如系统内核的烧写) ;usb接口速度快,可靠性高,但传输 距离有限7- 9;而通过网口进行通信不仅速度快、可靠性高,而且在移植了 tcp/ip 协议栈后,通过网口可以连接到局域网或广域网上进行远程操作,实现网上硬件测 试、网上升级、更新等非常实用的功能。然而,运行 tcp/ip 协议栈要占用额外的系 统资源(cpu、内存等) ,无法满足一些资源比较紧张的系统的要求,这三种方式各 有优点,可以互为补充,配合使用。 bsp 的开发和移植中,设备驱动的开发和移植占有很大的比重,上层应用和设 备驱动结合紧密10- 12,往往硬件平台发生变化时,设备驱动和上层应用都要进行重 新开发,bsp 的可移植性比较弱。另外,bsp 与主机通信的方式与嵌入式系统硬件 配置有很大的关系,当硬件平台采用新的通信方式时,也会给 bsp 的开发带来额外 的开销。 本课题属于项目“嵌入式板级支持包”的一部分,该项目由板级支持包和调试 器两部分组成,本课题主要目的是构建一个通用的通信平台,为板级支持包和主机 软件提供通信服务,屏蔽通信细节。通信平台支持多种通信方式(串行、usb、网 络) , 上层应用可以自由选择通信方式, 通过调用通信平台提供的接口函数进行稳定、 可靠、高效的通信。 华中科技大学硕士学位论文 2 1.2 国内外概况 在嵌入式系统中应用比较广泛的 bsp 有很多,功能上也有很大大差异,下面对 几种常见的 bsp 在通信方面的特点进行分析: 1blob blob13具有启动加载和监控两种模式14。用户在加电以后数秒内按键盘,blob 放弃对操作系统的引导,进入监控模式。在监控程序的控制下,用户可以通过命令 行向系统发出命令启动下列操作:通过串口下载映像、擦除闪存内容、将内存中的 映像写入闪存、将闪存中的某个映像装入内存,并跳转到这个映像的入口等15。 blob 的功能相对比较简单,在移植时编写串口和 flash 等设备的驱动即可。 blob 与主机的通信方式比较单一,主要是通过串行接口,对通信接口没有统一的管 理,也没有提供统一的通信接口供上层应用调用。 2u- boot u- boot 支持 scc/fec 以太网、ootp/tftp 引导、ip 和 mac 的预置功能; 可以在线读写 flash、doc、ide、iic、eerom、rtc;支持串行口下载代码16; u- boot控制台提供 i/o 函数、内存申请和中断服务等,这些应用程序还可以在没有 操作系统的情况下运行,是测试硬件系统很好的工具17。由于传统的 bootloader 都 分为 stage1 和 stage2,所以在 stage2 中添加中断处理服务十分困难18,比如 blob, 而 u- boot是把两个部分放到了一起,所以添加中断服务程序就很方便。 u- boot 的功能非常强大,对外围设备的支持也十分广泛,并且还在不断的增 加中。u- boot支持的通信方式有两种:串口和以太网口,然而 u- boot也没有提 供一个相对独立的通信平台。 3redboot redboot 是基于 ecos 系统的硬件抽象层 hal 衍变而来19。ecos( embedded configurable operatingsystem)是 red hat 公司的一种嵌入式可配置实时操作系统, 其最为显著的特点是可配置性、可裁剪性、可移植性和实时性。ecos 的最小配置形 式是它的硬件抽象层 hal 所提供的引导程序 redboot。硬件抽象层,是对硬件平台 进行抽象,对目标系统硬件进行操作和控制,包括对中断和异常的处理,在 ecos 系 统中为上层软件提供一个硬件操作接口。 如果 ecos 系统或应用需移植到新的硬件平 华中科技大学硕士学位论文 3 台,则只需对硬件抽象层进行适当修改,这保证 ecos 系统有良好的可移植性20。 redboot 的主要功能有21: (1) 支持启动脚本,一上电就可自动执行脚本中的命令,完成自加载; (2) 提供一个简单的命令行接口用于配置和管理,通过串口(终端仿真)或以太网 (telnet)访问该命令行接口; (3) 内部集成了 gdb stub 通过串口或以太网与主机的调试器通信;属性配置一 一如系统日期时间、默认的 flash启动映像、静态 ip 地址之类的属性均可 由用户控制; (4) 可定制、可扩展,以适应目标环境; (5) 支持网络引导,可通过 bootp,dhcp 和 tftp 协议对系统进行设置并加 载程序; (6) 使用 x/y modem协议,支持从串口加载映像文件; (7) 上电自测试” 。 从 redboot的功能我们可以看出, redboot 通过串口或以太网口可以同主机调试 器进行通信,redboot移植时要根据硬件平台的具体配置修改硬件抽象层。硬件抽象 层虽然具有良好的封装性, 为上层应用提供了良好的接口, 可以很方便的将包括 ecos 在内的应用程序移植到新的平台,但 hal实现机制比较复杂,开发人员要花很多精 力去熟悉 hal中的各种定义和规定,无形中增加了开发的开销。对于某些要求相对 简单的 bsp 来说,一个轻量级的简洁的设备抽象层即可满足了。 4vxworks 的 bsp vxworks 22操作系统板级支持包 bsp(board support package)对各种板子的硬件 功能提供了统一的软件接口,包括硬件初始化、中断的产生和处理、硬件时钟和计 时器管理、局域和总线内存地址映射、内存分配等23。每个板级支持包括一个 rom 启动(boot rom)或其他启动机制。 vxworks 的 bsp 可以按功能分为两大部分24。 (1) 目标系统的系统引导部分:主要是目标系统启动时的硬件初始化,在目标系 统上电后开始执行,主要是配置处理器的工作状态,初始化系统的内存等, 这部分的程序一般只在系统引导时执行,为操作系统运行提供硬件环境。 (2) 目标系统的设备驱动程序:主要是驱动目标系统配置的各种设备,包括字符 型设备、块存储设备、网络设备等,这些设备驱动程序完成对硬件的配置, 华中科技大学硕士学位论文 4 操作系统通过设备驱动程序来访问硬件,从而完成读取数据和外界的交互 等。 vxworks bsp 与主机的通信主要有两种方式:串口和以太网口。在 vxworks 中, 将 i/o 系统设计成为任何类型的设备提供一个简单、统一、独立于设备的接口,任何 对于 i/o 系统的操作都可以视为对一个文件的操作, 而不必了解 i/o 设备或程序驱动 实现的细节。 5. wince的 bsp windows ce是微软开发的一个开放的、可升级的 32 位嵌入式操作系统,是基 于掌上型电脑类的电子设备操作。它是精简的 windows 95。 wince bsp25- 26通常由oem 抽象层,引导程序层,设备驱动程序层和配置文件构 成。 oem 抽象层简称 oal,负责wince 操作系统与硬件之间的通信。 引导程序层, 主要完成系统上电后的初始化,程序拷贝,引导加载等。配置文件,主要是包含一些配 置信息的文件27- 29。wince bsp 基本结构如图 1. 1 所示。 图 1. 1 wince bsp 基本结构 wince bsp 是 wince操作系统的一部分, 它提供了硬件和操作系统之间的接口, 操作系统要访问具体的硬件就可以通过bsp层提供的api进行访问,而不必直接与硬 件打交道。wince bsp 与主机的通信在系统启动阶段,通过串口接受用户调试命令、 输出调试信息,通过串口或以太网口下载 wince映像文件等。 通过以上对几种 bsp 的分析可以看出,bsp 的功能越来越多,除了硬件初始化 目标板 设备驱动 配置文件 oem 抽象层 bootloader 板级支持包(bsp) 华中科技大学硕士学位论文 5 和系统加载,还支持远程下载、在线调试等功能,与主机的通信也变得越来越重要, 随之而来的是实现的复杂性也越来越高。模块化、分层式设计30- 33成为 bsp 开发的 趋势。一个通用的通信平台会对 bsp 的开发和移植带来很大的便利,提高 bsp 的开 发效率。 1.3 主要研究工作 本课题从武汉精伦电子股份有限公司项目“二代身份证识别系统”入手,研究 并实现了一个用于板级支持包的通信平台,并顺利移植到其他开发项目中。通信平 台为板级开发包和主机软件提供可靠、高效的通信服务。板级开发包和主机软件可 以通过通信平台提供的统一接口,灵活的选择通信方式(串行通信、usb 通信或网 络通信)进行通信。 课题的主要工作如下: 1. 分析板级支持包通信平台的功能需求,完成通信平台整体结构设计。通信平 台分为设备端通信模块和主机端通信模块两大部分。 2. 分析并实现设备抽象层,设备抽象层对通信平台所涉及到的各种设备进行统 一管理,并为上层应用程序提供一套标准的、与设备无关的设备访问接口。 3. 实现串口、usb接口和网口驱动,并移植 lwip 协议栈 4. 分析并实现主机端通信模块。主机端通信模块由通信接口父类和派生的通信 子类组成。通信接口父类定义了通信的标准接口,通信子类通过继承及重载方法实 现具体的通信操作。 5. 对通信平台进行性能测试。 华中科技大学硕士学位论文 6 2 通信平台总体设计 通信平台为板级支持包和调试器之间提供通信服务,在设计时要考虑到系统的 可移植性和可扩展性。本章首先分析了板级支持包的功能特点,以及它对通信平台 的需求;随后提出通信平台的总体结构设计方案,最后对通信平台中的各功能模块 进行了分析。 2.1 需求分析 嵌入式系统中,运行于目标板上的板级支持包常常要与运行于主机上的调试器 进行通信,以接收用户命令,下载映像文件,进行在线调试等。目标板与主机的连 接一般有串口、usb接口和网络接口等方式,如图 2. 1 所示,进行通信时,上层应 用程序要调用设备驱动程序提供的接口函数收发数据,由于不同的设备驱动提供的 接口函数往往不统一,所以当通信方式发生改变时,应用程序也要进行改动,降低 了板级支持包的可移植性。 图 2. 1 通信平台示意图 2.1.1 板级支持包的功能 本系统所设计的板级支持包是基于 arm核的通用板级支持包, 设计的目标是能 目标板 bsp 通信设备驱动 宿主机 debugger 通信设备驱动 串口、usb、网络 华中科技大学硕士学位论文 7 够为所有基于 arm处理器设计的产品提供一个一般性的功能强大的板级开发包。 系 统所设计的板级支持包主要提供了以下功能: 1. 硬件初始化:设定目标板的最初工作环境,为后续的引导工作做准备。 2. 核心和应用程序加载:在完成系统的板级初始化以后,如果用户没有交互的 要求,在默认的情况下,一般会加载操作系统核心和相关的应用程序,并将控制权 交给操作系统。 3. 用户交互:在将控制权转交给操作系统之前,应始终提供交互接口,使用户 (包括宿主机)能够通过这个接口与板级支持包进行交互。 4. 结果显示:通过图形化界面将系统运行的状态和结果信息反馈给用户。 5. 硬件测试:对系统中的特定硬件模块进行测试(如内存、闪存、串口等) 。 6. 在线调试:用户可以在宿主机通过调试命令对系统进行静态调试或动态调 试。静态调试指获取系统在某一时刻的状态快照(内存、寄存器、程序状态字等) , 传输到宿主机进行分析和显示。 动态调试是通过 arm 处理器提供的 jtag 接口对系 统进行动态的跟踪调试,如单步、下断点等。 7. flash 烧写擦除:将嵌入式系统的软件(操作系统、应用软件)从宿主机 下载到目标板并烧写到存储器(一般都是 flash)中。 8. 设备驱动:板级支持包在运行过程中要使用目标板上的各种硬件、接口,如 闪存、lcd、串行接口、usb 接口、以太网口等,必须提供各种硬件的驱动程序供 系统使用。 2.1.2 对通信平台的要求 1. 可靠性 从上面对板级支持包的功能描述中可以看出,目标板和宿主机之间要进行大量 的通信,宿主机要向目标板发送各种控制命令、烧写文件,目标板要给宿主机返回 运行结果、状态信息(系统快照) 。通信平台要提供一定的纠错机制,使得数据可以 在宿主机和目标板之间进行可靠的传输。 2. 可扩展性 通信平台应该具有很好的可扩展性,随着技术的发展,嵌入式系统的通信方式 也有了越来越多的选择,串行接口、并行接口、usb 接口、以太网口、蓝牙、红外 等等,通信平台应该能够很方便的将新的通信接口加入到系统中。 华中科技大学硕士学位论文 8 3. 可移植性 作为通用板级支持包的组成部分,通信平台必须具有良好的可移植性。通信平 台应该具有一个统一的访问接口,上层应用不需要与具体的硬件打交道,通过调用 通信平台提供的接口函数,就可以完成双方的通信。 4. 灵活性 灵活性有两个方面:一个指灵活的通信方式选择,用户可以根据实际情况选择 不同的通信方式。另外一个指的是灵活的通信模式选择,不同的通信方式和工作环 境对通信的质量有很大的影响,如无线方式很容易受到外界的电磁干扰,必须采用 确认重传机制才能进行可靠的数据传输,以太网传输在通信距离较远的情况下也有 可能出现丢包的现象;而串口和 usb传输出错的几率非常小,可以采用直接传输无 须确认。 2.2 整体设计 通信平台是在目标板的板级支持包和主机软件之间构建的一个为双方提供可靠 数据传输的通道,既与二者密切相关,又在功能上相对独立。通信平台由两大部分 组成:板级支持包的通信部分和调试器的通信部分。两个部分向上层的应用程序提 供相同的调用接口,但在具体实现上有所不同,板级支持包应用于嵌入式系统,直 接运行在目标板上,所有的硬件驱动都必须自己开发,通信平台属于板级支持包的 一个组成部分;而调试器运行在通用 pc 上,操作系统是 windows2000 或 windowsxp,操作系统本身对通信接口的支持比较好,如串行接口和网口驱动,本 来就是操作系统的组成部分,只需在这些驱动的基础上添加设备抽象层,为调试器 提供统一的调用接口就可以了。 2.2.1 设备端通信模块 考虑到板级支持包的通用性和可移植性,设备端通信模块采用了分层的设计。 系统按照需求不同划分为不同的功能模块。从系统的角度,所有的功能模块可以分 为五个层次,自上而下依次为应用层、设备抽象层、微内核操作系统层、驱动层、 硬件层。应用层包括人机接口、硬件测试模块、在线调试模块和文件下载模块等。 设备抽象层提供设备管理和设备访问接口;微内核操作系统层采用了 uc/os- ii,对整 华中科技大学硕士学位论文 9 个系统进行资源管理和任务调度;驱动层是一组与硬件有关的代码,由驱动层直接 操纵硬件工作,当上层应用需要访问硬件时只需调用驱动层的相应函数就可以了, 移植到不同的目标板时只需修改驱动层,系统的其他部分无需改动。整个板级支持 包的结构如图 2. 2 所示。 第一层 交互模块 测试模块 文件下载模块 在线调试模块 第二层 设备抽象层 设备管理 接口函数 存储管理 第三层 微内核操作系统层(uc/os ii) 第四层 设备驱动层 flash驱动 串口驱动 usb驱动 网口驱动 第五层 硬件层 flash 串口 usb口 以太网控制器 图 2. 2 板级支持包结构 设备端通信模块分为设备抽象层和设备驱动层。设备抽象层按功能分为设备管 理模块、存储管理模块、驱动接口模块。设备驱动层包括串行接口驱动模块、usb 驱动模块、网口驱动模块等。下面对每个模块分析如下: 1设备管理模块 由于通信平台包括了众多的硬件设备和接口,所以必须对这些设备进行统一的 管理。设备管理模块通过设备表、驱动表和文件表对嵌入式系统中的各种通信接口 进行统一的管理。 2存储管理模块 数据缓冲区是设备驱动程序和上层应用交换数据的核心,数据缓冲区的创建、 释放、读取和写入是设备驱动程序必不可少的工作,数据缓冲区访问的效率对整个 设备驱动程序的性能有着举足轻重的影响。 通信平台中采用环形缓冲技术对数据缓冲区进行管理,很好的满足了通信平台 对存储管理的要求。 3驱动接口模块 华中科技大学硕士学位论文 10 驱动接口模块提供了一系列的标准调用接口,上层的应用程序可以通过这些接 口对通信设备进行操作。在通信平台中,通信设备被抽象为设备文件,应用程序通 常可以通过接口函数 open()打开一个设备,建立其与该设备的链接,对于该应用程序 而言,建立的连接表现为一个已打开的文件。打开代表目标设备的文件后,就可以 通过 read()、write()、ioctl()等常规的文件操作函数对目标设备进行操作。 4设备驱动模块 对于一个具体的设备来说,文件操作和设备驱动是同一事物的不同层次,文件 操作是对设备操作的组织与抽象,而设备操作则是对文件操作的最终实现。设备驱 动模块包括与硬件平台相关的各种通信设备的驱动程序, 本系统以 idr320 开发板为 硬件平台,实现了串口驱动、usb 口驱动和网口驱动的开发,其中,网口驱动模块 还实现了 tcp/ip 协议栈的移植。 2.2.2 主机端通信模块 主机端通信模块主要包括通信接口类、串口子类、usb 通信子类和网络接口子 类,为调试器 debugger 提供通信服务。主机端通信模块层次结构如图 2.3 所示。 图 2.3 主机端通信模块 应用程序 设备抽象层 操作系统(uc/os) 设备驱动 debugger 通信接口类库 windows 操作系统 设备驱动 传输介质 (串口、网口、 usb) 传输介质 (串口、网口、 usb) 目标板 宿主机 华中科技大学硕士学位论文 11 1通信接口类 考虑到通信平台的可扩展性,主机端的通信模块设计采用了面向对象的方法和 继承派生机制,用 c+语言开发而成。 整个通信模块由一个通信接口类和多个通信子 类组成。通信接口类是是所有通信子类的父类,它定义了通信平台向上层应用程序 提供的调用接口,通过通信接口类派生的各种子类也同时拥有了这些标准调用接口, 只需实现调用接口所对应的函数就可以了。通过这种方式,可以非常方便的加入新 的通信接口而不需要对上层的应用程序进行太大的改动。通信接口类的接口调用函 数包括 open(),close(),read(),write()等。 2串口子类 继承于通信接口类,提供对串口通信的支持。通过 windows 操作系统提供的重 叠机制,可以对串口进行同步或异步的读写操作。 3网络接口子类 继承于通信接口类,提供对网络通信的支持。由于 windows 操作系统本身已经 提供了强大的网络功能和完善的 tcp/ip 通信机制,所以网络接口子类对 socket 类进行了封装,实现通信接口类的调用接口。 4usb通信子类 继承于通信接口类,提供对 usb通信的支持。 2.4 小结 本章重点介绍了通信平台的整体结构设计。首先介绍了板级支持包的功能特点, 然后分析了通用板级支持包的通信平台的设计要求,主要是对可扩展性、可移植性 和灵活性的分析,接着根据功能要求将通信平台划分为两大部分:设备端通信模块 和主机端通信模块,并对两大模块中的各个功能子模块进行了详细的分析和说明, 后面的章节将就这两大模块的实现进行深入的分析和介绍。 华中科技大学硕士学位论文 12 3 设备端通信模块设计与实现 设备端通信模块负责对目标板上的通信设备进行管理,为板级支持包的上层应 用程序提供访问接口,与主机端通信模块建立连接并进行通信。本章将详细介绍设 备端通信模块中设备抽象层的设计与实现,并以 id320 硬件开发板为例详细介绍 usb 驱动模块和网络驱动模块设备驱动的设计方法,串口驱动由于比较简单,本文 不再赘述。 3.1 设备端通信模块总体设计 设备端通信模块为板级支持包提供通信服务,它向上层应用程序屏蔽了通信设 备操作的细节,为了达到这个目的,设备端通信模块采用了模块化、分层式的设计 思想。设备端通信模块由设备抽象层和设备驱动层组成,设备驱动层包括与具体通 信介质相关的通信子模块。设备端通信模块与整个系统的关系参见图 3.1。 图 3.1 设备端通信模块与整个系统关系 硬件测试 在线调试 文件下载与烧写 系统调用接口 设备管理 存储管理 串口驱动 usb驱动 网络驱动 ucos/ii 微内核操作系统 应用程序层 设备抽象层 驱动层 操作系统层 华中科技大学硕士学位论文 13 3.1.1 板级支持包工作原理 板级支持包支持用户交互、硬件测试、在线调试、文件下载烧写等功能。通常 情况下,板级支持包都是单任务顺序执行,由用户通过用户交互接口发送命令,板 级支持包的主程序通过一个无限循环等待接收命令并执行,在执行命令并返回结果 后继续循环等待下一个命令。这种方式无疑降低了系统的执行效率,多任务并发执 行是提高效率的有效方法。然而,多任务并发必然涉及到任务的调度及任务间通信 等一系列问题。另外,由于采用了模块化、分层式设计,不同层之间的数据交换和 通信也需要解决。例如,当底层驱动接收到了宿主机发送过来的数据后,如何通知 上层的应用程序进行接收等。 为解决上述问题, 本课题在板级支持包中引入了ucos- ii 微内核操作系统。 1. ucos- ii 微内核操作系统 ucos- ii 是一个源代码公开的,抢占式多任务的实时嵌入式操作系统。它提供 了实时系统所需的基本功能,其包含全部功能的核心部分代码只占用 8.3k 字节,而 且由于 ucos- ii 是可裁剪的,所以用户系统中实际的代码最少可达 2.7k 字节,非常 短小精悍。ucos- ii 实际上是一个实时操作系统内核,只包含了任务调度,任务管 理,时间管理,内存管理和任务间的通信与同步等基本功能。为了简化系统的设计, ucos- ii 规定所有任务的优先级必须不同,任务的优先级同时也唯一地标识了该任 务。即使两个任务的重要性是相同的,它们也必须有优先级上的差异,这也就意味 着高优先级的任务在处理完成后必须进入等待或挂起状态,否则低优先级的任务永 远也不可能执行。 ucos- ii 最多可以管理 63 个任务,这些任务通常都是一个无限循环的函数 ucos- ii 提供了任务管理的各种函数调用,包括创建任务,删除任务,改变任务的 优先级,挂起和恢复任务等。 对于一个多任务操作系统来说, 任务间的通信与同步是必不可少的。 ucos- ii 提 供了四种同步对象,分别是信号量,邮箱,消息队列和事件。通过邮箱和消息队列 还可以进行任务间的通信。所有的同步对象都有相应的创建,等待发送的函数。但 这些对象一旦创建就不能删除,所以要避免创建过多的同步对象以节约系统资源, 也可以根据系统的实际需要选择使用合适的同步对象。 2. 板级支持包的任务分配 板级支持包启动后主要运行了三个任务:监控任务、tcp/ip 协议栈任务和用户 界面交互任务。监控任务负责实时监控通信接口状态,接收调试器的各种命令和数 华中科技大学硕士学位论文 14 据文件。tcp/ip 协议栈任务用于 tcp/ip 通信。用户交互任务用于响应用户的键盘命 令并执行相应任务。 3.1.2 设备抽象层 从图 3.1 中我们可以看出, 设备抽象层34是设备端通信模块与上层应用程序的接 口,它向上层应用程序提供了一套标准的接口函数,通过这些接口函数,上层应用 程序可以对通信设备进行读写,进而完成通信任务。在设备抽象层,所有的通信设 备都被抽象成文件的形式35,不同的通信设备以文件描述符相区别,通过通信设备 进行传送或接收数据的操作被转换为对文件的读写操作。 对文件的操作是对设备操作的组织与抽象,设备操作则是对文件操作的最终实 现,不同设备实现相同设备操作的方法是完全不同的,这就是通信子模块,也就是 底层的设备驱动程序的主要工作。为了完成文件操作与设备操作之间的转换,设备 抽象层必须有一定的机制,将对文件的标准系统调用与低层设备驱动程序中对设备 的操作对应起来,设备抽象层主要是通过文件描述表 files、设备描述表 devices 和驱 动描述表 drivers 来实现对各种设备的管理。 3.1.3 驱动层 驱动层包含了对应与具体通信设备的各个通信子模块,目前,系统支持的一共 有三个:串行通信子模块、usb 通信子模块和网络通信子模块。串行通信子模块和 usb通信子模块分别完成对串口和 usb口的设备驱动,网络通信子模块除了底层的 网络设备驱动程序以外,还移植了 lwip 协议栈,使得板级支持包具备了通过网口连 接到局域网或广域网上进行远程操作的能力。 3.2 设备抽象层设计 3.2.1 数据结构 设备抽象层主要通过文件描述表 files、设备描述表 devices 和驱动描述表 drivers 来实现对各种设备的管理。设备描述表包含了每一个通信设备的描述信息,驱动描 述表中的表项是一个函数跳转表,函数跳转表中的函数指针指向具体的设备驱动函 数。应用程序可以通过系统调用 open()“打开”设备,建立与目标设备的连接,每一 华中科技大学硕士学位论文 15 个打开的设备在文件描述表中占有一个表项,表项的下标就是文件描述符。 在打开代表目标设备的文件后,上层应用程序通过 read()、write()、ioctl()等系统 调用对目标设备进行操作。标准系统调用使用文件描述符标识要访问的设备,系统 从文件描述表中查找这一文件描述符,再利用这一描述符找到该设备在设备描述表 和驱动描述表中的相关信息,最后调用驱动描述表中对应的设备驱动函数来完成最 终的操作。 系统中的所有外部设备都由一个个抽象的设备描述数据结构来描述,设备描述 数据结构体中成员至少应该包括设备名及设备驱动名。一个典型的设备描述数据结 构定义如图 3. 2 所示。 struct device_struct /设备描述数据结构 char *name; /* 设备名称*/ char *descrip; /* 设备描述字符串 */ char *driver_name; /* 设备驱动名- - - 与设备驱动表对应 */ int io_addr; /* i/o 基址*/ int count; /*设备使用计数*/ ; 图 3. 2 设备描述结构 每一个通信设备对应一个设备描述结构体,系统将所有的设备描述结构体组合 在一起,构成一张设备描述表。表中的每一元素对应着一个外部设备,系统利用设 备名 name 来表示每一个设备,它们的设备名称必须各不相同,因为系统调用 open 将利用设备名称查找整个设备表来完成文件描述符表的建立。设备描述结构体中的 设备驱动名称 driver_name 说明该设备对应的设备驱动的名称, 系统将利用设备驱动 名来查找设备的驱动操作函数。设备使用计数 count 来维护着设备同时打开的次数, 系统用这个计数决定了最终关闭设备的操作时间。 由于同一个设备驱动可以为多个设备服务,所以设备驱动采用单独的数据结构 进行描述: 华中科技大学硕士学位论文 16 struct dev_operations int (*open)( int fd,int oflags); /* 设备打开函数 */ int (*close)(int fd); /* 设备关闭函数 */ int (*read)(int fd,char *buf,int nbytes); /* 设备读函数 */ int (*write)(int fd,char *buf,int nbytes); /* 设备写函数 */ int (*init)(); /* 设备初始化函数 */ int (*ioctl)(int fd,unsigned int cmd,unsigned long args); /* 设备控制函数 */ char * name; /* 设备驱动名 */ ; 图 3. 3 设备驱动数据结构体 设备驱动数据结构体中包含了常用的设备驱动函数指针,这些指针最终都会指 向实际驱动程序中对应的函数。系统将所有提供的设备驱动数据结构体组合在一起 形成一个设备驱动表,表中以每个设备驱动的设备驱动名作为它们的唯一标识。在 调用接口函数 open()打开一个设备时,将首先用设备名在设备描述表中查找,然后再 用设备描述表中对应表项的设备驱动名在驱动描述表中进行查询,最后将得到的驱 动描述结构指针填入文件描述表。 文件描述表是一个静态数据结构体数组,数据结构体的主要元素定义如图 3. 4 所示。 struct file_struct /i/o 文件句柄数据结构 int errno; /* i/o 操作返回值 */ int flags; /*i/o 设备类型和控制标志 */ struct device_struct *ds; /*设备描述表指针 */ struct dev_operations *dops;/*设备驱动指针*/ ; 图 3. 4 文件描述结构 华中科技大学硕士学位论文 17 文件描述符结构中的 errno 定义了每次 i/o 操作的返回值,应用程序可以通过这 个返回值判断错误类型。 ;flags 定义了设备的类型和控制标志,如:设备是只读、只 写还是可读可写方式打开的,设备读写操作是不是可阻塞等标志;指针 ds 指向设备 描述表中的一项,利用 ds 可以确定该文件描述符打开的究竟是那个设备;指针 dops 指向驱动描述表中的一项,利用 dops 可以定位该文件描述符对应的设备驱动程序。 设备描述表、设备驱动表和文件描述表三者的关系可用图 3. 5 表示: 图 3. 5 设备驱动接口结构图 设备描述表、驱动描述表和文件描述表三者都采用静态数组来实现,设备描述 表和驱动描述表通过对数组直接赋值完成初始化;文件描述表的初始化是在引导过 程中对所有数组成员的 flags 清零来完成的。文件描述表在系统运行过程中通过标准 的文件系统调用来维护,系统每打开一个设备,都会在文件描述表中分配一项作为 设备的文件描述符,返回这一项对应的数组下标作为“打开文件号” ,对应图 3. 5 中 的 fd;在对设备进行读、写、关闭的时候,利用“打开文件号”作为索引访问文件 描述表,得到设备的文件描述符。 为了扩展对新的硬件资源的支持,可以针对新设备编写新的设备驱动程序,再 在设备描述表和驱动描述表中添加对应条目就可以了,这种方法大大增强了通信平 *dops *ds 文件描述表 设备描述表 驱动描述表 华中科技大学硕士学位论文 18 台的可扩展性。 3.2.2 接口函数实现 设备抽象层为应用程序提供一组标准的接口函数来完成设备的操作控制任务, 这些接口函数包括:open、close、read、write 和 ioctl,它们为应用程序屏蔽了底层 设备驱动的控制细节。对应用程序而言,所有的打开设备都由打开文件号来引用, 打开文件号是一个非负的整数,是文件描述符数组的下标。当应用程序使用 open() 打开一个设备时,返回值 fd 是一个打开文件号,当读、写一个设备时,用这个打开 文件号标识该设备,将其作为参数传送给其它接口函数。 下面就主要的几个接口函数作一个详细的说明。 1. 接口函数 open 接口函数 open用于打开一个设备,它在应用程序与打开的设备之间建立起一个 连接,并初始化驱动程序的私有数据结构。接口函数 open打开设备的流程基本上是 固定的:在文件描述表中分配一空白项,根据设备名初始化空白文件描述符,调用 设备驱动程序的 open函数打开物理设备,最后将分配的文件描述符在文件描述数组 中的下标作为打开设备号返回给应用程序。 接口函数 open的算法描述如图 3. 6 所示。 对文件描述符是否有空闲的是通过文件描述符的标志位来判断的,一旦更改了 文件描述符的标志位,该文件描述符就认为是被占用的。所以,如果调用设备驱动 的 open函数失败,系统就必须要释放这个被占用的文件描述符。 应用程序可以规定各种各样的选择标志来限定对设备的打开,最重要的是对设 备读写方式的控制。如果一个设备以“只读”的方式打开后,再利用接口函数 write 进行写操作时将会出错。 华中科技大学硕士学位论文 19 图 3. 6 接口函数 open 算法描述 2. 接口函数 close 接口函数 close 用于断开应用程序与打开设备的连接。对于同一设备被多次打开 的情况,这一接口函数只在最后一个关闭操作到来时才调用驱动程序的 close 函数。 因为驱动程序的 close 函数会将设备真正的关闭掉,还会重新初始化驱动程序数据结 构和设备硬件状态。如果在关闭一个文件描述符对应设备的同时,还有其他程序通 算法:open 输入:设备名, 打开方式 输出:打开设备号 从文件描述数组中分配一空闲项; if(无空闲项) 系统达到打开设备的上限,打开失败; 根据设备名从设备描述表中找出对应设备描述项; if(没找到设备描述项) 系统无此设备,打开失败; 根据设备描述项中的驱动名在设备驱动表中找到对应设备驱

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论