Tornado和VxWorks学习笔记

Tornado and vxWorks学习笔记-myc

环境配置相关:

1.tornado

2.2在启动时，弹出一个警告窗口如下：

Warning: Cannot find a valid Tornado Registry on host "".

You need to have access to a Tornado Registry to connect to any targets. For instructions on how to start the Tornado Registry, please refer to the documentation.

应该如何解决？

解决方法：启动Tornado后，选择Tool options→Tornado Registry→勾选Local registry。

问题原因：Tornado Registry即Tornado目标服务器注册表，这种注册表可以使主机通过名称连接目标服务器（运行主机工具的主机和运行目标服务器的机器可以不同）。也即说，这个注册表必须一致处于运行状态，否则主机工具就不能联系上运行目标服务器的机器，也就不能与目标机进行通信。

而由于我们的机器同时运行主机工具和目标服务器，因此，我们只需要将Tornado Registry建立为本地的就可以了。所以，要勾选Local registry。

（由于Tornado工具与目标机通信的方式无关，所以无论与目标机的通信方式是通过网络还是通过串口，注册表都是必须的。）

2.目标机代理执行的模式有三种：

㈠任务模式：目标机代理作为VxWorks的一个任务，用户可以再不影响目标系统运行的情况下隔离某个任务。

㈡系统模式

㈢双模式

3.Tornado Launch工具条是一个下拉列表，显示了当前运行的并注册过的目标服务器。如果没有目标服务器列出，

或没有用户需要的目标服务器，则用户必须配置和启动一个目标服务器。

4.目标服务器管理Tornado主机工具和VxWorks目标机代理间的通信。在主机工具与目标机交互前，必须针对该

目标机配置并启动目标服务器。

5.在Tornado内建立一个开发环境，具体步骤如下：

㈠设好目标机硬件

㈡定义主机环境变量，配置好网络软件；在\x86-win32\bin下，有torwars.bat脚本程序，用来设置环境变量；

网络要配置好TCP/IP协议，修改主机host文件。

㈢开启Tornado目标服务器注册表。

㈣指明目标机启动参数(boot parameters)，并启动目标机。（最开始学习的时候，没有目标机的话，就用VxSim 吧）

㈤配置并启动目标服务器(target sever)，目标服务器是管理主机开发工具和目标机通讯的。

6.VxWorks具有可移植性的原因是采用了模块化的设计，它将所有硬件的功能函数分别放到一系列库中，这些库

就称之为板级支持包BSP（Board support Package）。

7.BSP库为实现所有目标板上各种硬件的功能提供了相同的软件接口，包括如下功能：

㈠硬件初始化

㈡中断的产生与处理

㈢硬件时钟和定时器管理

㈣本地及总线存储空间映射

㈤设置存储空间大小

㈥等等

8.*在一块新的目标板上安装VxWorks操作系统是很困难滴，是因为我们不能无法使用VxWorks的开发工具，并且，

也没有相对应的BSP。但是，Tornado软件为我们提供了VxWorks的BSP开发工具包，这个BSP的开发工具包提供的一些策略可以使VxWorks的安装变得容易点。（BSP工具包的用户应该具备低级c语言和汇编语言的编程经验，熟悉设备驱动程序，熟悉中断处理程序以及软硬件之间的接口）

BSP工具包包含一套文献资料和一些软件。

其中，文献资料包括：①安装指南②用户手册

软件包括：

㈠BSP合法性测试包

㈡BSP模板

㈢驱动程序模板

㈣SCSI测试包（SCSI：small computer system interface，小型计算机系统接口）

9.在运行具有网络功能的vxsim full simulator的时候, 如果在启动targetServer时遇到如下错误:

Error: rpccore backend client Timed outfailed.

则需要检查以下几点:

1)检查ULIP虚拟网络适配器的ip地址是否配置为:192.168.255.254

2)VxWorks组件中, development tool components/WDB agent components/select WDB connection/中, 应当仅选

择WDB END driver connection选项.

同时, select WDB mode应当仅选择WDB task debugging选项.

3)Target Server的配置里面, Target Server Properties应当选择Back End(表示通过网口调试), Available Back处应

选择wdbrpc选项.

Target Name/Ip Address可以填目标机地址. 例如:192.168.255.1

(还有一次, 直接target server都打不开,之前一直好好的, 忽然间就出错了, 一直遇到这种错误:

error ：simulator failed to initialize before timeout

我是这么解决的: 先新建了一个project, 然后重新编译了一个最原始的vxworks.exe, 然后打开.

再之后又重新开之前的那个vxworks.exe 然后居然就正常了)

10.如果想要能够有ping功能, 需要包含组件network conmponents/networking protocols/network applications/PING

client.

11.如果vxsim0和vxsim1不能互相ping通, 但vxsim0和vxsim1可以ping通主机, 则说明组件:

network conmponents/networking protocols/core TCP/IP conmponents/ICMPv4没有被包含进去.

12.Simulator与其它主机的通信

假设host0(你的主机, simulator运行于此机上)的Ip为10.12.9.113, host1的Ip为10.12.9.129. 如果host1想与simulator通讯, 只需在host1的路由表中增加一项:

Route add 192.168.255.1 10.12.9.113 metric 1

然后可以分别在host1上ping 192.168.255.1和simulator上ping 10.12.9.129进行验证.

网络编程相关:

Tcp(基于连接的)编程

1.相关概念:

端口: RFC1700规定常用的端口号从0-1023, 1024-49151是已注册的端口号.

这个端口号很重要, 比如在客户机/服务器模型下, 服务器端有一个任务在指定的端口等待客户来连接(在vxworks当中, 是先通过listen函数监听端口, 然后accept函数接受来自client端的连接来实现的), 一旦连接上之后, 就可以按设计的数据交换方法和格式进行数据传送.

2.客户机/服务器通信过程:

对server来说, 包括如下几个步骤(注意:结构体struct sockaddr_in和struct sockaddr是不一样滴两个结构):

1)创建一个tcp socket.

eg: int sd=socket(AF_INET,SOCK_STREAM,0); /*其中, sd是socket描述符, 由socket函数返回. AF_INET得看Help文件具体才知道是什么意思, 反正大多都用这个. SOCK_STREAM 说明是建立的一个基于连接的socket, 也即tcp socket. */

2)分配一个server的端口给第1步中创建的socket. 也即让创建的那个socket和某个端口绑定起来, 否则server到

哪监听想要连过来的client呢? 绑定了之后相当于server就在这个端口这里等待client的连接请求了.

VxWorks下面, 是通过bind函数绑定socket和分配的端口的, 如下:

bind(sd,(struct sockaddr *)&serverAddr,sizeof(struct sockaddr_in))

这里的sd即是刚才的建立的socket, 可是端口号在哪里呢? 端口号是在serverAddr里面的一个成员里面存着的. serverAddr是struct sockaddr_in类型的结构体. 其中:

serverAddr.sin_family = AF_INET;/*这个AF_INET 我也不明白是何意*/

serverAddr.sin_port = htons(SERVER_NUM);/* SERVER_NUM 即为分配的端口号, 例如6000(随便自己分一个, 大于1023就ok了), htons是将主机字节序转换成网络字节序的意思, 因为端口号存在这个结构体当中规定是要存网络字节序滴! 所以这里要转换一下*/

这个结构体里还有其它两个变量, 一个是长度(暂时不知道是什么意思, 反正不填也没事). 还有一个是serverAddr.sin_addr.s_addr是用来存放server的ip地址的(经转换过的长整形ip地址), 这个地址在server上面也没什么用, 可以不填, 因为运行在server上的程序不必要还知道自己的ip地址, 但在client上运行的程序代码中, 这个地址就需要填了, 因为client需要通过server的ip地址来找寻建立socket连接的目标, 没有server ip地址, client就不知道该去找谁通信了

3)经过上面两步, socket和端口就绑定起来了. 我是这么理解滴:

第1步建立一个tcp socket, 就相当于找了一截水管, 端口号就相当于server上一个固定的洞口, 把socket和端口号绑定, 就相当于是把这截水管的一段连住那个洞口了. 连住之后, 就等待监听水管的另一头有没有人(client)把它也用个另一根管子接起来.

监听(listen函数):

Listen(sd, 4);/*可以理解为server这时在这里等着, 看看这个socket和端口结合体有没有client愿意伸跟水管和它连通, 4表示等待排列的最大连接数*/

4)接受(accept函数):

当server在listen的时候, 发现有个client想要和自己连接(即发现有个client也伸了一根水管想要和自己的水管接起来), 这个时候server就做出处理, 可以连接. 于是, accept函数就把server自己伸出去的水管和client伸过来的水管给连起来了. 同时, 还把client的一些相关信息给带了回来, 保存在结构clientAddr和返回值clientsd 里了. 如下:

clientsd=accept(sd,(struct sockadd*)&clientAddr,&clientLen); /*其中, clientsd 即表示client伸过来的socket描述符. Client的ip地址被保存在了clientAddr.sin_addr 中*/

当然了, 这里的clientLen最开始初始化的时候, 应该初始化为sizeof(struct sockaddr_in), 也即clientAddr的大小, 否则accept就得不到client的ip地址了(这是个很恶心的问题, 但是必须初始化一下, 具体为啥不知道, 得看help)

5)水管都接好了, 那就通信(”放水,接水”)吧, 如下:

recBytes=recv(clientsd,receiveMessage,sizeof(receiveMessage),0) ; /*从clientsd 里面接受数据, 数据存放在receiveMessage 这个buffer里面*/

对client来说, 就包括下面几个步骤:

1)建立一个Tcp socket.

2)把这个socket和server连接起来

注意: 这里说把socket和server连接起来, 并不是说把socket和server的socket连接起来. 因为client又没有监听机制, 并不知道server的socket是多少. 对于client来说, 知道的仅仅是server的ip地址以及分配的端口号(其实端口号就对应一种服务, 例如常用的端口号telnet(23), ftp(21), smtp(25), http(80)都是分配好的. 如果你想写一个telnet的client程序, 那么你就知道要用server的23号端口来进行通信).

连接的方法如下:

connect(sd,(struct sockaddr *)&serverAddr,sizeof(serverAddr));

(注意: 这里的serverAddr在初始化的时候, 一定一定一定要记得bzero一下, 否则connect的时候打死的连不上.)

其中, sd是client的socket, serverAddr. sin_family一般填AF_INET, serverAddr. sin_port就需要填写服务对应的端口号, serverAddr. sin_addr.s_addr 需要填写server端的ip地址(vxworks中需要用inet_addr函数将其转换成长整形的ip地址)

当client端发出connect请求, 如果此时server段空闲, 并accept了这个connet请求, 那么就可以进行通信了.

3)通信:

send(sd,sendMessage,sizeof(sendMessage),0); /*发送数据, sendMessage 即为需要发送的数据*/

udp(基于非连接的)编程

1.通信进程

对于server来说, 步骤如下:

1)建立socket (同tcp一样)

2)绑定端口(同tcp一样)

3)接受数据.

Udp通信由于不是面向连接的通信, 提供的是不可靠服务, 因此不需要建立连接. 直接可以接收数据.

Vxworks下面是通过recvfrom来实现. 如下:

recvfrom(sd,receiveMessage,sizeof(receiveMessage),0,(struct sockaddr_in*)&clientAddr,&clientLen);

/*其中, sd为socket, receiveMessage 为一个保存接收数据的buffer, clientAddr在函数返回的时候(也即接收到数据的时候)会将发送数据端的地址保存下来, clientLen为保存clientAddr长度的一个变量, 需要注意的是: 这个clientLen在recvfrom函数调用之前必须初始化为sizeof(struct sockaddr_in), 否则得不到发送端的地址!

这一点很恶心, 具体原因需见help*/

4)根据需要, 回复发送端. (如果不需要通知发送端数据已收到, 这步也可省略)

sendto(sd,responseMeg,sizeof(responseMeg),0,(struct sockaddr *)&clientAddr,clientLen);

/*其中, responseMeg 是回复的内容, clientAddr 即是通过recvfrom函数得到的发送端地址.*/

对于client来说, 步骤如下:

1)建立socket

2)发送数据

sendto(sd,sendMessage,sizeof(sendMessage),0,(struct sockaddr *)&serverAddr,sizeof(serverAddr));

/*其中serverAddr需要填的内容有sever端地址和端口号, sendMessage 为要发送的内容.*/

此处不需要绑定端口, 直接即可通过socket发送数据.

3)如果需要接受server端的回复, 可通过recvfrom函数接收消息.

MUX编程

1.相关概念.

END驱动与MUX接口概述

VxWorks下增强型网络驱动-END(EnhancedNetworkDriver)是一个数据链路层驱动程序,增强型网络驱动（END）是OSI模型中数据链路层的实现, 通过MUX函数与网络协议层通讯. END驱动程序是基于MUX模式, 网络驱动程序被划分为协议组件和硬件组件. MUX作为数据链路层和网络层之间的接口, 它管理网络协议接口和低层硬件接口之间的交互, 将硬件从网络协议的细节中隔离出来; 删除使用输入钩例程来过滤接收从协议来的数据包, 和删除了使用输出钩例程来过滤协议包的发送; 并且链路层上的驱动程序需要访问网络层（IP或其他协议）时, 也会调用相关的MUX例程. 值得注意的是, 网络层协议和数据链路层驱动程序不能直接通讯, 它们必须通过MUX. MUX的目的是提供一个接口, 隔离网络接口驱动和网络服务, MUX支持两种网络驱动接口类型: –END: Enhanced Network Driver, 一种面向帧结构的驱动.

–NPT: Network Protocol Toolkit, 一种面向分组的驱动，所有链路层信息被去除.

个人理解, 以交换机为例. 一个交换机的接口就是一个end driver, 物理层的信息暂时就不管了, 我们在编程时看到的是链路层. 也就是说, 这个enddriver在接受\发送数据包时都是以帧为单位的(比如说0x00,0x04,0x67,0x00,0x00,0x01,……). 假如现在要编写一个处理包的协议, 需要对帧进行处理, 那么在编写协议代码的时候, 需要通过mux来将end接口收到的包送到指定的处理函数里面. 同时, 需要发送包的时候, 将编辑或处理过的包通过mux送到end接口, 然后让end接口发送出去.

因此, mux是连接enddriver和协议之间的接口, 编写协议的人员即可以不用去理会driver的具体实现过程, 通过mux, 可以实现协议的灵活裁剪.

网络协议是OSI模型中网络层和传输层的实现.在基于END驱动vxWorks中,网络协议通过MUX接口与数据链路层进行通信,所有与具体网络接口相关的事务都在数据链路层驱动中进行处理,如发送和接收数据等.

2.muxBind函数

void * muxBind

(

char * pName, /* interface name, for example, ln, ei,... */

int unit, /* unit number */

BOOL (* stackRcvRtn) (void* , long, M_BLK_ID, LL_HDR_INFO * , void* ), /* receive function to be called. */

STATUS (* stackShutdownRtn) (void* , void* ),/* routine to call to shutdown the stack */

STATUS (* stackTxRestartRtn) (void* , void* ),/* routine to tell the stack it can transmit */

void (* stackErrorRtn) (END_OBJ* , END_ERR* , void* ),/* routine to call on an error. */

long type, /* protocol type from RFC1700 and many */

/* other sources (for example, 0x800 is IP) */

char * pProtoName, /* string name for protocol */

void * pSpare /* per protocol spare pointer */

)

For example:

muxBindCookie=muxBind(ifName,unit,StackRecvRtn,StackShutdownRtn,StackTxRestartRtn,StackErrorRtn,MYOWN_P ROTO,pProtoName,pSpare);

参数:

ifName: enddriver也即一个物理接口的名称.

unit: enddriver的编号.

StackRecvRtn: 用户自定义的用来处理接受到的包的函数, 函数原型为:

STATUS StackRecvRtn (void *pCookie ,long type, M_BLK_ID pMblk, LL_HDR_INFO * pLinkHdr,void *pSapre );

StackShutdownRtn: 关闭处理函数.

StackTxRestartRtn: 重启处理函数.

StackErrorRtn: 出错处理函数.

MYOWN_PROTO: 自己定义的一个协议类型, 如#define MYOWN_PROTO 0xfff9

pProtoName: 协议名称.

pSpare: 协议的备用指针, 可以用来存储一些需要的数据结构, 在muxBind之后, 该指针会传入到StackRecvRtn 函数中去.

muxBindCookie: 为muxBind的函数返回值指针. 这个Cookie记录了协议函数和enddriver之间的相关联信息. 有了这个cookie, 即可以方便的知道协议函数是和哪一个enddriver绑定了. 这个cookie指向的是一

个MUX_BIND_ENTRY结构, 当调用完muxBind之后, 也即当把用户自定义的包处理函数和enddriver绑

定之后, 这个结构的就会被填充起来记录相关信息. 具体如下:

typedef struct muxBindEntry

{

int unitNo; /* unit号*/

char devName[END_NAME_MAX]; /* 设备名*/

long netSvcType; /* 协议类型,值等于muxBind函数的type值, 如0xfff9 */

long netDrvType; /* network Driver type, 设备类型*/

UINT32 flags; /* BIB entry flags , 暂时不知道*/

END_OBJ* pEnd; /*绑定的end信息*/

void* pNetCallbackId; /*和用户传进的pSpare指针指向的内容一样*/

FUNCPTR addrResFunc; /* reference to Address resolution function */

FUNCPTR netStackRcvRtn; /* 用户定义的那个包处理函数地址*/

}MUX_BIND_ENTRY, *MUX_ID;

包处理函数的介绍:

muxBind函数的几个参数, 以stackRcvRtn函数最为重要了, 当一个enddriver接受到相应的(即符合定义的协议类型)包之后, 即会将包送至这个函数进行处理. 这里可能有些疑惑, 一个底层的driver, 如何会在接收到包之后即知道将包根据协议类型送至哪个函数处理? 这就是mux层的功劳了. 在系统启动的时候, 一个enddriver 会被加载(通过muxDevLoad函数实现的), muxDevLoad会默认将enddriver收到的包交给一个称之为muxReceive 的函数进行处理, 而事实上, 这个muxReceive函数是一个钩子函数, 用户在编写协议代码时调用muxBind, 即可以将用户自己定义的包处理函数的地址赋值给这个muxReceive函数指针. 因此, 底层的enddriver在接收到包之后, 即可将包送上来鸟.

包处理函数的原型为:

STATUS StackRecvRtn (void *pCookie ,long type, M_BLK_ID pMblk, LL_HDR_INFO * pLinkHdr,void *pSapre );

其中, pCookie和调用muxBind函数返回的那个cookie是一样的, type指协议类型, pMblk保存的即是接收到的包的内容, pLinkHdr暂时还不知道是什么东东, pSapre为备用指针, 其值为用户在调用muxBind时传入的那个pSpare.

至于pMblk指向的数据, 为一个M_BLK类型的结构体, 具体需要看vxworks关于内存池的管理相关类容才能具体了解了.

3.muxSend函数

muxSend函数的原型为:

STATUS muxSend(

void * pCookie, /* muxBind()函数返回的cookie */

M_BLK_ID pNBuff /* 要进行发送的数据包*/)

4.关于给vxsim发包的问题:

程序写好之后, 如何测试? 可以通过发包软件给vxsim发包. 然后观察vxsim收发包的情况.

vxsim0的地址可以通过在shell里ping “192.168.255.254”,3 这个命令让vxsim发包, 然后通过抓包软件获得vxsim 的mac地址!

我得到的vxsim0的mac地址是00:00:00:00:00:01.

发包的时候, 对着虚拟网卡发包, 目的地址写成vxsim的mac地址就ok了.(当然协议类型也要填对!)

5.附件, 看过的文章中, 对于mux层的解释.

1)END驱动与MUX接口概述

VxWorks下增强型网络驱动-END(EnhancedNetworkDriver)是一个数据链路层驱动程序,增强型网络驱动（END）是OSI模型中数据链路层的实现，通过MUX函数与网络协议层通讯。END驱动程序是基于MUX 模式，网络驱动程序被划分为协议组件和硬件组件。MUX作为数据链路层和网络层之间的接口，它管理网络协议接口和低层硬件接口之间的交互，将硬件从网络协议的细节中隔离出来；删除使用输入钩例程来过滤接收从协议来的数据包，和删除了使用输出钩例程来过滤协议包的发送；并且链路层上的驱动程序需要访问网络层（IP或其他协议）时，也会调用相关的MUX例程。值得注意的是，网络层协议和数据链路层驱动程序不能直接通讯，它们必须通过MUX。MUX的目的是提供一个接口，隔离网络接口驱动和网络服务,MUX支持两种网络驱动接口类型：

–END: Enhanced Network Driver，一种面向帧结构的驱动

–NPT: Network Protocol Toolkit，一种面向分组的驱动，所有链路层信息被去除。

2)用MUX-API实现网络协议

(1) 网络协议是OSI模型中网络层和传输层的实现.在基于END驱动vxWorks中,网络协议通过MUX接口与

数据链路层进行通信,所有与具体网络接口相关的事务都在数据链路层驱动中进行处理,如发送和接收数据等。

3)实现过程详解

*Step 1: 使用muxBind()函数将协议类型与特定的网络接口绑定

muxBind()函数原型如下:

void * muxBind

(

char * pName, /* interface name, for example, ln, ei,... */

int unit, /* unit number */

BOOL (* stackRcvRtn) (void* , long, M_BLK_ID, LL_HDR_INFO * , void* ),

/* receive function to be called. */

STATUS (* stackShutdownRtn) (void* , void* ),

/* routine to call to shutdown the stack */

STATUS (* stackTxRestartRtn) (void* , void* ),

/* routine to tell the stack it can transmit */

void (* stackErrorRtn) (END_OBJ* , END_ERR* , void* ),

/* routine to call on an error. */

long type, /* protocol type from RFC1700 and many */

/* other sources (for example, 0x800 is IP) */

char * pProtoName, /* string name for protocol */

void * pSpare /* per protocol spare pointer */

)

其中: pName为网络接口的名字, unit为接口号, stackRcvRtn为协议数据处理函数,负责对接收的数据(或者发送的数据,当协议类型为MUX_PROTO_OUTPUT时), stackShutdownRtn, stackTxRestartRtn, stackErrorRtn 分别为关闭,重启和错误处理函数, 若不用则设置为NULL, type为指定的协议类型, pProtoName为协议名称, pSpare为每个协议的备用指针

协议类型及含义:

MUX_PROTO_SNARF: 在所有标准协议接收之前调用stackRcvRtn()处理函数;

MUX_PROTO_PROMISC: 在所有标准协议接收之后调用stackRcvRtn()处理函数;

MUX_PROTO_OUTPUT: 在数据被送到物理层(DRIVER)之前调用stackRcvRtn()函数.

在用muxSend()发送数据时,需要从网络数据缓冲池中申请内存,这里需要用到END_OBJ指针,

取得END_OBJ 的方法

第一种方法:

END_OBJ * endFindByName

(

char * pName, /* device name to search for */

int unit

)

第二种方法:

利用muxBind()的返回值(void类型的指针),将此指针强制转换为MUX_ID类型(声明在系统头文件"private/muxlibP.h"中),其中的pEnd成员即我们需要的END_OBJ指针.如下:

pEnd = ((MUX_ID)pSendCookie)->pEnd;

/* 接收(或者发送)处理函数[也可以说是过滤函数] */

BOOL stackRcvRtn

(

void * pCookie, /* returned by muxBind() */

long type, /* from RFC1700, or user-defined */

M_BLK_ID pNetBuff, /* packet with link-level info */

LL_HDR_INFO * pLinkHdr, /* link-level header info structure */

void * pSpare /* defined on a per-protocol basis */

)

{

/*process code here*/

return(FALSE/*or TRUE*/);

}

若stackRcvRtn()返回TRUE,则该数据包将不再被传递至上层协议或底层DRIVER

(当为MUX_PROTO_OUTPUT类型时);否则该数据包将继续向上或向下传递.

/*muxSend()发送数据包*/

管道

#include "vxWorks.h"

#include "ioLib.h"

#include "selectLib.h"

#define pipeName1 "pipe1" /*命名管道1的名称*/

#define pipe1MaxMesgNum 2 /*管道1可以容纳的消息数*/

#define pipeName2 "pipe2" /*命名管道2的名称*/

#define pipe2MaxMesgNum 2 /*管道2可以容纳的消息数*/

#define eachMesgMaxByte 50 /**每个消息的最大字节数/

#define STATUS int

STATUS task1();

STATUS task2();

STATUS task3();

STATUS pipeTaskInit()

{

int taskId1,taskId2;

/*创建两个管道, task1,task2分别往管道1和2里发送消息,task3用select函数从管道接收消息*/ if(pipeDevCreate(pipeName1,pipe1MaxMesgNum,eachMesgMaxByte)!=OK)

return ERROR;

if(pipeDevCreate(pipeName2,pipe2MaxMesgNum,eachMesgMaxByte)!=OK)

return ERROR;

if((taskId1=taskSpawn("task1",100,0,10000,(FUNCPTR)task1,0,0,0,0,0,0,0,0,0,0))==ERROR) return ERROR;

if((taskId2=taskSpawn("task2",100,0,10000,(FUNCPTR)task2,0,0,0,0,0,0,0,0,0,0))==ERROR) return ERROR;

if((taskId2=taskSpawn("task3",100,0,10000,(FUNCPTR)task3,0,0,0,0,0,0,0,0,0,0))==ERROR) return ERROR;

return OK;

}

STATUS task1()

{

int pipeFd1=0;

int nBytes=0;

char mesgTask1[]="task1 send message!"; /*发送的消息*/

if((pipeFd1=open(pipeName1,O_RDWR,0))==ERROR) /*利用open函数打开管道1, 返回一个fd*/ return ERROR;

while(1)

{

if((nBytes=write(pipeFd1,mesgTask1,sizeof(mesgTask1)))==ERROR) /*往管道1里面写(发送)数据*/

return ERROR;

taskDelay(sysClkRateGet());

}

return OK;

}

STATUS task2()

{

int pipeFd2=0;

int nBytes=0;

char mesgTask2[]="task2 send message!";

if((pipeFd2=open(pipeName2,O_RDWR,0))==ERROR) /*利用open函数打开管道2, 返回一个fd*/ return ERROR;

while(1)

{

if((nBytes=write(pipeFd2,mesgTask2,sizeof(mesgTask2)))==ERROR) /*往管道2里面写(发送)数据*/ return ERROR;

taskDelay(2*sysClkRateGet());

}

return OK;

}

STATUS task3()

{

int pipeFd1=0,pipeFd2=0;

char messageBuf[50];

fd_set fdset;

memset(messageBuf,0,sizeof(messageBuf));

if((pipeFd1=open(pipeName1,O_RDWR,0))==ERROR)

return ERROR;

if((pipeFd2=open(pipeName2,O_RDWR,0))==ERROR) /*利用open函数分别得到管道1和2的fd */ return ERROR;

while(1)

{/*注意, 以下三行代码不能放错位置了, 最初我就是放在了循环体外面, 导致任务2挂起了.*/ FD_ZERO(&fdset); /*将文件描述符集合全部置0*/

FD_SET(pipeFd1,&fdset); /*置位管道1的文件描述符pipeFd1*/

FD_SET(pipeFd2,&fdset); /*置位管道2的文件描述符pipeFd2*/

select(FD_SETSIZE,&fdset,NULL,NULL,NULL);/*select函数监听管道, 注意, select函数应该是这样一个机制, 监听的是fdset中被置位的fd所对应的文件描述符, 在监听到有fd可读(可写)时, 就把fdset中不可读的fd置0, 可读的不变(仍然置1), 然后返回. 这样一来, 下面就可以通过FD_ISSET宏来确定在fdset中, 是哪一个fd可读了, 也即可以从中读取数据了. 但是呢, 在下一次监听之前, 就必须要将fdset中待监听的fd重新置位一遍才可以, 这也是为什么上述三行代码不能放在循环体之外的原因. */

if(FD_ISSET(pipeFd1,&fdset)) /*检测管道1是否可读*/

{

read(pipeFd1,messageBuf,eachMesgMaxByte);

printf("\r\n %s",messageBuf);

memset(messageBuf,0,sizeof(messageBuf));

}

if(FD_ISSET(pipeFd2,&fdset)) /*检测管道2是否可读*/

{

read(pipeFd2,messageBuf,eachMesgMaxByte);

printf("\r\n %s",messageBuf);

memset(messageBuf,0,sizeof(messageBuf));

}

}

return OK;

}