I/O端口

I/O端口（精选6篇）

I/O端口 篇1

1 引言

Windows 2000/NT和串口通信是工业领域常用的操作系统和通信方式,然而在Windows 2000/NT下用调用Win32 API函数进行串口通信时,由于层层调用了系统提供的驱动程序而导致每次操作耗时过多,实时性不强。在一些实时性要求高的情况下难以满足要求,本文即是讨论并解决该问题。首先引出了另一种实时性很好的串口操作的方法———直接访问I/O端口;接着介绍了由于Windows2000/NT对I/O端口的保护而无法使用,并讲述了Windows 2000/NT对I/O端口的保护机制和绕过该机制的方法;最后提出了一个实际中遇到的问题,并介绍了解决方法。

2 在Windows 2000/NT下直接访问I/O端口的方法

直接访问端口,就是调用访问端口的函数,如_inp,_outp等直接对端口所指的地址进行访问。这种方法不需经过操作系统内核,每次操作相当于访问一次内存或寄存器的时间,所以能做到访问时间短,实时性高。但在Windows 2000/NT下调用这些函数时,会出现编译错误,这是由于Windows 2000/NT对端口进行了保护的缘故[1]。下面介绍Windows 2000/NT对端口的保护机制和突破此机制的方法。

首先需要理解三个概念:CPL,IOPL和IOPM。

CPL(Current Privilege Level)为处理器的当前特权级,由处理器正在执行的指令代码的代码段寄存器CS的最低两位决定。两位组成的四个值0、1、2和3,分别表示当时处理器所处的四个权限级。0级的特权级最高,3级的特权级最低。Windows 2000/NT只用0级和3级(rang0和rang3级),对应内核模式和用户模式。

IOPL(I/O Protection Level)为I/O保护级,指定了要求执行I/O指令的特权级。位于标志寄存器EFLAG的12,13位。Windows 2000/NT中把IOPL设置为0。

IOPM(I/O Permission Bitmap)为I/O许可位图,位于任务状态段TSS(Task State Segment)中从0x88到0x2088,大小为8193字节的连续地址空间中。其中前8192字节(65536位)中的各位正好与80x86处理器的I/O地址空间中的65536个8位I/O端口一一对应。根据规定IOPM必须以FFH结束,故IOPM的第8193个字节一定为FFH[2]。

80x86通过两个策略来实现对I/O端口的保护。

第一个策略是在数值上比较IOPL和CPL的大小。若CPL≤IOPL,则由CS确定的代码段可直接访问I/O端口,否则需由第二策略决定直接I/O端口操作是否可正常执行。因为Windows 2000/NT中把IOPL设置为0,故CPL=0的内核模式可直接访问I/O端口,而CPL=3的用户模式不可以。

第二个策略是通过在任务状态段TSS中设置一个称为I/O许可位图(IOPM)的存储区来决定CPL>IOPL的用户模式代码段能否直接访问I/O端口。IOPM中每位对应一个I/O端口。如果这个位是1,访问被禁止;若为0,就授予用户模式对该I/O端口的直接访问权。不过运用第二个策略的前提条件是必须让位于TSS中0x66,0x67处的IOPM偏移量指向TSS中IOPM开始(0x88)处。IOPM偏移量的默认值为指向TSS末尾,这样将禁止用户模式下的直接I/O端口访问,而不管IOPM的内容。图1为上述两策略的图形描述。

为了在Windows 2000/NT中用户模式下插入直接I/O端口指令能正常运行,需要作到如下两点:一是让IOPM偏移量指向TSS中IOPM开始处;二是将IOPM全部位置0。有两个DDK上没公开的内核模式函数可完成该任务。

Ke386IoSetAccessProcess()接收两个参数,一个是指向调用PsGetCurrentProcess()函数而得到的当前进程的进程结构;一个是如果要授予直接I/O端口访问权就必须设置为1,而要禁止直接I/O端口访问就必须设为0的整数。如若整数为0,函数通过把被传递的进程的IOPM的偏移量指向TSS结尾而禁止直接I/O端口访问(图2中实线);如果整数为1,函数通过把被传递的进程的IOPM的偏移量指向TSS中IOPM开始而为直接I/O端口访问做好准备(图2中虚线)。Ke386SetIoAccessMap()也接受两个参数:一个整数和一个缓冲区指针。其中IOPM被定义为typedef UCHAR IOPM[0x2000]。如果该整数为1,它将把一个长度为8192字节的值从缓冲区复制到TSS的IOPM中;若整数为0,则用FFH填满IOPM。

在用户模式下直接访问I/O端口操作之前,应先编写一个内核模式设备驱动程序。在该内核模式设备驱动程序中先调用Ke386IoSetAccessProcess(),将位于TSS中0x66,0x67处的IOPM偏移量从指向TSS末尾改为指向0x88处的IOPM。之后调用Ke386SetIoAccessMap()函数将IOPM中各位置0。经相关步骤后编译得该驱动程序portio.sys(名字可任意),并将其正确安装后便为下面解决实际问题时的直接I/O端口操作作好了准备。

3 实际问题

3.1 问题的提出

根据工业现场控制要求设计的智能化温度程序控制仪,采用MCS-51系列单片计算机89C51设计。要求完成温度程序控制仪与PC机之间的数据通信。

为了提高温度程序控制仪的可靠性,对温度程序控制仪中的单片计算机每秒复位一次。复位后,温度程序控制仪进行测量和控制并向上位机(PC机)发送握手信号55AAH,发送后4~6ms内接收上位机回送的命令字节。若能接收到上位机回送的命令字节,则根据命令字节的要求执行相应的操作。如果收不到上位机的命令字节,温度程序控制仪向上位机发送4字节的温度值(实际测量的温度和设定的温度,各为2个字节)。

在上位机(PC机)上最初用的是Win32通信API函数设计的多线程串口通讯程序,但发现每次读PC机串行口时,一下就收到6个字节(55AAH及4字节温度值),而实际要求是:PC机首先接收2个字节,然后再回送给温度程序控制仪(下位机)命令字节(2个字节)。

通过分析,问题的原因是:采用API函数编写的程序是用户模式级的,串口操作的执行过程是通过用户模式的Win32函数(CreateFile,ReadFile,WriteFile等)向内核模式的I/O管理程序发送请求,I/O管理程序将该请求在层层驱动程序之间往下传,最终由最低层驱动程序访问硬件,之后把结果层层上传给用户模式。这是一个比较复杂的过程,该过程的执行结束可能需要几十毫秒的时间。然而由于温度控制仪只可能循环等待5ms左右,也就是说在5ms内温度控制仪是不可能接收到上位机的命令字节的。所以,主要原因是由于PC机访问串口接收缓冲区所花的时间太长而造成的。温度程序控制仪的工作过程如图2所示。

由上述分析知,解决问题的关键是必须缩短每次访问串口的时间。方法是用直接访问I/O端口的函数(_inp_outp等)代替Win32 API串口函数。但是,在Windows2000/NT中插入如上指令时,将导致特权指令异常。这是因为Windows 2000/NT不像Windows 98/95那样是基于DOS下的技术。它们出于自身安全的考虑而不允许处于用户模式的应用程序直接访问I/O端口。下面首先分析一下在Windows 2000/NT中是如何实现对I/O端口进行保护的,然后再考虑如何突破这种限制而使得在用户模式下就可直接访问I/O端口。

3.2 问题的解决

现在就有两种不同的方法来实现串口通信程序。其一是Win32 API函数;其二是直接I/O端口函数。前一种方法实时性差,但大家较熟悉,后一种方法实时性好,但需要对硬件掌握较好。本文以API函数为主,直接I/O端口函数为辅解决前面提到的实际问题。

串口I/O接口芯片8250内部有10个寄存器。COM1的端口地址为3F8~3FF(3F8,3F9分时复用),COM2的端口地址为2F8~2FF(2F8,2F9分时复用)。以COM2为例,2F8为数据发送保持和接收缓冲寄存器,其余各寄存器有的存储着上位机为串口通信设置的各种参数(数据位数、奇偶位和波特率等),有的保存着当时串口通信的各种状态。实质上,Win32中各串口API函数操作的目标主要就是这10个寄存器,只不过它们都是经过Windows 2000/NT提供的驱动程序层层间接访问的[3]。所以在使用API函数编写的程序中同时使用直接I/O端口函数时要注意不能随便修改上述寄存器,这样可能导致Win32函数调用的内核驱动程序与硬件失去同步而产生严重后果。但用直接I/O端口函数对0x2F8端口的读和写不会产生太大问题。

程序中大部分任务由API串口通信函数完成,只有当上位机需要向温度程序控制仪发送命令字节时,才调用两个直接I/O端口函数来保证实时性。用直接I/O端口函数读端口0x2F8的内容,判断其是否为温度程序控制仪发送的握手信号55AAH。若是则马上向该端口写用户要求的命令字节;如果不是就等待。在VC++6.0中相关程序代码如下:

上面采用的是效率较低的查询方式,但由于温度程序控制仪每秒都发出握手信号55AAH一次,故查询时间最多为一秒。效果可以达到要求。

4 结束语

Windows 2000/NT中存在I/O端口保护是有原因的。轻率地使用直接I/O端口而绕开一个已有的内核模式驱动程序并不是十分稳妥的方法,有可能导致驱动程序和硬件失去同步,从而出现不可预料的结果,所以要谨慎使用。

摘要：针对一个实际问题,介绍了Windows 2000/NT对I/O端口的保护机制和直接访问I/O端口的方法。并用Win32 API函数和直接I/O端口函数混合编程解决这个实际的实时问题。

关键词：实时通讯,设备驱动程序,I/O端口

参考文献

[1](美)保拉·汤姆林森等著.周济译.Windows NT/2000编程实践[M].北京:中国电力出版社,2001.

[2]陈建铎,宋彩利,冯萍.32位微型计算机原理与接口技术[M].北京:高等教育出版社,1998.

[3](美)Art Baker,Jerry Lozano著.施诺等译.Windows2000设备驱动程序程序设计指南[M].北京:机械工业出版社,2001.

I/O端口 篇2

带有I/O模块和处理器的导轨被称为本地I/O导轨;带有I/O模块、电源、远程I/O通信卡并且安装在远离本地I/O导轨的导轨被称为远程I/O导轨。远程I/O导轨的`数目取决于不同处理器能够控制变量的数目。

远程I/O导轨与处理器之间的通信可以采用多种方式实现,具体包括同轴电缆、双轴电缆、屏蔽双绞线等，如果距离较远而需要考虑抑制噪声干扰问题可以采用光纤通信。

并行I/O模块：

并行I/O模块承担了与外部系统进行信息和数据交互的重要责任,可以用于扩展外围器件,者直接动键盘、LED等简单外部设备。

通常来说,51单片机有4个8位的并行I/O口,分别为P0、PI、P2、P3四组,其中PO和P2既可以用作普通I/O端口也可以当成数据地址端口,P3则在作为普通I/O端口的同时还具有其他(第二)功能,只有PI仅仪用作普通I/O口。

I/O端口 篇3

随着科学技术的日新月异自动化水平的不断提高。将电气控制系统 (简称ECS) 纳入集散控制系统以下简称DCS实现炉、机、电一体化监控, 已是各工厂所必须选择的控制系统方案。由于国内对电气系统监控的有关规定、规范还在不断地修订完善中, 对电气系统的控制方式没有作统一的规定, 国内各企业对电气系统接入DCS的方式采用了不同的方式, 主要有“硬接线”方式、远程I/O及分布I/O接口方式、智能终端设备 (ST) 和现场总线 (FB) 连接方式, 各种方式各有优缺点, 目前在工厂的新建项目中应用较多的是远程I/O及分布I/O连接方式。

2 远程I/O及分布I/O接口方式

远程I/O基于现场总线发展起来的现场与控制室或控制系统之间的一种全数字、双向串行、多节点的通讯系统。现场总线是工业系统向分散化、智能化、网络化的发展方向, 其导致传统自动仪表和控制系统在结构和功能上得到进一步的变革, 把DCS集中与分散相结合的控制方式变成新型的全分布式控制网络。远程I/O适用于恶劣环境中, 远程I/O的理论基础简单, 工程应用方便可靠, 整套系统设计方便, 整体网络和硬件可以自由分配, 灵活变通, 主要注意工艺要求, 整体考虑防止网络地址的冲突。具体实践应用应该了解硬件的原理和注意事项, 软件应了解组态方式, Profibus—dp协议转换卡组态简单, 可以进行离线组态, 并要保存好组态程序。远程I/O和DCS通讯应清楚通讯协议以及其衔接部分的接线方式, 通讯距离决定用光纤还是普通通讯电缆, 采用光纤还需要配备光纤耦合器。控制系统个从设计、安装、投运到生产运行及其维护检修都有其优越性;通讯速率高, 通讯质量好, 通讯介质广, 网络拓扑结构灵活, 可应用于安全等级较高的危险场合。特别投资少、耗能少;是符合国家提倡的节能环保要求。

远程I/O通信 (分布式I/O通信) 是采用的周期I/O数据传输方式。远程I/O通信中采用“周期I/O方式交换数据”, 按照主从方式存取控制, 其带的通信处理器作为主动站, 其它远程I/O单元皆为从动站。在主站设立一个“远程I/O缓冲区”, 主站中负责通信的处理器采用周期扫描方式, 按照顺序与各从站交换数据存放于远程I/O缓冲区中。这样周而复始, 使主站中的“远程I/O缓冲区”得到周期性刷新。在主站中的CPU单元负责用户程序的扫描, 它按照循环扫描方式进行处理, 每个循环扫描周期都有一段时间集中进行I/O处理, 这是它对本地I/O单元和远程I/O缓冲区进行读写操作;尽管主站中的CPU单元没有直接对远程I/O单元进行操作, 但是由于主站中远程I/O缓冲区和远程I/O单元是一一对应的, 所以主站CPU对远程I/O缓冲区进行读写操作, 就相当于直接访问了远程I/O单元。图1、图2分别为远程I/O连接方式和分布式I/O连接方式。

3 性能结构分析

远程I/O它的最为主要的优势在于远程, 最远传播距离为可达到十几公里, 其次是稳定性和可靠性高, 在恶劣的工业环境里, 一旦通讯正常可以保证几年不出问题, 为化工连续生产带来了保证。技术特点是:

(1) 系统具备开放性;总线标准、通信协议均是公共的, 一次性选用后可以满足多种上位机系统兼容和集成, 通用性极强。

(2) 互可操作性和互换性;是实现互连仪表、设备间及系统间的信息传送与沟通, 可实现点对点、一点对多点的数字通讯。互换性是不同生产厂家性能类似产品可以互换, 而不必担心兼容性。

(3) 适应性强;其通讯可支持双绞线、同轴电缆、光纤、红外线、电力线、射频。同时能够适应环境恶劣的工业现场, 抗干扰能力强。

存在的问题:近几年来, 在新建火电机组及工厂电气系统都实现了范围不等的联网应用, 并通过远程I/O接口向DCS传送监测信息, 在提高电气系统自动化水平和管理维护方面, 给用户提供了实实在在的好处。但是, 电气控制系统 (ECS) 在实施过程中也存在此困难和问题, 主要如下:

1) 对于DCS厂家来说, 取消了大量的变送器和I0卡件, 市场利益受到一定的冲击, 还要投入精力来做通信接入工作, 难免会有定的抵触情绪。

2) 目前国内也投资了进口DCS设备, 但DCS的通信开放性受到很大限制, 对于通信的信息, DCS的通信周期、数据包长度都对通信的实时性有很大影响。

3) 通信方式与硬接线方式相比, 信息申转环节多, 在可靠性和实时性方面还有一定的差距, 目前通信的信息大多局限于监测信息, 还不能完全实现用户期望的全通信目标。

4) ECS节点多、分散性强, 并且多台机组需要分期建设, 对系统的容量、网络构架的可扩展性和设备厂家的售后服务能力都提出了很高的要求, 而不同厂家的解决方案良秀不等, 网络通信中断、信息刷新缓慢等问题经常困扰用户, 使系统维护量增大, 从而影响ECS的实施效果和用户的应用信心。

5) 从投资成本来看, 由于部分工程ECS的站控层和通信层配置较复杂, 从而使ECS的投资偏高, 对于整个控制系统而言, 成本降低并不明显。

6) 在DCS投运之后, 用户对ECS酌应用相对较少, 关注程度较低, 因而目前ECS的电气维护和管理功能并不十分完善。

对于以上问题的解决, 一方面, 需要ECS厂家切实根据用户需求提供先进的技术、可靠的产品和完善的服务, 并且能持续不断地改进和创新, 特别是提高网络通信的可靠性和实时性、提供丰富完善的电气维护和管理功能;另一方面, 需要广大电厂、设计规划部门和DCS厂家以更加坚定的信心和开放的心态来接纳ECS, 各方密切配合, 从真正为电厂用户提供服务的角度出发, 做好ECS和DCS的互联规划和实施工作, DCS厂家应从软硬件配置上满足异构系统互联的开放性、实时性和灵活性要求。

4 结语

对象I/O技术的模拟实现 篇4

我们知道C++对象是“存活”在RAM中的，由于RAM的易失性[1]，程序需要将对象存入磁盘中，将来需要时再把对象读入内存加以恢复，这样一来就好像对象一直“活”着一样，因此对象的持久化是C++中的一个非常重要的操作。

许多程序员可能有这样的误区，利用下面的代码：saveClassName();className=readClassName();p=new className;不就轻松实现对象的保存和恢复了吗?

需要指出的是，在C++中，是通过new A而非new“A”（或className=“A”,new className）实例化A的对象。换句话说，试图利用下面的代码className=readClassName（）;p=new className；来达到通过类的字符串名称动态创建对象的做法是根本行不通的，因为p=new className根本无法通过编译！[2]

由此我们得出对象的持久化需要的两个条件：

(1)获取对象所属类的名称的能力；

(2)能根据类的字符串名字动态创建对象的能力。

这两种能力的获得目前有两种解决方案：

一是由C++编译器（compiler）提供———例如Borland C++4.5:

二是由程序员自己加上去。

本文是通过第二种方法模拟实现对象的持久化机制，从而深入探讨了对象I/O技术的实现机制。

本文结构如下，首先描述了对象持久化的实现，其次对实现进行了验证，最后是论文进行总结。

1 对象持久化的实现

为了说明问题而又不失一般性，我们假定有三个类，分别是Object,A和B，其中A和B都派生于Object，类的定义如下：

为了让对象具备持久化的两个条件，需要依次为对象添加如下信息。

1.1 为每个类增加对象创建函数CreatObject，如表2所示。

1.2 增加类的识别信息（类名称或ID等）以及继承信息，由于这部分信息比较多，可以将其整合到一个结构体Struct ClassInfo中。ClassInfo中保存有两个链表：

类的继承链表和程序中所有类的类型信息链表。类的识别能力就由这两个链表来完成。换句话说，我们希望在main函数执行之前内存中就存在如图1所示的两个链表。其中类的继承链表是由Struct ClassInfo的带参构造函数完成的（在VC++中，结构体也可以有构造函数），而类的类型信息链表则是由ClassInfoInit类完成的。Struct ClassInfo和ClassInfoInit的定义如表3所示。注意，链表的创建是在它们的构造函数中完成的。

最后一步，将类型信息作为类的静态的成员变量添加进来，并为每个类实例化静态的初始化类，目的是在main函数执行之前得到图1所示的两个链表。

在这要强调一下static关键字的作用：

(1)如果类的成员变量被Static关键字所修饰，则这该属性不是为类中的每个对象分别拥有，而是共用，其引用形式不是对象成员变量，而是类成员变量，即不需要市里实例化对象就可以使用。成员函数也与此相仿[3]。

(2)如果对象（包括作为类成员的对象），如initObject、ObjectInfo等，被说明为Static，则这些对象是在main函数执行之前就已经存在了，换句话说，这些对象的构造函数是在main函数调用之前就已经被调用了。因此在main函数执行之前，内存中就已经存在着图1所示的链表就可以理解了。

我们添加的RTTI信息能否有效的支持对象的持久化可以由试验来验证。

2 试验

该试验主要验证了对象持久化必须具备的两个能力，即动态创建对象能力和获取对象所属类的能力。试验的环境如下：操作系统Windows XP sp2,IDE环境是VC++6.0 SP6。如需要全部源代码可与作者联系（hehh6@henu.edu.cn）。

通过对象增加的RTTI信息（增加的静态成员变量），获取对象所属类的能力自然具备。

动态创建对象能力实际上就是根据类的字符串名称来实例化对象的能力，在图1所示链表的支持下，该功能可以非常轻松的实现。

思路如下：通过ClassInfo：:pFirstClass查找类名匹配的ClassInfo，利用ClassInfo中的pCreateObject指针实例化对象,为方便起见,可为程序增加查找函数

3 结束语

本文在手动添加的RTTI信息的支持下实现了对象的持久化，从中读者可以深入了解对象持久化的的实现机制。

在商业的编译器VC++中其实现持久化是通过一个神秘的宏，当将该宏展开后，VC++实现持久化的的思路和本文大同小异，只是更精巧[4]。

参考文献

[1]Stanley B.Lippman.Inside The C++Object Model(深度探索C++对象模型)[M].侯捷,译.武汉:华中科技大学出版社,2001.

[2]葛磊.The Object's Permanence Technology and Its Realization in MFC[J].开封大学学报,2006,20(1).

[3]钱能.C++程序设计教程[M].第二版.北京:清华大学出版社,2005:418-419.

海量存储系统I/O性能瓶颈分析 篇5

海量存储系统实现了当前存储系统的PB以及更高级别的发展规模,它对数据实行条带化的分割方式,有效的对信息数据进行了组织和存储,良好充分的利用了设备的存储空间,同时采用并行化的文件系统和访问协议,能够在保证低开销和低延迟的情况下为外界提供强大的并发访问的能力。此外,为了保证数据和系统安全,还实现了信息备份和冗余。

Shannon在信道编码定理中指出,只要信息传输速率低于信道容量,总可以找到一种编码方法,使得差错概率任意的小。磁盘阵列中即是通过数据冗余技术来降低传输中可能存在的差错,它通过牺牲一些存储空间保存冗余数据,来实现对用户数据的保护,从而达到提高可靠性的目的。RAID控制器利用与磁盘的通信协议,很容易就能判断出故障盘的位置,这种情况只需用信息论中的简单高效的纠删码(Erasure Code)就能完成数据的恢复任务,其中MDS阵列纠删码的存储效率、编解码复杂度、更新复杂度都达到了最优,一直是存储系统中纠删码技术的热点。

当前磁盘阵列由于冗余技术的引入带来了大量数据校验运算,同时冗余数据也占用了部分聚合带宽。校验数据运算瓶颈,额外的冗余开销、阵列控制器CPU性能瓶颈、内部总线吞吐量、PCI总线吞吐率、通道性能、磁盘最大吞吐率、分条大小、Cache策略、I/O调度、工作负载情况等最终影响磁盘阵列整体性能。

其中阵列控制器CPU性能瓶颈、内部总线吞吐量、PCI总线吞吐率、通道性能、磁盘最大吞吐率都取决于具体硬件部件,在硬件性能一定的情况下,可以通过优化磁盘阵列的数据校验算法,采用一种新的信道编码方式来提高阵列控制器的存取速度和处理能力。

2 研究内容

本文主要研究影响海量存储系统I/O性能的元素,包括存储系统本身的硬件瓶颈和存储系统采用的冗余编解码方式对I/O性能的影响。

2.1 I/O数据传输中的瓶颈

2.1.1 硬件总线结构

本文以P4080平台为例,介绍I/O数据在信道传输过程中,可能造成瓶颈的磁盘阵列控制器的组件,P4080平台的硬件总线体系结构如图1所示。

主机数据传输到目标磁盘,必须经过主机通道、PCI总线、内部总线、内存、磁盘等多个部件。数据在这些部件的传输过程中,需要完成运算、存储和传输三种操作,运算包括对I/O请求数据的封装处理、分条处理、校验数据运算,这些操作主要由CPU完成。存储依赖于硬盘本身。传输依赖于主机通道、PCI总线、内部总线、内存传输能力。这些操作依赖于具体部件,处理性能也取决于相关硬件部件。

2.1.2 硬件吞吐率

I/O数据从主机通道到磁盘的过程中两次经过PCI总线,PCI传输阶段以及磁盘并发阶段必须复用PCI总线,即

P4080和IOP80331平台采用的PCI-E总线频率为125MHZ,总线位宽为64位,其理论带宽为

在I/O数据传输过程中,有三个阶段要访问内存。即PCI传输阶段需要将接收到的数据传递到内存缓冲区,CPU处理阶段对数据进行分条校验运算,分条数据最终经PCI转SATA桥片从内存存储到具体磁盘。

P4080处理器内部总线频率是1.5GHZ,位宽32bit,内部总线理论带宽

IOP80331处理器内部总线频率是800MHZ,位宽32bit,内部总线理论带宽

2.2 I/O数据的编码

冗余技术的底层编码结构有着多种实现方式,目前包括EVENODD、XCODE、HOVER、RS编解码等。

RS(Reed Solomon)编解码容错性能好,理论上没有上限,但计算代价高,数据量一增大,消耗时间非常大,目前此类编码应用在一些只读、归档、对实时性要求不高的存储系统中。

EVENODD码、X码是纠双错MDS阵列纠删码。Hover码容许三个以上盘同时故障。阵列纠删码码字成二维阵列分布,结构刚好符合磁盘阵列结构,是当前存储系统RAID技术广泛采用的编码方式。它的编译码只需要异或运算,软硬件实现简单、廉价,编译码速度快。

3 存储综合测评系统

测评系统采用P4080平台和IOP80331平台作为存储服务器,测试主机端使用IOmeter对存储服务器端发送I/O请求,具体配置参数如表1所示。

3.1 测评系统硬件平台

测评系统硬件平台的配置如表1所示。

3.2 测评系统拓扑结构

测试评价系统拓扑结构如图2所示。

3.3 测试方案

为了找到两种平台的最佳性能,在测试主机端不断增加并发数和worker数,同时监测两种平台下的CPU,内存,网络利用率并统计100%顺序读写I/O带宽。

4 测试数据

P4080平台测试数据如图3、图4所示。

随着worker数的增加,即不断给存储控制器施加压力,磁盘阵列控制器的顺序读吞吐量有一定幅度下降,1worker时读写性能最优,读吞吐量最大值已经达到112MBps,写的最大吞吐量为107MBps,顺序读写性能都已达到当前网络允许的最大流量。可见,如果要提升当前磁盘阵列控制器的顺序读写性能,应当把网络换成万兆网络并增加挂载的硬盘数量。

IOP80331平台测试数据如图5、图6所示。

随着队列深度的增加,磁盘阵列控制器的IO吞吐量并没有相应提升,而是一直保持在17MBps左右,也没有超过最大网络流量,这说明网络此时不是瓶颈。与此同时监测到磁盘阵列控制器端的CPU利用率已经到了77%,内存利用率99%以上,这充分说明了当前磁盘阵列控制器的内存就是瓶颈。

5 结论

本文从信号在信道中传输的角度,跟踪了I/O数据在整个存储系统传输过程中的处理方式,分析了可能造成存储系统瓶颈的原因,各种I/O数据冗余编码方式。最后设计了一套存储系统性能评估方案,评测了P4080平台和IOP80331平台的系统瓶颈并提出了解决方案。

摘要：通过追踪I/O数据在信道中的传输过程,分析了当前海量存储系统可能存在的瓶颈。指出了在硬件性能一定的情况下,编码技术在磁盘阵列中的应用,以及对存储系统的容错性和存取速度的贡献。本文最后提出了一种存储综合测评系统,具体评估了P4080和IOP80331平台的读写带宽和系统性能。

关键词：海量存储系统,磁盘阵列,I/O性能,冗余

参考文献

[1]曹强,黄健忠著.海量网络存储系统原理与设计.华中科技大学出版社,2010

[2]程耀东,汪璐.高性能海量存储系统研究.中国科学院高能物理研究所计算中心,2010

[3]杨照宏,于双和.分布式海量存储系统的可靠性和容错性研究,大连海事大学,2007

[4]金超,冯丹.容错存储系统的结构优化技术研究,华中科技大学,2011

[5]C.Huang and L.Xu.STAR:An EfficientCoding Scheme for Correcting TripleStorage Node Failures,FAST-2—5:4thUsenix Conference on File and StorageTechnologies,December,2005.

[6]JAMES LEE HAFANER,HOVER Erasure Codesfor disk arrays[R].Technical ReportRJ,IBM Research,San Jose,CA,2005.

[7]Peter Corbett,Bob English,Atua Goeletc.Row-Diagonal Parity for DoubleDisk Failure Correction.Proceedingsof the Third USENIX Conference onFile and Storage Technologies.SanFrancisco,CA,USA,March 31-April2,2004.

[8]J P.M.Chem.K.Lee etc.Performanceand Design Evaluation of the Raid-II Storage Server.Distributed andParallel Databases 2(3):243-260,1994.

CC2530普通I/O口的扩展 篇6

1 CC2530的I/O口扩展方法的总体思路及各组成工作原理

1.1 CC2530的I/O口扩展方法的总体思路

本扩展方法采用CC2530的I/O口模拟IIC总线的SCL和SDA, 通过IIC总线控制PCA9554芯片, 使串行通信变成并行通信。从理论上来讲CC2530芯片P1口的8个I/O口就可以连接4组IIC通信, 每组因扩展芯片地址A2A1A0的不同可同时支持8个芯片, 每个芯片又可控制8个端口。因此, CC2530的P1口从理论上就可支持128个 (4×8×8) 端口, 如图1所示。并且, 如果芯片固定的头地址不一样的话, 例如PCA9554和PCA9554A, 那么端口数量又可增加一倍, 这样P1口就扩展成了256个端。依此类推CC2530的I/O口通过扩展数量呈几十倍的增加, 可大大丰富I/O口的应用。

1.2 IIC总线工作原理

IIC总线只有两条线, 一条是数据线SDA, 另一条是时钟线SCL。数据线SDA在时钟线SCL的控制下可串行发送和接收数据, 传送速率最高达100kbps。各被控制器件均并联在这两条线上, 每个接到IIC总线上的器件都有唯一的地址, 通过不同地址决定通信对象, 如图1所示。这样, 各控制电路虽然挂在同一条总线上, 却彼此独立, 互不相关。IIC总线的优点是占用的空间非常小, 可避免线路互连而使电路板走线错综复杂的现象, 减少了电路板上的布线空间, 降低了互联成本。

IIC总线上只有四种信号:开始信号、停止信号、重新开始信号和应答信号。IIC总线上能实现主/从双向通讯, 器件发送数据到总线上, 则定义为发送器, 器件接收数据则定义为接收器。主器件和从器件都可以工作于接收和发送状态。IIC总线时序如图2所示。

1.3 PCA9554工作原理

PCA9554是带中断的GPIO扩展芯片, 它提供了IIC总线方式应用中的8位串行转并行输入/输出口的扩展。PCA9554共有4条命令, 在总线主控制器 (本文中为CC2530) 向PCA9554发送写数据过程中, 命令字节是紧跟地址字节, 之后第一个字节作为一个指针指向要进行写或读操作的寄存器。CC2530通过总线写I/O口的相应配置位来激活端口的输入或输出。通过给PCA9554的A2A1A03个管脚不同的电平来实现不同IIC地址, A2A1A03个管脚可组成8个地址码, 由此总线上最多允许挂8个PCA9554。而PCA9554与PCA9554A的IIC固定地址不同 (PCA9554的固定地址为01000A2A1A0, PCA9554的固定地址为01110A2A1A0) , 这样就允许16个器件 (PCA9554和PCA9554A各8个) 连接到同一个IIC总线上, 每个器件扩展出8个I/O端口, 这样CC2530的两个I/O端口就可扩展到8x16个I/O口。

2 扩展I/O口的应用

本应用通过CC2530的I/O口 (P1.0和P1.1) 模拟IIC总线的SCL和SDA, 然后通过IIC总线形式控制GPIO扩展芯片PCA9554, 最后通过扩展的IO来控制LED、蜂鸣器、按键信号、继电器等, 如图3、4所示。

3 结语

本文通过IIC总线形式控制GPIO扩展芯片PCA9554扩展CC2530的I/O口。在文主要提出了具体的硬件设计, 并运用于实践中。CC2530的I/O口进行扩展, 使I/O口的数量大大增多, 能丰富开发设计者的运用。

参考文献

[1]施邦平.采用I2C器件扩展单片机的多级通信[J].自动化与仪器仪表, 自动化与仪器仪表, 2006 (6) :63-64.