Vxworks嵌入式操作系统下网络设备驱动程序设计
“钢厂小霸王”通过精心收集，向本站投稿了9篇Vxworks嵌入式操作系统下网络设备驱动程序设计，下面小编为大家带来整理后的Vxworks嵌入式操作系统下网络设备驱动程序设计，希望大家能够受用!
篇1：Vxworks嵌入式操作系统下网络设备驱动程序设计
作者Email: cai_yang@etang.com
摘 要：本文主要介绍在Vxworks操作系统下网络设备驱动程序设计、调试方法以及将其加入系统内核的配置方法。
篇2：Vxworks嵌入式操作系统下网络设备驱动程序设计
引 言
VxWorks操作系统是美国WindRiver公司于1983年设计开发的一种嵌入式实时操作系统（RTOS），是嵌入式开发环境的关键组成部分。良好的持续发展能力、高性能的内核以及友好的用户开发环境，在嵌入式实时操作系统领域占据一席之地。它以其良好的可靠性和卓越的实时性被广泛地应用在通信、军事、航空、航天等高精尖技术及实时性要求极高的领域中，如卫星通讯、军事演习、弹道制导、飞机导航等。
1 嵌入式系统
嵌入式系统是以嵌入式计算机为技术核心，面向用户、面向产品、面向应用，软硬件可裁减的，适用于对功能、可靠性、成本、体积、功耗等综合性严格要求的专用计算机系统。和通用计算机不同，嵌入式系统是针对具体应用的专用系统，目的就是要把一切变得更简单、更方便、更普遍、更适用；它的硬件和软件都必须高效率地设计，量体裁衣、去除冗余，力争在同样的硅片面积上实现更高的性能。
嵌入式系统主要由嵌入式处理器、外围硬件设备、嵌入式操作系统以及特定的应用程序等四部分组成，是集软硬件于一体的可独立工作的“器件”；用于实现对其它设备的控制、监视或管理等功能。
嵌入式系统应具有的特点是：要求高可靠性；在恶劣的环境或突然断电的情况下，要求系统仍然能够正常工作；许多嵌入式应用要求实时处理能力，这就要求嵌入式操作系统(EOS)具有实时处理能力；嵌入式系统中的软件代码要求高质量、高可靠性，一般都固化在只读存储器中或闪存中，也就是说软件要求固态化存储，而不是存储在磁盘等载体中。
2 设备驱动程序
Vxworks5.4中驱动程序主要分为三种：字符、块以及网络驱动程序。本文所介绍的网卡驱动程序则属于网络设备驱动程序。
2.1 网络设备驱动程序设计
网络的各功能部件图1所示，网络设备驱动程序实际上是处理硬件和上层协议之间的接口程序。网络传输协议层分发数据在应用程序接口和网络接口之间。网络化网络协议（如IP协议）发送数据在网络主机之间。连接/接口层使能主机隶属于硬件到相同物理媒质的通信。
在Vxworks5.4中，网卡驱动程序又分为END（Enhanced Network Driver）和BSD两种。它们分别处于如图2所示结构中。
2.1.1 BSD驱动程序设计
在Vxworks5.4中，网络驱动程序都是基于BSD UNIX版本4.3基础上的，这些驱动程序都定义在一个全局例程中，那就是attach子程序，xxattach( )子程序中包含5个函数指针，它们都被映射到ifnet结构中，这5个函数可见表1，它们在IP协议层任何地方被调用。
表1 网络接口处理
驱动程序指定函数
函数指针
功能
xxInit
if_init
初始化接口
xxOutput()
if_output
对要传输的输出分组进行排队
xxIoctl()
if_ioctl
处理I/O控制命令
xxReset()
if_reset
复位接口设备
xxWatchdog()
if_watchdog(optional)
周期性接口例程
驱动程序入口xxattach( )调用ether_attach( )来把上述5个函数映射到ifnet结构中，ether_attach( )调用如下：
ether_attach(
(IFNET *) & pDrvCtrl->idr,
unit,
“xx”,
(FUNCPTR) NULL,
(FUNCPTR) xxIoctl,
(FUNCPTR) ether_output( ), /* generic ether_output */
(FUNCPTR) xxReset
);
pDrvCtrl->idr.ac_if.if_start = (FUNCPTR)xxTxStartup;
上述参数中，需要一个接口数据记录（Interface Data Record (idr)），unit号和设备名，下面四个参数就是相关驱动程序的函数指针。第一个函数指针指的是init( )例程，这个例程可要可不要，第二个函数指针指的是ioctl( )接口，它允许上层来控制设备状态；第三个函数指针指的是把数据包送到物理层；最后一个函数指针指的是如果TCP/IP堆栈决定需要复位的话，它就复位这个设备。
接着下面那一句代码表示添加数据传输例程到IDR，ether_output( )例程被调用后，传输开始例程就被TCP/IP协议堆栈调用。
在这个入口驱动程序中还包括设备的初始化、发送和接收描述符的初始化等。
2.1.2 END驱动程序设计
END驱动程序是基于MUX模式，网络驱动程序被划分为协议组件和硬件组件。MUX数据链路层和网络层之间的接口，它管理网络协议接口和低层硬件接口之间的交互；将硬件从网络协议的'细节中隔离出来；删除使用输入钩例程来过滤接收从协议来的数据包，和删除了使用输出钩例程来过滤协议包的发送；并且链路层上的驱动程序需要访问网络层（IP或其他协议）时，也会调用相关的MUX例程。值得注意的是，网络层协议和数据链路层驱动程序不能直接通讯，它们必须通过MUX。如图3所示：
2.3将驱动程序加载到Vxworks系统中
要对所设计的驱动程序进行测试，首先就必须把驱动程序加载到Vxworks IMAGE中，并且给设备分配一个IP，这样才能有利于网间测试。
首先，修改configNet.h文件，添加如下代码：
#ifdef INCLUDE_DM_9102_END
#define DM_9102_BUFF_LOAN_0 1
#define DM_9102_LOAD_FUNC sysDm9102EndLoad
#define DM_9102_LOAD_STR_0 “”
IMPORT END_OBJ * DM_9102_LOAD_FUNC (char *, void *);
和END_TBL_ENTRY endDevTbl [] 中添加
#ifdef INCLUDE_DM_9102_END
{0, DM_9102_LOAD_FUNC, DM_9102_LOAD_STR_0, TRUE, NULL, FALSE},
#endif /* INCLUDE_DM_9102_END */
其次，编辑config.h文件，添加如下代码：
#define INCLUDE_DM_9102_END /* Davicom 9102 Fast Ethernet Controller */
最后，编辑sysLib.c文件，添加如下代码：
/* include dm9102 End driver support routines */
#ifdef INCLUDE_DM_9102_END
IMPORT STATUS sysDm9102PciInit (void);
#endif /* INCLUDE_DM_9102_END */
/* include dm9102End driver support routines */
#ifdef INCLUDE_DM_9102_END
#include “sysDm9102End.c”
#endif /* INCLUDE_DM_9102_END */
#ifdef INCLUDE_DM_9102_END
sysDm9102PciInit ();
#endif /* INCLUDE_DM_9102_END */
通过上述过程相应的添加程序，然后重新编译Vxworks，这样就将所设计的网卡驱动程序添加到Vxworks内核中了。
2.4 PCI设备检测
如果所设计的网卡是基于PCI总线的，那么在程序开始就需要对PCI设备进行检测，在Vxworks5.4中有专门的PCI函数来检测设备的总线号、设备号和功能号。首先利用pciFindDevice( )函数对给定VendorID和DeviceID的设备进行检测，检测完后同时给出了设备的总线号、设备号和功能号；接下来就是获得该设备的中断号、基地址（包括IO和内存）。Vxworks中pciConfigLib.h文件中定义PCI总线的常量。如中断号：PCI_CFG_BRG_INT_LINE，IO基地址：PCI_CFG_BASE_ADDRESS_0，内存基地址：PCI_CFG_BASE_ADDRESS_1等等。所以利用函数pciConfigInByte和pciConfigInLong就可以很容易地获得设备的中断号和基地址。
2.5 调试方法
为了方便调试网卡驱动程序，推荐利用串口对程序进行下载并将Vxworks image拷贝到软盘中以从软盘来加载它。调试的时候首先应该给网卡分配一个IP（利用usrNetIfConfig函数），然后利用ping来对网卡进行测试。
3 结语
利用上述方法所设计的网卡后，不久可以利用它来进行程序下载，而且能满足网卡所有的功能，包括对TCP/IP和UDP/IP（组播、广播和单播）进行了测试。
篇3：Vxworks嵌入式操作系统下网络设备驱动程序设计
Vxworks嵌入式操作系统下网络设备驱动程序设计
作者Email: cai_yang@etang.com
摘 要：本文主要介绍在Vxworks操作系统下网络设备驱动程序设计、调试方法以及将其加入系统内核的配置方法。
关键词：Vxworks 嵌入式操作系统 网络设备
引 言
VxWorks操作系统是美国WindRiver公司于1983年设计开发的一种嵌入式实时操作系统（RTOS），是嵌入式开发环境的关键组成部分。良好的持续发展能力、高性能的内核以及友好的用户开发环境，在嵌入式实时操作系统领域占据一席之地。它以其良好的可靠性和卓越的实时性被广泛地应用在通信、军事、航空、航天等高精尖技术及实时性要求极高的领域中，如卫星通讯、军事演习、弹道制导、飞机导航等。
1 嵌入式系统
嵌入式系统是以嵌入式计算机为技术核心，面向用户、面向产品、面向应用，软硬件可裁减的，适用于对功能、可靠性、成本、体积、功耗等综合性严格要求的专用计算机系统。和通用计算机不同，嵌入式系统是针对具体应用的专用系统，目的就是要把一切变得更简单、更方便、更普遍、更适用；它的.硬件和软件都必须高效率地设计，量体裁衣、去除冗余，力争在同样的硅片面积上实现更高的性能。
嵌入式系统主要由嵌入式处理器、外围硬件设备、嵌入式操作系统以及特定的应用程序等四部分组成，是集软硬件于一体的可独立工作的“器件”；用于实现对其它设备的控制、监视或管理等功能。
嵌入式系统应具有的特点是：要求高可靠性；在恶劣的环境或突然断电的情况下，要求系统仍然能够正常工作；许多嵌入式应用要求实时处理能力，这就要求嵌入式操作系统(EOS)具有实时处理能力；嵌入式系统中的软件代码要求高质量、高可靠性，一般都固化在只读存储器中或闪存中，也就是说软件要求固态化存储，而不是存储在磁盘等载体中。
2 设备驱动程序
Vxworks5.4中驱动程序主要分为三种：字符、块以及网络驱动程序。本文所介绍的网卡驱动程序则属于网络设备驱动程序。
2.1 网络设备驱动程序设计
网络的各功能部件图1所示，网络设备驱动程序实际上是处理硬件和上层协议之间的接口程序。网络传输协议层分发数据在应用程序接口和网络接口之间。网络化网络协议（如IP协议）发送数据在网络主机之间。连接/接口层使能主机隶属于硬件到相同物理媒质的通信。
在Vxworks5.4中，网卡驱动程序又分为END（Enhanced Network Driver）和BSD两种。它们分别处于如图2所示结构中。
[1] [2] [3] [4] [5]
篇4：QNX操作系统及网络设备驱动模块
摘要：介绍嵌入式操作系统QNX的微内核结构、基于io-net的网络子系统、网络设备驱动程序的组成；给出以以太网网设备驱动程序为例的详细说明，包括初始化、从网络设备接收数据，向网络设备发送数据和网络设备信息的统计。
关键词：QNX 网络 驱动程序
QNX是业界公认的X86平台上最好的嵌入式实时操作系统之一。它具有独一无二的微内核实时平台，建立在微内核和完全地址空间保护基础之上，实时、稳定、可靠，已经完成到PowerPC、MIPS、ARM等内核的移植，成为在国内广泛应用的嵌入式实时操作系统。本文简单介绍QNX内核和网络结构的特点，针对目前热门的网络应用环境，讨论QNX网络设备驱动程序的结构和编写。
1 QNX内核简介
QNX的微内核结构是它区别于其它操作系统的显著特点。目前嵌入式系统中，操作系统和应用程序之间的关系大概可以归纳为图1～图3所示的三种情况。
平板式内存结构，如图1所示，所有的程序都使用同一个地址空间，不加保护；应用程序可以自由访问所有空间，效率较高，但是任何应用程序指针错误都可能会导致内核崩溃。
大内核内存结构，如图2所示，操作系统内核和各种驱动程序、网络协议在同一个地址空间，应用程序在单独空间；内核模块同处于一个保护空间，运行效率高，(本网网收集整理)应用程序无法直接访问保护空间，系统稳定性大大提高。缺点是，由于内核模块（例如网络驱动)处于保护空间，因此调试困难，任何驱动程序的修改都要重新编译内核，无法做到驱动的动态加载和卸载。
QNX的微内核结构，如图3所示，内核独立自处于一个被保护的地址空间；驱动程序、网络协议和应用程序处地程序空间中。
微内核结构的优点：①驱动程序、网络协议、文件系统等操作系统模块和内核相互独立，任何模块的故障都不会导致内核的崩溃；②驱动程序、网络协议、文件系统和应用程序都处于程序空间，都调用相同的内核API，开发与调试和应用程序没有区别；③操作系统功能模块可以根据需要动态地加载或卸载，不需要编译内核。在高可靠性要求的情况下，可以编写监视模块，对可靠性要求高的模块进行监视，必要的时候重新启动或重新加载而无须重启系统。高可靠性的内核结构使QNX具备了高可靠性嵌入式操作系统的本质特征。
在具有高可靠性内核的基础上，QNX的创新设计使它同样具有很高的效率。QNX最为引人注目的地方是，它是UNIX的同胞异构体，保持了和UNIX的高度相似性，绝大多数UNIX或LINUX应用程序可以在QNX下直接编译生成。这意味着为数众多的稳定成熟的UNIX、LINUX应用可以直接移植到QNX这个更加稳定高效的.实时嵌入式平台上来。
2 QNX网络结构
QNZ网络子系统由三个部分组成：网络管理模块（io-net）、网络协议模块（npm-qnet.so、npm-tcpip.so）、网络设备驱动模块（devn-ne.so）。
模块之间的层次关系如图4所示。
图4中的每个模块各自具有不同的功能，但是它们具有一些相同的属性。如：网络设备驱动、TCP/IP协议栈分别对上层io-net模块和应用程序产生数据，两者都可以被看作数据源；同时它们也接受上层发来的数据，又可以同时被看作数据的消费者。过滤模块对向上的数据进行筛选，分协议进行处理；对向下的数据则进行相应的转换，如进行网络地址转换NAT。转换模块负责不同协议帧结构的转换，在以太网的工作环境下，它就负责对IP数据报进行以太网帧的封装和解包。
和QNX其它服务进程一样，QNX的网络子系统也在内核外部空间运行。应用程序面对的是一个统一的网络接口，硬件相关的内容被完全包装在网络子系统内。
QNX网络子系统的三个子模块按层次分开，io-net模块处于中心，是QNX网络的核心和重点，其它模块都挂接在它上面。数据和信息的流动都必须经由io-net调度与转发，所有其它模块所面对的就是一个单一主体。这样的中心交换结构，屏蔽了各个模块间相互协调的复杂细节，在很大程序上方便了模块的编写工作；同时，io-net还是QNX的网络管理中心。任何网络协议和网络设备驱动程序都必须向io-net注册，由它来加载，并接受io-net的配置和管理，用户对网络状态的查询和管理也是通过io-net来实现的。
篇5：QNX操作系统及网络设备驱动模块
QNX网络设备驱动模块处于网络硬件和io-net模块之间。驱动模块负责配置硬件使其正常工作，向io-net报告数据收发情况，接收和传递数据，接受io-net的调度和管理。QNX网络设备驱动程序依照以上功能，分为初始化、接收发送数据、网络设备信息统计几个功能块。要使网络设备工作正常，驱动程序就要对它进行一定的寄存器配置，同时，还要向QNX网络子系统注册自己，表明网络设备的存在和网络通信能力，才能为系统和应用程序所用。在初始化工作完成以后，网络设备就进入了工作状态，收发数据。设备信息的统计也是由设备驱动程序来完成的。
(1)初始化
初始化包括两个方面，一方面是初始化网络设备，使其正常工作；另一个方面，是向io-net正确注册驱动模块，表明自己的属性，方便上层正确操作。网络设备的初始化工作和硬件紧密相关，这里就不一一描述。
驱动模块向io-net加载自己的时候，系统遵循如下工作流程：
①io-net搜索全局的符合io_net_dll_entry。它定义了驱动的初始化函数，io-net会直接调用这个函数。
②初始化函数向io-net注册驱动和相应的函数。
③初始化函数告诉io-net和它的模块自己的通信能力。
经过以上流程以后，io-net中就建立起有关此驱动程序的数据和函数调用列表。驱动程序必须正确编写初始化函数，并将该函数正确链接至io_net_dll_entry。
（2)从网络设备接收数据
当有包到达网络设备的时候，网络设备就会用某种方式通知驱动程序（例如中断），此时，驱动程序就要采取某种策略来处理到来的帧或数据。通常驱动程序这时候需要做以下工作：
①通过DMA将包取回来；
②做相应的必要处理，如通知网络设备释放当前帧的缓存，配置寄存器让网络设备等待下一帧到来等；
③通过调用io-net的tx_up_start函数把包传递给上层模块。
当上层所有的模块都完成对这个包的处理以后，io-net调用我们驱动中的tx_done函数，它来做最后的处理工作。
tx_up_start（）函数是设备驱动中比较关键的函数，下面简要部分一下这个函数的入口参数。
npkt_t*(*tx_up_start)(int registrant_hdl，
nptk_t *npkt,
int off,
int framelen_sub,
uint16_t cell,
uint 16_t endpoint,
uint16_t iface，
void *done_hdl)
其中:int registrant_hdl--本驱动在io-net中的句柄，注册时由io-net生成；
nptk_t *npkt --需要处理的包的指针；
int off--底层协议包头长度，如以太网帧头部长度；
int framelen_sub--尾部填充的长度，对于以太网这个值为零；
uint16_t cell、uint16_t endpoint--endpoint和cell是io-net在注册的时候分配的用来区别不同的驱动；
uint16_t iface--接口号，可以让同一个驱动负现多个相同硬件；
void *done_hdl--该指针指向tx_done（）函数需要的额外数据。
（3）向网络设备发送数据
当上层模块需要硬件传送包的时候，会调用io-net管理器的rx_down()函数。
int(*rx_down)(npkt_t*npkt，
void *func_hdl）
rx_down函数入口参数中，npkt是指向需要传送的数据的结构指针，func_hdl是相应驱动模块在io-net中的句柄。其中npt结构包含许多成员，其中的重要成员如表1所列。
表1
cell、endpoint、iface需要处理该包的硬件标识buffers指向包的指针tot_iov包含数据包的所有I/O矢量Framelen所有数据的长度，以字节为单位驱动模块在接收到io-net的调用后，就要配置网络设备，让它完成数据的发送工作。网络设备发送数据所需要的信息都会在相应的数据结构中，如net_buf_t结构中保存了等待传送的数据包的链接列表，配置DMA所需的物理地址在net_iov_t中等。驱动模块要等待硬件完成这些包的传送，并调用io-net的tx)done（）函数通知上层模块驱动程序已经完成了数据的发送。
4 网络设备信息的统计
应用程序或者用户可以通过网络信息接口nicinfo工具来了解网络工作状态。信息的查询都是通过io-net来进行的。驱动程序必须维护相应的状态数据，方便io-net的查询。网络设备有一些共同的状态属性，如收到和发出的包的个数、发送错误的包的个数等，不同的网络设备还会具有不同的属性和状态，这些都可以在驱动程序中用数据结构详细列明。
需要维护的数据结构中，主要的是Nic_t，它包括四个子结构；
CustNicStats--网络信息入口；
EthernesStats_t--以太网状态；
GenStats_t--常用统计信息；
NetStats_t--网络信息（包含常用统计信息）。
以上是驱动程序需要维护的数据。当用户或应用程序要查询这些信息的时候，它们就通过Nicinfo工具对/dev/io-net/en0调用devctl()函数来取得网络信息。信息的取得是必须通过io-net来完成的，io-net对信息的查询则是通过调用io_net_register_funs_t结构中所指向的函数来取得信息的。例：
#include
int generic_eth_devctl(void *hdl,int dcmd,void ＊data,size_t size,int ＊ret）
{
Nic_t ＊nic=(Nic_t ＊)hdl；
int status;
status=EOK;
switch(dcmd){
case DCMD_IO_NET_NICINFO;
memcpy(data,nic,min(size,sizeof(Nic_t)));
break;
default:
status=ENOTSUP;
break;
}
return(status）；
}
结语
网络设备的驱动是网络系统的最低层和最基础的模块，是如今嵌入式开发中首先要解决的问题之一。由于QNX具有微内核的特点，其网络设备驱动程序的开发不需要内核调试，更适合初学者掌握。本文对QNX操作系统及网络设备驱动程序的介绍，可以帮助读者对相关内容作初步了解。
篇6：QNX操作系统及网络设备驱动模块
QNX操作系统及网络设备驱动模块
摘要：介绍嵌入式操作系统QNX的微内核结构、基于io-net的网络子系统、网络设备驱动程序的组成；给出以以太网网设备驱动程序为例的详细说明，包括初始化、从网络设备接收数据，向网络设备发送数据和网络设备信息的统计。关键词：QNX 网络 驱动程序
QNX是业界公认的X86平台上最好的嵌入式实时操作系统之一。它具有独一无二的微内核实时平台，建立在微内核和完全地址空间保护基础之上，实时、稳定、可靠，已经完成到PowerPC、MIPS、ARM等内核的移植，成为在国内广泛应用的嵌入式实时操作系统。本文简单介绍QNX内核和网络结构的特点，针对目前热门的网络应用环境，讨论QNX网络设备驱动程序的结构和编写。
1 QNX内核简介
QNX的微内核结构是它区别于其它操作系统的显著特点。目前嵌入式系统中，操作系统和应用程序之间的关系大概可以归纳为图1～图3所示的三种情况。
平板式内存结构，如图1所示，所有的程序都使用同一个地址空间，不加保护；应用程序可以自由访问所有空间，效率较高，但是任何应用程序指针错误都可能会导致内核崩溃。
大内核内存结构，如图2所示，操作系统内核和各种驱动程序、网络协议在同一个地址空间，应用程序在单独空间；内核模块同处于一个保护空间，运行效率高，应用程序无法直接访问保护空间，系统稳定性大大提高。缺点是，由于内核模块（例如网络驱动)处于保护空间，因此调试困难，任何驱动程序的修改都要重新编译内核，无法做到驱动的动态加载和卸载。
QNX的微内核结构，如图3所示，内核独立自处于一个被保护的地址空间；驱动程序、网络协议和应用程序处地程序空间中。
微内核结构的优点：①驱动程序、网络协议、文件系统等操作系统模块和内核相互独立，任何模块的故障都不会导致内核的崩溃；②驱动程序、网络协议、文件系统和应用程序都处于程序空间，都调用相同的内核API，开发与调试和应用程序没有区别；③操作系统功能模块可以根据需要动态地加载或卸载，不需要编译内核。在高可靠性要求的情况下，可以编写监视模块，对可靠性要求高的模块进行监视，必要的`时候重新启动或重新加载而无须重启系统。高可靠性的内核结构使QNX具备了高可靠性嵌入式操作系统的本质特征。
在具有高可靠性内核的基础上，QNX的创新设计使它同样具有很高的效率。QNX最为引人注目的地方是，它是UNIX的同胞异构体，保持了和UNIX的高度相似性，绝大多数UNIX或LINUX应用程序可以在QNX下直接编译生成。这意味着为数众多的稳定成熟的UNIX、LINUX应用可以直接移植到QNX这个更加稳定高效的实时嵌入式平台上来。
2 QNX网络结构
QNZ网络子系统由三个部分组成：网络
[1] [2] [3] [4] [5]
篇7：VxWorks下PC/104-CAN驱动程序设计
VxWorks下PC/104-CAN驱动程序设计
摘要：详细介绍实时多任务操作系统VxWorks环境下驱动程序的设计原理；针对驱动程序实现的困难，给出VxWorks下实现驱动程序的工作步骤。文件以PC/104-CAN适配卡为例，简要介绍硬件结构，重点给出驱动程序实现的关键代码。关键词：RTOS VxWorks PC/104 CAN I/O系统 驱动系统
VxWorks是一款优秀的实时多任务操作系统，具有抢占式调试、中断延迟小等特点。本文在简要介绍必备的硬件环境下，以VxWorks为平台，详细介绍驱动程序的开发。
1 PC/104-CAN适配卡的硬件结构
PC/104-CAN适配卡主要由CAN控制器（SJA1000）、光电隔离（6N137），收发驱动器（82C250）及译码电路组成。编程主要了解的是控制器SJA1000。CAN适配卡原理如图1所示。
(本网网收集整理)
2 CAN地址译码和中断选择
系统104主板的CPU为486DX，其对接口板访问有两种方式：内存映射和I/O访问。I/O寻址采用专门的指令，每次只能传送单个字节。内存映射方式可以访问较大的地址空间并且指令丰富，便于实现快速交换数据。本文讨论的CAN卡采用存映射模式工作，与486DX接口是104总线，它与ISA总线兼容。对于Intel X86体系的CPU，ISA可以映射的空间为0xC8000～0xEFFFF。使用比较器和地址选择开关组成可选端口地址译码电路，通过开关选通内存映射基地址（C8000H、C9000H、CA000H、…、EF000H），以避免与其它器件冲突。CAN偏移地址分配如下：
00～FFH SJA1000的寄存器；
100H～1FFH 对该范围内的任意地址进行写操作，均可导致CAN硬件复位。
SJA1000的INT引脚通过跳线选择IRQ3～7、IRQ9～12或IRQ15中的一个，避免与其它的适配卡冲突。
3 PC/104-CAN适配卡驱动实现
3.1 VxWorks驱动概述
VxWorks操作系统有两种方式实现驱动。第一种方式是，把设备驱动程序作为独立任务实现，直接在顶层任务中实现硬件操作，完成特有专用的驱动程序。第二种方式是，VxWorks的I/O系统将设备程序作为内核过程实现。这种方式便于实现I/O子系统的层次模型，便于文件系统一起把设备作为特殊文件处理，提供统一的管理、统一的界面和统一的.使用方法，并把设备、文件及网络通信组织成为一致的更高层次的抽象，为用户提供统一的系统服务和用户接口。我们和这种驱动方式。
作为I/O系统和硬件设备之间的连接层，VxWorks驱动就是屏蔽硬件操作，为I/O系统提供服务。实现一个完整的驱动，必须了解VxWorks下I/O的三个基本元素：File、Driver和Dervice。File是为用户提供访问设备的统一接口；Driver是实现具体的基本控制函数，也就是实现I/O系统所需要的接口；而Device则是一个抽象的硬件设备，是一系列的结构体、变量和宏定义对实际物理设备的定义。一般而言，实现一个驱动应该有三个基本的步骤：①用编程语言完成对实际物理设备的抽象；②完成系统所需要的各类接口及自身的特殊接口；③将驱动集成到操作系统中。之后还有一些调试工作。
3.2 VxWorks I/O系统驱动程序框架
VxWorks为各种设备（包括字符设备、块设备、虚拟设备及网络设备）提供统一的访问接口，包括七种基本的I/O函数：open(filename、flags、mode)，create（filename、flags）,read(fd、&buf、nBytes)，write(fd、&buf、nBytes)，ioctl(fd、command、arg)，close（fd）及remove（filename）。I/O系统所起的作用就是，把用户请求分配到与设备对应的驱动例程中去。VxWorks系统中有一个驱动程序列表，其形式如表1所列。
表1 设备驱动列表（调试时可利用iosDrvShow查看）
驱动号码createremoveopenclosereadwriteioctl1 2ca OpenNULLca Openca Closeca Readca Writeca IoctlI/O系统的可动态调用iosDrvInstall()函数将设备的驱动例程（即XXOpen()、XXClose()、XXRead()等）加入到设备驱动列表中，如图2所示。
同样，系统中有一个设备列表，每个设备对应于设备列表中的一项，每一项包括设备名称和设备驱动号，同时包括一个设备描述的结构。该结构第一个变量是DEV_HDR类型的变量DEV_HDR。
DEV_HDR的定义如下：
Typedef struct
{
DL_NODE node； /*设备列表节点*/
short drvNum; /*驱动号码*/
char *name; /*设备名*/
}DEV_HDR；
系统调用iosDevAdd()，可以将设备加入到设备列表中。系统中将驱动和设备联系起来的就是文件描述符列表，每个文件描述符列表除了包括驱动号、设备ID外，还包括文件名、可用标志和指向DEV_HDR的指针。系统每次成功执行open()，返回一个文件描述符，这样对于设备的read()、write()及ioctl就可以通过文件描述符进行。
文件描述符表（调试时调用iosFdShow()查看）如下：
I/O系统的整体结构如图3所示。系统启动时（一般挂接在usrroot()），XXDrv()和XXDevCreade()便将设备及其驱动加入相应的列表中。
3.3 设备驱动程序的访问过程
下面以CAN驱动程序为例，说明驱动程序的访问过程。（假定设备名“/can/1”并且以CAN设备驱动程序为例，上述中的XX在这里用Can代替。）
①fd=open(“/can/1”,O_RDWR,0644)
②I/O系统在设备列表中寻找设备名为/can/1的设备项，找到相应的设备驱动号。
③I/O系统在文件描述符中保留一个文件描述符空间。
④I/O系统在设备驱动列表中找到对应的CanOpen(CAN_DEV*PCAN_DEV,UBYTE*remainder,int flags)，该驱动例程返回设备描述符的指针。
⑤I/O系统将设备描述符的指针存储在文件描述符列表的Device ID，同时将对应的设备驱动号存储在文件描述符的Driver num项。最后I/O系统返回该描述符项的索引（即为fd）。
⑥这样应用程序中的read()和write（）等函数调用就可以根据fd找到相应的设备驱动号，进而找到相应的驱动例程。
4 CAN驱动程序的实现
CAN驱动程序的实现即是完成下面七个函数的编写。下面简要介绍其完成的功能，并用伪指令进行说明。
int drv_num; ;/*驱动号码*/
typedef struct {
DEV_HDR pCANHDR; /*这个数据结构必须放在设备描述符的最初部分*/
/*其余与驱动有关数据*/
}CAN_DEV； /*CAN设备描述符*/
CAN_DEV can_chan_dev；
STATUS CanDrv(void){
完成驱动的一些初始化；
intconnect(); /*连接所选的IRQ与中断处理函数*/
sysIntEnablePIC(); /*486DX允许中断*/
drv_num=iosDrvInstall(CanOpen,NULL，CanOpen，CanClose，CanRead,CanWrite，CanIoctl)；/*将设备驱动例程装入设备列表中*/
}
/*iosDrvInstall()将设备的CAN驱动例程加入设备驱动列表中，7个参数为7个驱动例程的进入点（entry point），如果没有某个例程，则传递NULL。*/
STATUS CanDevCreate（）{
完成一些设备初始化
iosDevAdd (&Can_chan_dev.pCANHDR,“can0”，drv_num)；/*将设备放入设备驱动列表中*/
}
int CanOpen(CAN_DEV *pCan_Dev,UBYTE *remainder,int flags){
CAN卡硬件复位
CAN卡关中断
CAN卡进入软件复位模式
设置CAN卡工作寄存器，如接收码寄存器和屏蔽码寄存器等
CAN卡开中断和进入操作模式
Return((int)pCan_Dev); /*注意必须返回设备描述结构指针*/
}
int CanRead(int CAN_DEV_ID,UBYTE * buf,int nBytes){
等待信号量（该信号量由中断处理例程释放）
从接收缓冲区读取数据
释放接收缓冲
返回接收数据数量
}
int CanWrite(int CAN_DEV_ID,UBYTE* buf,int nbyte){
查询发送缓冲是否可用
向发送缓冲区写数据
命令发送
查询发送完成标志
返回发送数据数量
}
void interrupt_handle_routin(int arg){
处理中断事件
发送（释放）信号量
}
限于篇幅，其它函数略。
图3 I/O系统整体结构
5 CAN驱动调试
硬件驱动的调试是件十分麻烦的事，经验十分重要。这里简要介绍几个帮助调试的函数。
①可以调用iosDrvShow()、iosDevShow（）及iosFdShow()查看相关内容，判断并将驱动及设备中入相应列表。
②使用logMsg()现实相关内容，以定位错误。
初期调试，示波器和信号灯是非常有用的，可以确定硬件的工作状况，从而有助于发现程序中的错误。
6 小结
笔者采用两种方式完成了CAN卡驱动。相对于第一种（笔者亦完成），第二种方式――VxWorks的I/O系统将设备程序作为内核过程实现，大大减少了系统的开销，实时性和可靠性有了很大的提高，并且为用户提供了统一的接口，使用十分方便。
开发驱动程序，辅助工具是非常有用的。Windows下的开发工具就比较多，而在VxWorks下开发驱动的工具相对较少。Windriver是一款不错的开发工具，可以开发VxWorks下的驱动程序（也可以开发其它操作系统下的驱动程序）。正确、熟练地使用这些辅助工具，会使开发工作事半功倍。
篇8：VxWorks下PC/104-CAN驱动程序设计
VxWorks下PC/104-CAN驱动程序设计
摘要：详细介绍实时多任务操作系统VxWorks环境下驱动程序的设计原理；针对驱动程序实现的困难，给出VxWorks下实现驱动程序的工作步骤。文件以PC/104-CAN适配卡为例，简要介绍硬件结构，重点给出驱动程序实现的关键代码。关键词：RTOS VxWorks PC/104 CAN I/O系统 驱动系统
VxWorks是一款优秀的实时多任务操作系统，具有抢占式调试、中断延迟小等特点。本文在简要介绍必备的硬件环境下，以VxWorks为平台，详细介绍驱动程序的开发。
1 PC/104-CAN适配卡的硬件结构
PC/104-CAN适配卡主要由CAN控制器（SJA1000）、光电隔离（6N137），收发驱动器（82C250）及译码电路组成。编程主要了解的是控制器SJA1000。CAN适配卡原理如图1所示。
2 CAN地址译码和中断选择
系统104主板的CPU为486DX，其对接口板访问有两种方式：内存映射和I/O访问。I/O寻址采用专门的指令，每次只能传送单个字节。内存映射方式可以访问较大的地址空间并且指令丰富，便于实现快速交换数据。本文讨论的CAN卡采用存映射模式工作，与486DX接口是104总线，它与ISA总线兼容。对于Intel X86体系的CPU，ISA可以映射的空间为0xC8000～0xEFFFF。使用比较器和地址选择开关组成可选端口地址译码电路，通过开关选通内存映射基地址（C8000H、C9000H、CA000H、…、EF000H），以避免与其它器件冲突。CAN偏移地址分配如下：
00～FFH SJA1000的寄存器；
100H～1FFH 对该范围内的任意地址进行写操作，均可导致CAN硬件复位。
SJA1000的INT引脚通过跳线选择IRQ3～7、IRQ9～12或IRQ15中的`一个，避免与其它的适配卡冲突。
3 PC/104-CAN适配卡驱动实现
3.1 VxWorks驱动概述
VxWorks操作系统有两种方式实现驱动。第一种方式是，把设备驱动程序作为独立任务实现，直接在顶层任务中实现硬件操作，完成特有专用的驱动程序。第二种方式是，VxWorks的I/O系统将设备程序作为内核过程实现。这种方式便于实现I/O子系统的层次模型，便于文件系统一起把设备作为特殊文件处理，提供统一的管理、统一的界面和统一的使用方法，并把设备、文件及网络通信组织成为一致的更高层次的抽象，为用户提供统一的系统服务和用户接口。我们和这种驱动方式。
作为I/O系统和硬件设备之间的连接层，VxWorks驱动就是屏蔽硬件操作，为I/O系统提供服务。实现一个完整的驱动，必须了解VxWorks下I/O的三个基本元素：File、Driver和Dervice。File是为用户提供访问设备的统一接口；Driver是实现具体的基本控制函数，也就是实现I/O系统所需要的接口；而Device则是一个抽象的硬件设备，是一系列的结构体、变量和宏定义对实际物理设备的定义。一般而言，实现一个驱动应该有三个基本的步骤：①用编程语言完成
[1] [2] [3] [4] [5]
篇9：嵌入式操作系统uCLinux
嵌入式操作系统uCLinux
作者Email:cuiwj181#sohu.com摘要:本文将分析嵌入式操作系统uClinux的内核结构、、内存管理、多进程处理、针对实时性的解决方案和开发环境，先对uCLinux有一个深刻的认识，将有利于今后进一步研究开发。
关键词:uCLinux，内存管理，多进程处理，RTLinux，开发环境
1引言
嵌入式操作系统是嵌入式系统的灵魂，而且在同一个硬件平台上可以嵌入不同的嵌入式操作系统。比如ARM7TDMI内核，可以嵌入Nucleus、VxWorks、uClinux等操作系统。在此主要对uClinux的进行介绍，嵌入式uClinux操作系统主要有三个基本部分组成：引导程序、uClinux内核（由内存管理、进程管理和中断处理等构成）和文件系统。uClinux可以通过定制使内核小型化，还可以加上GUI(图形用户界面)和定制应用程序，并将其放在ROM、RAM、FLASH或DiskOnChip中启动。由于嵌入式uClinux操作系统的内核定制高度灵活性，开发者可以很容易地对其进行按需配置，来满足实际应用需要。又由于uClinux是源代码公开，因此开发人员只有了解内核原理就可以自己开发部分软件，例如增加各类驱动程序。下面将详细分析嵌入式操作系统uClinux。
2嵌入式uCinux内核结构
uClinux内核结构如图1所示：
图1代表了内核的功能结构，与Linux基本相同，不同的只是对内存管理和进程管理进行改写，以满足无MMU处理器的要求。uClinux是Linux操作系统的一种，是由Linux2.0内核发展来的，是专为没有MMU的微处理器（如ARM7TDMI、Coldfire等）设计的嵌入式Linux操作系统。另外,由于大多数内核源代码都被重写，uClinux的内核要比原Linux2.0内核小的多,但保留了Linux操作系统的主要优点：稳定性，优异的网络能力以及优秀的文件系统支持。
3uClinux的内存管理
uClinux同标准Linux的最大区别就在于内存管理。标准Linux是针对有MMU的处理器设计的。在这种处理器上，虚拟地址被送到MMU，MMU把虚拟地址映射为物理地址。通过赋予每个任务不同的虚拟―物理地址转换映射，支持不同任务之间的保护。对于uCLinux来说，其设计针对没有MMU的处理器，不能使用处理器的虚拟内存管理技术。
uClinux不能使用处理器的虚拟内存管理技术（应该说这种不带有MMU的处理器在嵌入式设备中相当普遍）。
uClinux仍采用存储器的分页管理，系统在启动时把实际存储器进行分页。在加载应用程序时程序分页加载。但是由于没有MMU管理，所以实际上uClinux采用实存储器管理策略(realmemeorymanagement)。这一点影响了系统工作的很多方面。
uClinux系统对于内存的访问是直接的，（它对地址的访问不需要经过MMU，而是直接送到地址线上输出），所有程序中访问的地址都是实际的物理地址。操作系统对内存空间没有保护（这实际上是很多嵌入式系统的特点），各个进程实际上共享一个运行空间（没有独立的地址转换表）。
一个进程在执行前，系统必须为进程分配足够的连续地址空间，然后全部载入主存储器的连续空间中。与之相对应的是标准Linux系统在分配内存时没有必要保证实际物理存储空间是连续的，而只要保证虚存地址空间连续就可以了。此外磁盘交换空间也是无法使用的，系统执行时如果缺少内存将无法通过磁盘交换来得到改善。
uClinux对内存的管理减少同时就给开发人员提出了更高的要求。如果从易用性这一点来说，uClinux的内存管理是一种倒退，退回了到了UNIX早期或是Dos系统时代。开发人员不得不参与系统的内存管理。从编译内核开始，开发人员必须告诉系统这块开发板到底拥有多少的内存（假如你欺骗了系统，那将在后面运行程序时受到惩罚），从而系统将在启动的初始化阶段对内存进行分页，并且标记已使用的和未使用的内存。系统将在运行应用时使用这些分页内存。
由于应用程序加载时必须分配连续的地址空间，而针对不同硬件平台的可一次成块（连续地址）分配内存大小限制是不同（目前针对EZ328处理器的uClinux是128k，而针对Coldfire处理器的系统内存则无此限制），所以开发人员在开发应用程序时必须考虑内存的分配情况并关注应用程序需要运行空间的大小。另外由于采用实存储器管理策略，用户程序同内核以及其它用户程序在一个地址空间，程序开发时要保证不侵犯其它程序的地址空间，以使得程序不至于破坏系统的正常工作，或导致其它程序的运行异常。
从内存的访问角度来看，开发人员的权利增大了（开发人员在编程时可以访问任意的地址空间），但与此同时系统的安全性也大为下降。此外，系统对多进程的管理将有很大的变化，这一点将在uClinux的多进程管理中说明。
4uClinux的多进程处理
uClinux没有MMU管理存储器，在实现多个进程时（fork调用生成子进程）需要实现数据保护。由于uClinux的多进程管理是通过vfork来实现，因此fork等于vfork。这意味着uClinux系统fork调用完成后，要么子进程代替父进程执行（此时父进程已经sleep）直
到子进程调用exit退出；要么调用exec执行一个新的进程，这个时候将产生可执行文件的加载，即使这个进程只是父进程的拷贝，这个过程也不能避免。当子进程执行exit或exec后，子进程使用wakeup把父进程唤醒，使父进程继续往下执行。
uClinux的这种多进程实现机制同它的内存管理紧密相关。uClinux针对没有mmu处理器开发，所以被迫使用一种flat方式的内存管理模式，启动新的应用程序时系统必须为应用程序分配存储空间，并立即把应用程序加载到内存。缺少了MMU的内存重映射机制，uClinux必须在可执行文件加载阶段对可执行文件reloc处理，使得程序执行时能够直接使用物理内存。
5uCLinux针对实时性的解决方案
uClinux本身并没有关注实时问题，它并不是为了Linux的实时性而提出的。另外有一种Linux：RT－Linux关注实时问题。RT-Linux执行管理器把普通Linux的内核当成一个任务运行，同时还管理了实时进程。而非实时进程则交给普通Linux内核处理。这种方法已经应用于很多的操作系统用于增强操作系统的实时性，包括一些商用版UNIX系统，WindowsNT等等。这种方法优点之一是实现简单，且实时性能容易检验。优点之二是由于非实时进程运行于标准Linux系统，同其它Linux商用版本之间保持了很大的兼容性。优点之三是可以支持硬实时时钟的应用。uClinux可以使用RT-Linux的patch，从而增强uClinux的实时性，使得uClinux可以应用于工业控制、进程控制等一些实时要求较高的应用。
6uClinux的开发环境
1，GNU开发套件
GNU开发套件作为通用的Linux开放套件，包括一系列的开发调试工具。主要组件：
Gcc：编译器，可以做成交叉编译的形式，即在宿主机上开发编译目标上可运行的二进制文件。
Binutils：一些辅助工具，包括objdump（可以反编译二进制文件），as（汇编编译器），ld（连接器）等等。
Gdb：调试器，可使用多种交叉调试方式，gdb-bdm（背景调试工具），gdbserver（使用以太网络调试）。
2，Clinux的打印终端
通常情况下，uClinux的默认终端是串口，内核在启动时所有的信息都打印到串口终端（使用printk函数打印），同时也可以通过串口终端与系统交互。
uClinux在启动时启动了telnetd（远程登录服务），操作者可以远程登录上系统，从而控制系统的运行。至于是否允许远程登录可以通过烧写romfs文件系统时由用户决定是否启动远程登录服务。
3，交叉编译调试工具
支持一种新的处理器，必须具备一些编译，汇编工具，使用这些工具可以形成可运行于这种处理器的二进制文件。对于内核使用的编译工具同应用程序使用的有所不同。在解释不同点之前，需要对gcc连接做一些说明：
ld（linkdescription）文件：ld文件是指出连接时内存映象格式的文件。
crt0.S：应用程序编译连接时需要的启动文件，主要是初始化应用程序栈。
pic：positionindependencecode，与位置无关的二进制格式文件，在程序段中必须包括reloc段，从而使的代码加载时可以进行重新定位。
内核编译连接时，使用ucsimm.ld文件，形成可执行文件映象，所形成的代码段既可以使用间接寻址方式（即使用reloc段进行寻址），也可以使用绝对寻址方式。这样可以给编译器更多的优化空间。因为内核可能使用绝对寻址，所以内核加载到的内存地址空间必须与ld文件中给定的内存空间完全相同。
应用程序的连接与内核连接方式不同。应用程序由内核加载（可执行文件加载器将在后面讨论），由于应用程序的ld文件给出的内存空间与应用程序实际被加载的'内存位置可能不同，这样在应用程序加载的过程中需要一个重新地位的过程，即对reloc段进行修正，使得程序进行间接寻址时不至于出错。（这个问题在i386等高级处理器上方法有所不同）。
由上述讨论，至少需要两套编译连接工具：
1）二进制工具（Binutils）
GNUbinutils包包括了汇编工具、链接器和基本的目标文件处理工具。对binutils包的设置定义了所需的目标文件的格式和字节顺序。Binutils包种的工具都使用了二进制文件描述符（BFD）库来交换数据。通过设置文件config.bfd，可以指定默认的二进制文件格式（例如elflittleendian）和任何工具可用的格式，见例1。
例1在config.bfd中添加的用来指定目标二进制格式的代码
arm-*-uClinux*|armel-*-uClinux*
tag_defvec=bfd_elf32_littlearm_vec
targ_selvecs=”bfd_elf32_bigarm_vecarmcoff_little_vecarmcoff_big_vec”
2）C编译器
GNU编译器集GCC是通过使用一种叫做“寄存器转换语言”（RTL）的方式实现的。假定现在有一种基本的机器描述性文件，它已经能满足大家的需要。现在要做的仅仅是设置默认情况下使用的参数和如何将文件组合成可执行文件的方式。GNU的文档提供了所有必需的资料，使得用户可以为新型的处理器的指令集合提供支持。如果要针对体系的机器建立一个新的目标机器，那么就必须指定默认编译参数和定制系统的特定参数，见例2。对于特定的目标系统，可以使用TA
RGET_DEFAULT宏来在target.h文件中定义编译器的开关。目标t-makefile段指定了应该构建哪一个额外的例程和其编译的方式。
例2使用uClinux-arm.h来指定默认的编译参数
＃undefTARGET_DEFAULT
#defineTARGET_DEFAULT(ARM_FLAG_APCS_32|ARM_FLAG_NO_GOT)
4可执行文件格式
先对一些名词作一些说明：
coff（commonobjectfileformat）：一种通用的对象文件格式
elf（excutivelinkedfile）：一种为Linux系统所采用的通用文件格式，支持动态连接
flat：elf格式有很大的文件头，flat文件对文件头和一些段信息做了简化
uClinux系统使用flat可执行文件格式，gcc的编译器不能直接形成这种文件格式，但是可以形成coff或elf格式的可执行文件，这两种文件需要coff2flt或elf2flt工具进行格式转化，形成flat文件。当用户执行一个应用时，内核的执行文件加载器将对flat文件进行进一步处理，主要是对reloc段进行修正。以下对reloc段进一步讨论。
需要reloc段的根本原因是，程序在连接时连接器所假定的程序运行空间与实际程序加载到的内存空间不同。假如有这样一条指令：
jsrapp_start;
这一条指令采用直接寻址，跳转到app_start地址处执行，连接程序将在编译完成是计算出app_start的实际地址（设若实际地址为0x10000），这个实际地址是根据ld文件计算出来（因为连接器假定该程序将被加载到由ld文件指明的内存空间）。但实际上由于内存分配的关系，操作系统在加载时无法保证程序将按ld文件加载。这时如果程序仍然跳转到绝对地址0x10000处执行，通常情况这是不正确的。一个解决办法是增加一个存储空间，用于存储app_start的实际地址，设若使用变量addr表示这个存储空间。则以上这句程序将改为：
movladdr,a0;
jsr(a0);
增加的变量addr将在数据段中占用一个4字节的空间，连接器将app_start的绝对地址存储到该变量。在可执行文件加载时，可执行文件加载器根据程序将要加载的内存空间计算出app_start在内存中的实际位置，写入addr变量。系统在实际处理时不需要知道这个变量的确切存储位置（也不可能知道），系统只要对整个reloc段进行处理就可以了（reloc段有标识，系统可以读出来）。处理很简单，只需要对reloc段中存储的值统一加上一个偏置（如果加载的空间比预想的要靠前，实际上是减去一个偏移量）。偏置由实际的物理地址起始值同ld文件指定的地址起始值相减计算出。这种reloc的方式部分是由uClinux的内存分配问题引起的。
7总结
以上主要阐述了嵌入式操作系统uClinux的内核结构、、内存管理、多进程处理、针对实时性的解决方案和开发环境，先对uCLinux有一个深刻的认识，将有利于今后进一步研究开发。
【Vxworks嵌入式操作系统下网络设备驱动程序设计】相关文章：
3.linux下迁移mysql数据库存放目录linux操作系统
5.linux下使用rsync实现文件目录同步linux操作系统
文档为doc格式