嵌入式IP（精选8篇）
嵌入式IP 篇1
随着嵌入式技术的迅速发展, 嵌入式设备也在工业控制领域得到广泛的应用。但嵌入式系统接入因特网的需求促使嵌入式设备必须实现Internet网络化并能够实现配置信息的远程管理。在精简的嵌入式TCP/IP协议栈基础上, 重点了分析了ARP和TCP协议, 并给出通过上位机软件系统对嵌入式设备的IP地址修改流程和开发过程。
1 嵌入式 TCP/IP 协议
TCP/IP包含应用层、传输层 、网络层等一系列协议 , 且每层可采用的协议有多种。由于嵌入式设备的硬件资源有限, 其可直接寻址的程序空间和数据空间都很小, 处理速度较慢, 所以嵌入 式设备一 般采用最 精简的TCP/IP协议栈 (包括ARP、IP、UDP、ICMP等协议)[1], 在设计和开发过程中主要使用了ARP和TCP协议。
(1) ARP协议 (地址解析协议 : Address Resolution Proto- col) 是获取MAC物理地址的TCP/IP协议, 其主要作用是通过已知IP地址, 获取对应MAC物理地址的协议。当ARP请求被广播到网络上后, 目的主机收到请求包后发出一个ARP回应包, 给出自己的MAC地址和IP地址[2]。
(2) TCP协议 (传输控制协议 : Transmission Control Pro- tocol) 是一种面向连接的、可靠的、基于字节流的传输层通信协议, 通过3次握手建立连接, 通信完成时要删除连接, 采用“带重传的肯定确认”技术来实现传输的可靠性。
2 系统设置流程
上位机远程修改嵌入式设备的IP地址的流程包括:
(1) 上位机发出查询下位机MAC地址的ARP广播请求包, 嵌入式设备接收后响应ARP请求, 返回本地MAC地址; (2) 上位机记录响应ARP请求的嵌入式设备IP地址和MAC, 为建立TCP连接做准备; (3) 选择需要进行修改的嵌入式设备IP并发送TCP连接请求, 嵌入式设备建立与上位机的TCP连接;(4) 上位机发送IP?参数数据包, 嵌入式设备截取数据包中的信息来完成本地IP设置[3]。
3 上位机软件系统实现
在VC++开发平台上对上位机软件系统进行了实现, 使用基于TCP的Socket与嵌入式设备进行连接, 通过gethostby- name函数返回给定嵌入式设备IP地址对应于的包含主机名字和地址信息的hostent结构指针。使用IP地址和默认端口号与下位机进行连接, 如果连接成功则将封装好的数据包到下位机并给出提示[4]。关键代码如下:
4 结语
给出一种对嵌入式设备的IP地址等网络参数进行设置和管理的解决方案, 利用ARP协议查询潜入式设备的IP地址和MAC地址, 并在与嵌入式设备建立TCP连接的基础上发送IP参数数据包来完成嵌入式设备的参数动态设置和管理, 为嵌入式系统的Internet接入提供了一定的参考价值。
嵌入式IP 篇2
10B嵌入式网络设备的基本框图如图1所示。
其中，Flash是一片HY29LV160，共16Mb，分35个扇区。程序映像文件是从低扇区开始存放的。
本嵌入式网络设备系统的MAC及IP地址设置的基本思想是：把MAC及IP地址存放在Flash的未用扇区（一般在高扇区），嵌入式操作系统启动后，自动运行一个程序去读取MAC及IP地址并设置它。
用户如何把MAC及IP地址放到Flash中？笔者使用的方法是通过计算机串口与网络设备的RS232接口（即串口）相连，使用超级终端的方式，运行网络设备中的程序把数据写入Flash中。
针对MAC及IP地址的设置，笔者编了以下两个运行于嵌入式操作系统uClinux上的程序。
（1）MyIP：处理IP地址的设置
程序使用说明：
myip-r ;读取Flash中的IP地址并检验合法性和启用它
myip-w 172.20.91.15 ；更改Flash中的IP地址为172.20.91.15, ;掩码为255.255.255.0,并启用它
myip-w 172.20.91.15-m 255.255.192.0 ；更改Flash中的IP地址为172.20.91.15，掩码为255.255.192.0，并启用它
（2）MyMAC,处理MAC地址的设置
程序使用说明：
mymac-r ；读取Flash中的MAC地址并检验合法性和启用它
mymac-w aa:bb:dd:ee:ff，更改Flash中的MAC地址为aa:bb:cc:dd:ee:ff，并启用它
运行在S3C4510B上的应用程序，可以用串口终端输入指令的方式运行。作为嵌入式应用，要求系统复位就能自动行动指定的程序。这时，我们得到另一种运行程序的方式：在uClinux开发包的4510B文件中配置（相当于DOS中的自动批处理程序）。如加入
/bin/./mymac-r
/bin/./myip-r
编译后的映像文件就可使系统自动运行mymac-r和myip-r，完成系统启动时自动从Flash中读取MAC地址和IP地址并配置它们。
对于嵌入式网络设备生产厂家，可以使用以上两个程序的带“-W”参数的用法完成MAC和IP地址的设置；而嵌入式网络设备的用户只用知道处理IP地址的程序，一般不允许随着更改MAC地址。
图2、图3是两个程序的流程。
在这里强调两点：
①这两个程序都用到了Linux的网络配置指令ifconfig(具体用法请查阅Linux下的相关帮助文档)。在用该指令更改MAC地址时，需要硬件的支持。如一般的通用计算机上，网卡的MAC地址不能更改，该指令执行时将报异常；而在S3C4510B这样的嵌入式网络设备上，就能成功更改设备运行时的MAC地址。
②Flash的基地址在操作系统启动前后一般是不同的，这主要是为了提高系统运行的速度。另外，对Flash进行写操作之前应先擦除操作扇区，注意数据的保护；不要擦除整个Flash，否则连同映像文件一起被清掉后，系统也就不能正常运行了。在对Flash的操作时应特别注意这些。源网站：收集整理。
结语
嵌入式IP 篇3
嵌入式网络通信在各个方面都得到了非常广泛的运用。目前最常见的就是总线和USB数据传输方式, 传输速度即使可以达到较快的水平, 但是其并不能够满足长距离的数据传输。因此, 以太网能够弥补其在数据传输方面的缺陷。以太网能够实现一百米距离点对点的数据传输, 如果要实现更加远距离的数据传输, 则需要使用路由器或者交换机来完成。此文基于对CP2200嵌入式TCP/IP协议进行探究, 并实现以太网嵌入式系统设计。
二、嵌入式TCP/IP协议的探究与实现
TCP/IP协议栈从上到下分别是由应用层、运输层、网络层和网络接口层所组成的四层结构, 每一层各司其职, 都有着不同的网络协议。依据软件实际使用的情况, 在嵌入式系统当中为了达到网络通信的目的, 需要对TCP/IP协议族进行裁剪。在对软件进行初始化的时候, 也对单片机同时进行了初始化, 其中包括对系统时钟、定时器、端口和串口进行了初始化。当然还有CP2200进行初始化, 其中包括对MAC层和物理层进行初始化, 并且中断使能。
在TCP/IP协议栈当中, 运用层包含HTTP协议, 运输层包含TCP协议和UDP协议, 网络层包含ARP协议、IP协议和ICMP协议。以下是嵌入式TCP/IP协议的每个模块的实现流程:
1、HTTP协议模块。
HTTP协议的发送函数http_send () 即是TCP协议的发送函数和数据信息的结合, 但是http_send () 函数主要是实现设计网页内容, JPEG的图片和HTML (超文本标记语言) 等信息的使用依靠其函数实现。
2、TCP协议模块。
TCP协议的发送函数tcp_send () 是需要发送一个不包含任何数据的TCP报文, 其作用是能够对字节头和校验和进行处理。通过对时间功能的设定, TCP协议的重传函数tcp_retransmit () 能够实现对数据最多为两次重传的传输功能, 实现传输功能的应用程序是依靠传送页数据而实现的, 即是HTTP服务程序。TCP协议的保活函数tcp_inacivity () 是没半秒运行一次, 当连接正在建立的状态下, 保活期满了的时候并且没能被再次使用, 就会中断连接。TCP协议的接收函数tcp_rcve () 实现对字节头和校验和的运算, 进而对HTTP服务程序和其连接状态等情况进行断定, 最后进行TCP有限的状态机判断数据包的程序。
3、UDP协议模块。
UDP协议的发送函数udp_send () 能够实现对字节头和校验和进行处理, 其接收函数udp_rcve () 是对所接收的UDP报文进行处理, 如果没有受到UDP报文数据, 就需要发送ICMP终点不可到达报文。
4、ARP协议模块。
ARP协议的发送函数arp_send () , 在发送请求报文的时候, 对于不清楚目的物理地址的, 则是广播报文;在发送应答报文的时候, 接收的一方的目的物理地址需要添加物理地址。ARP协议的重传函数arp_retransmit () 能够实现当其发出ARP请求之后的半秒时间内没有任何响应, 则进行再一次发送的功能, 但是当两次发送没有得到响应就会对报文进行删除。ARP协议的缓存更新函数age_arp_cache () 能够每一分钟更新一次。ARP的解析函数arp_resolve () 能够对所发送的IP报文目的IP地址进行解析, 如果发送IP地址和目的IP地址都不在相同的一个网络当中, 那么此IP地址是网关IP地址, 然后在缓存表当中对其进行查找, 如果找不到就需要发送ARP请求报文。ARP协议的接收函数arp_rcve () 能够实现对报文进行接收或者应答, 对缓存表需要进行更新和重新定时, 如果所接受的报文是应答报文, 则需要发送等候地址解析的IP报文, 但是所接收到的报文是请求报文, 则需要发送ARP应答报文。
5、IP协议模块。
IP协议的发送函数ip_send9 () 能够实现对发送IP报文的20字节头和校验和进行处理, 进而使用网络接口层进行发送。IP协议接收函数ip_rcve () 能够根据版本情况和所接收报文的种类转移到相应的接收函数来处理。
6、ICMP协议模块。
ICMP协议模块的接收函数icmp_rcve () 是实现对ping请求的接收进行处理, 并且处理ICMP不同种类的报文。其中Ping命令请求信息函数ping_send () 是用来检测发送接收两方的接收情况。
三、结言
综上所述, 此文对TCP/IP的网络结构中的各层协议模块进行探究, 基于网络控制芯片CP2200的以太网接口和单片机C8051F340, 并用编程语言来实现嵌入式以太网通信, 同时进一步通过对各个层协议的裁剪, 实现嵌入式以太网的数据通信。根据现阶段来看, 嵌入式网络通信基本上都是依靠TCP/IP协议来实现的, 嵌入式设备和网络两者相结合是嵌入式系统今后发展的主要方向。因此, 我们要更加深入地对嵌入式TCP/IP协议进行探究以及更深层次的功能实现。
参考文献
[1]王树森, 王希杰, 刘秋菊.嵌入式Web远程粮情监控系统的研究与实现[J].自动化仪表, 2013 (10) :243-247.
嵌入式IP 篇4
随着社会的发展,人们对软硬件的要求越来越高,对很多应用系统的实时性,并发性,精确性方面都提出了新的要求,多线程技术的广泛应用使其中部分矛盾得以解决[1]。特别是在以PC为主的监控系统中,引进多线程技术解决多任务实时问题是主要的解决思路。在嵌入式系统中,多线程技术也被广泛的使用。
嵌入式系统由于受处理器速度及存储空间等资源的限制,要实现多通道实时解码的解码系统,必须在解码库的效率、解码系统任务调度及缓冲区的分配与管理上精心设计。解码库的实时性即处理器开销有比较简单明确的评价方法,但是基于DSP/BIOS实时操作系统的多任务调度机制和实时通信多重缓冲区的配置方法同样影响系统的整体表现。
本文将介绍一种基于H.264编解码的嵌入式IP网络视频监控系统,并对解码系统进行优化。通过引入信号量协调解码系统的任务调度,通过对解码系统中多处缓冲区的分配与管理做出调整,最终达到了解码系统多通道实时显示的要求。最后,对比优化前与优化后的实验数据,对实验数据进行总结。
2 系统的整体设计
基于H.264编解码的嵌入式IP网络视频监控系统包括两部分:网络视频服务器,客户端。系统的整体框架如下图1示。
网络视频服务器是视频数据网络传输的第二代产品,是由一个或多个模拟视频输入口、数字信号处理器、压缩芯片和一个具有网络连接功能的服务器所构成的嵌入式系统,它的功能与可升级扩展能力以及系统二次开发兼容能力大大超过了上一代网络视频产品──网络摄像机。[2]
客户端运行在嵌入式平台上,其主要功能是通过网络与嵌入式视频服务器连接,接收、播放视频服务器传送过来的实时音视频数据;获取视频服务器的状态和配置参数,并可对这些参数进行配置;接收视频服务器的运动检测的告警信息。
2.1 网络视频服务器
网络服务器包括音视频数据采集、音视频数据编码、音视频数据发送及网络控制指令的交互四大模块。
音视频数据采集:采集原始的语音,视频数据。
音视频数据编码:音频采用多种格式压缩编码,比如有:g.7xx系列。视频数据采用标准的H.264编码。
音视频数据的发送:将压缩的音视频数据进行RTP打包发送出去。
网络指令交互:完成编码系统与解码系统之间的联络。
网络服务器的主要功能是把采集到的原始的音视频数据经过指定的编码方式编码后再通过网络发送给客户端。服务器与客户端采用TCP传输协议发送控制命令,保证服务端和客户端之间的准确通讯——包括链接请求,读取音视频配置等;采用U D P传输协议发送编码后的音视频数据,能提高网络的利用率、提升实时性。
2.2 客户端
客户端包括控制模块、收包模块和解码模块三大模块。
控制模块:向服务端发送TCP链接请求,发送配置信息给服务端并接收服务端返回的配置信息,在上述请求完成的基础上再发送请求音视频数据的指令。
收包模块:接收网络中由服务端发送过来的编码后的音视频数据。
解码模块:将从网络中收到的编码后的音视频数据调用对应的解码器进行解码,并显示。
系统流程图2如下所示:
2.2.1收包模块与解码模块的同步
解码系统优化前,我们调用CCS(系统硬件使用的编译环境)自带的图表工具“cpu graph”,得到当前的CPU占用率图,如图3所示,4路CIF(1CIF图像大小为352×288)实时预览时轻微运动图像中就会出现大量的马赛克,剧烈运动画面通常会停顿,无法达到实时显示的效果。
经过分析,我们从以下两个方面查找问题出现的原因:解码库的效率,解码系统的任务调度。
在本系统使用的解码库经过多种场景下的码流文件反复测试,得出解码库效率在D1(D1图像大小在PAL制下为720×576)情况下,CPU占用率低于75%,因而可以认定解码库的效率是足够的。
在嵌入式设备上,多种媒体业务并发时,各个线程之间将竞争有限的C P U资源。当线程得不到它所需要的CPU资源时,数据的处理将会被延误,从而加剧数据流的抖动。对于实时性要求高的业务,过长的延时和不连贯的音视频质量是无法容忍的。因此,如何合理地调度各个线程以高效率地利用C P U资源成为系统任务调度策略的研究重点[3]。
3 多线程的调度方式
3.1 线程的基本状态
一个线程创建之后,总是处于其生命周期的4个状态之一中。线程的状态表明此线程当前正在进行的活动。
1运行状态(running):线程进入运行状态后便会一直运行下去,知道被抢占、时间片用完、线程终止或进入阻塞状态。
2就绪状态(ready):线程已获得除处理机外的所需资源,正等待调度执行。
3阻塞状态(block):当线程需要等待一个事件时,它将阻塞(保存用户寄存器、程序计数器和栈指针),此时处理器转而执行另一个就绪线程。当阻塞一个线程的事件发生时,则阻塞的条件被解除,该线程移到就绪队列中。
4终止状态(terminate):当一个线程完成时,其寄存器上下文和栈都被释放。
3.2 信号量的引入
在引入信号量前,收包线程与解码线程是并行的、无序的,DSP有限的资源耗费在无序的任务调度中,解码线程因为没有足够的数据无法正常解码,而收包线程由于没有足够的运行时间无法从网络中获取数据量足够的数据包,这样整个系统的实时解码都被限制了。系统无法实现预期的多通道实时显示。
因此,我们引入了信号量来解决客户端系统中的收包模块与解码模块同步的问题。下面本文将以收包线程与解码线程进行一次数据交换为例来说明他们的工作流程(如图4所示)。
程序开始后,在解码线程中等待信号量,此时解码线程被挂起,收包线程运行;当收包线程收到足够数量的数据(例如一个完整的NAL)后发送信号量,解码线程被唤醒进入执行状态,收包线程挂起。
从以上描述可知,系统从以前的无目的、不间断的查询模式改变为现在的有明确目的的基于DSP/BIOS的线程阻塞与唤醒机制。
4 缓冲区的分配与管理
在实时系统中,延迟与丢包是无法避免的。因而在延迟和丢包的控制上,需要设计平衡的策略,使系统能够(兼顾)适应绝大部分的场合。本系统中,涉及到多处缓冲区的使用。因此在设计过程中,可以根据系统的性能要求,灵活配置,在延迟和丢包两个指标中,折中选择。
4.1 缓冲区的组成
缓冲区包括:网络收包的setRCVBuf和保存收包数据的JitBuf。
setRCVBuf是接收的socket缓冲区大小。在实际的过程中如果接收数据量比较大时,我们可以通过设置socket缓冲区的大小来避免不断的循环收包,这样能有效节约C P U资源。
JitBuf是一个结构体,在该结构体中用二维数组来保存从网络中收到的码流,该数组的行参数表示用于接收码流数组的多少,列参数固定为1472。接收码流数组个数越多,单位时间内保存的数据包的数量就越多,丢包的可能性就越小,但是延时也会相应的增加。
4.2 缓冲区的设置
程序中各个Buf大小设置的依据是从网络获取的实时数据分析得到的。以固定400Kbit/s码率,4路CIF图像为例,简称CBR-400K,4CIF。我们通过Ethereal截获数据包,调用其中的工具对截获的数据包进行分析。数据包长度为32.216秒。
平均每秒总包数为337个,即每2-3ms就要收包一次。从程序整体规划而言,在40ms(实时监控的两幅画面的最大间隔)内,收包的次数越多即在收包线程上耗费的时间越多,对应的解码线程上运行的时间就要越少,为了满足系统总体需求,收包与解码必须达到一定范围内的平衡,选择一个足够大的fdselect(ndk提供的用于监控网络协议栈中是否有数据的一个接口函数)时间是有必要的。
JitBuf中接受码流的数组个数直接影响到延时的大小与丢包率,如果该数组足够大,理论上讲丢包是可以避免的。考虑两方面的影响,我们结合实际的网络状况和编码数据的码率对该数组的大小作了估算,并对估算的结果作了一系列测试,从测试的实际情况最终确定该数组的大小。
解码各Buffer之间的关系,及空间分配:
5 实验结果及结论
5.1 实验结果
以CBR-400K,关键帧间隔20,4CIF做比较(测试网络环境相同,4路通道显示的是同一个摄像头的图像,CBR-400K,4CIF的解释参见3.2):
调用工具观看优化后的解码系统的C P U占用率,如图5所示。
优化前:轻微运动就会大量丢包,随机出现1-2路图像模糊不清(如图6所示的第一路与第二路)。剧烈运动时,四路图像不连贯,有时候四路图像均会停止,再次恢复正常预览需要的时间超过10秒,无法满足实时监测的需求。
优化后:轻微运动无丢包,图像细腻流畅画面清晰。剧烈运动偶尔丢包,图像细腻流畅,延时小于2秒。系统满足了4路实时监控的需求。见图7。
5.2 结束语
本文针对I P网视频解码系统中实时多任务调度问题,提出了一种基于DSP/BIOS实时操作系统的解决方案,采用信号量同步机制,约束多个通道解码线程和收包线程的状态迁移,同时通过对解码系统各级缓冲区的精确分配,达到了实时多通道视频解码系统的设计目标。本文提出的多任务调度与缓冲区管理策略,对其它实时性要求较高的嵌入式通信系统都具有一定的借鉴作用。
参考文献
[1]熊邦毛,熊叶明,张再萍.用多线程技术解决单线程冲突问题[J].计算机与数字工程,2007,35(1):115-118.
[2]倪为.小型智能视频监控系统的设计与实现[D].武汉大学,2008.
嵌入式IP 篇5
以太网具有通用性强、技术成熟、带宽迅速增加等特性, 工业控制领域出现嵌入式技术, 尤其是ARM技术的发展和DSP在工业控制领域的广泛应用, 利用嵌入式技术实现以太网通信已经不难见到。嵌入式实时操作系统接入网络后将使远程监测、远程控制、远程诊断和远程维护变得越来越容易。从根本上讲, 嵌入式设备接入网络, 当前基本采用基于TCP/IP的通信协议。该方案以LPC2210为核心元件研究基于ARM的嵌入式TCP/IP协议的实现的硬件电路, 同时在μC/OS-Ⅱ平台上编写应用软件程序。下面对系统做详实的阐述, 并重点介绍嵌入式实时操作系统μC/OS-Ⅱ[1]应用于TCP/IP时应进行合理的裁减。
1系统硬件设计
基于ARM的嵌入式TCP/IP网络通信系统主要包括ARM芯片和以太网控制器等芯片组成的以太网接口、驱动软件和嵌入式TCP/IP协议栈。硬件原理图如图1所示。
该方案设计相对简单, 硬件电路中采用的LPC2210[2]是Philips公司推出的微处理器, 带有16 KB RAM, 76个通用I/O口, 12个独立外部中断引脚, 集成有8通道的10位A/D, 能够基于芯片设计复杂的系统。虽然LPC2210具有较快的访问速度, 但片内没有集成FLASH, 所以这里扩展1片16 Mb FLASH SST 39VF160来保存用户程序。其架构满足μC/OS-Ⅱ正常运行的基本要求。
RTL8019AS是台湾Realtek半导体公司生产的以太网控制器, 其性能包括:支持EthernetⅡ和IEEE802.3标准;支持8/16位数据总线;内置16 KWord的SRAM;全双工, 收发同时达到10 Mb/s;支持BNC, AUI, UTP介质。RTL8019AS可提供100脚的TQFP封装, 减少了PCB面积, 更适合于嵌入式系统。HR901170A是汉仁电子有限公司生产的RJ45接口连接器 (带网络变压器/滤波器) , 该连接器满足IEEE802.3和IEEE902.3ab标准, 能够较好地抑制电磁干扰。通过HR901170A系统就可以连接到以太网上。
2嵌入式协议的选择
TCP/IP协议[3]是一组不同层次上的多个协议的组合, 通常被认为是一个包含链路层、网络层、传输层和应用层的4层协议系统, 如图2所示。嵌入式系统是为完成某种特定的功能而设计的专用系统。嵌入式系统不要求 (也不可能) 实现所有的TCP/IP协议, 所以嵌入式TCP/IP是对TCP/IP协议族进行选择而形成的协议集合。
首先在链路层上, 由于采用以太网的接入方式, 系统必须实现IEEE802.3所规定的CDMA/CD (载波监听多路访问及冲突监测) 协议, CDMA/CD协议不需用户实现, 此协议只要采用通用的NIC (Network Interface Controller, 网络接口控制) 芯片就可支持。为了保证系统在以太网中的通信, 系统还需实现ARP应答协议, 该协议用于将IP地址映射成以太网MAC地址。ARP协议包括ARP请求和ARP响应两部分, 系统与其他计算机通信, 就必须要支持ARP响应。ARP请求在本地建立了一个IP地址到MAC地址的映射, 保证了对外通信的有的放矢。RARP (逆地址解析) 协议主要用于解决如何从MAC地址得到IP地址, 主要用于无盘工作站中。在网络层, 由于系统要求能够在Internet中进行通信, 因此系统要实现IP协议。在TCP/IP协议族中, 网络层协议包括IP协议 (网际协议) 、ICMP协议 (Internet控制报文协议) 以及IGMP协议 (Internet组管理协议) 等。IP协议是TCP/IP族的核心协议, 它使异构网络之间的通信成为可能。因此RTU等系统数据跨越不同的网络进行传输就必须要实现IP协议。ICMP中规定了多种协议类型和代码, 如果完全地实现也要耗费不少的系统资源, 该嵌入式系统中, 在ICMP协议中能够测试网络的连通情况即可。传输层主要是在2台主机之间提供端到端的通信。传输层有2种不相同的传输协议:TCP (传输控制协议) 和UDP (用户数据报协议) 。TCP是面向连接的, 在不可靠的网络服务上提供端到端的可靠字节流。TCP协议设计了严格的3次建立连接握手过程、4次关闭连接握手过程以及捎带确认信息并通过滑动窗口进行流量控制的数据传输过程。UDP协议是不面向连接的, 它只是简单地把数据报从一台主机发送到另一台主机, 但并不保证该数据报能到达另一端, 可靠性必须由应用层来提供。考虑到系统中数据传输质量, 这里采用TCP协议。应用层协议主要是指用户进程。其包括:HTTP协议、FTP协议、POP3协议、SMTP协议、SNMP协议。
3系统软件设计
该TCP/IP网络通信系统为了具有较好的实时性和稳定性, 采用μC/OS-Ⅱ设计系统软件。在μC/OS-Ⅱ平台上, 软件设计工作主要包括:μC/OS-Ⅱ在LPC2210上的移植和TCP/IP协议在μC/OS-Ⅱ上的实现以及系统应用程序的编写。
μC/OS-Ⅱ的移植[4]工作主要集中在下面几个文件中:OS_CPU.H, OS_CPU_A.ASM, OS_CPU_C.C。另外, 在INCLUDES.H中必须包括LPC2210文件LPC2210.H;OS_CFG.H用于系统应用μC/OS-Ⅱ中的初始化配置。OS_CPU.H主要包括一些与处理器和编译器相关的常量和类型定义等, 而且需注意LPC2210的堆栈方向是由高到低, 用OS_STK_GROWTH来设置堆栈的增长方向。因此将OS_STK_GROWTH设为1。OS_CPU_A.ASM中需编写4个汇编语言函数:OS_TASK_SW () , OS_IntCtxSw () , OSStartHighRdy () 和OSTickISR () 。
以太网链路层遵循的IEEE802.3协议的CSMA/CD和CRC校验等功能由网络控制芯片Rtl8019AS完成, LPC2210芯片则完成其他TCP/IP协议的解释和执行。LPC2210控制RTL8019AS完成通信任务时, 首先要对RTL8019AS复位, 并对RTL8019AS的寄存器进行初始化, 确定发送和接收的条件, 然后才能发送数据或接收数据。当一帧数据发送结束、接收到1帧数据或出错等事件发生时, RTL8019AS向LPC2210申请中断, LPC2210响应中断后根据中断状态寄存器的内容进行相应的处理。
在LPC2210内部, ARM程序完成对数据的打包解包。系统复位后, 系统首先发送ARP请求, 建立地址映射, 并内部中断进行定时更新。ARM芯片根据情况将采集或收集到数据按照TCP协议或UDP协议格式打包, 送入网卡芯片, 由网卡芯片将数据输出到局域网中。ARM芯片对数据报进行分析, 如果是ARP (物理地址解析) 数据包, 则程序转入ARP处理程序。如果是IP数据包则进一步判断是哪个协议向IP传送数据。如果是ICMP协议, 判断是否为Ping请求, 是则应答, 不是丢弃该数据包;如果是TCP或UDP协议, 且端口正确则按相应的协议处理数据, 端口不正确丢弃数据包。TCP/IP系统框图如图3所示。
TCP/IP在μC/OS-Ⅱ上的设计结束后, 剩下的工作就是编写应用程序。将系统划分成若干个任务, 每个任务对应一个独立的无限循环的主程序, 完成一个特定的功能。为简化设计, 应用程序采用静态优先级, 即应用程序在执行的过程中各个任务优先级保持不变。
4结语
基于ARM的嵌入式TCP/IP协议的设计方案, 论述了软、硬件的设计方法和协议的选择。该设计方案在硬件实现上简洁可靠;软件实现上可维护性好;可扩展性好, 有利于系统的后续开发, 降低了系统设计的复杂性。实验证明该方案可行性强, 可以直接把系统的处理数据送到以太网上传输。可以看出, ARM和嵌入式TCP/IP协议将会得到更大的发展和更广阔的应用。
参考文献
[1]Jean J Labrosse.嵌入式实时操作系统μC/OS-Ⅱ[M].2版.北京:北京航空航天大学出版社, 2003.
[2]周立功.ARM嵌入式系统基础教程[M].北京:北京航空航天大学出版社, 2005.
[3]周立功.ARM嵌入式系统软件开发实例 (一) [M].北京:北京航空航天大学出版社, 2004.
[4]任哲.嵌入式实时操作系统μC/OS-Ⅱ原理及应用[M].北京:北京航空航天大学出版社, 2005.
[5]杜春雷.ARM体系结构与编程[M].北京:清华大学出版社, 2003.
[6]季昱, 林俊超, 宋飞.ARM嵌入式应用系统开发典型实例[M].北京:中国电力出版社, 2005.
[7]马忠梅, 马广云.ARM嵌入式处理器结构与应用基础[M].北京:北京航空航天大学出版社, 2002.
[8]王田苗.嵌入式系统设计与实例开发──基于ARM微处理器与μC/OS-Ⅱ实时操作系统[M].北京:清华大学出版社, 2002.
[9]田泽.嵌入式系统开发与应用教程[M].北京:北京航空航天大学出版社, 2005.
[10]肖军, 邵景峰, 马辉, 等.嵌入式实时操作系统与网络构件的设计[J].可编程控制器与工厂自动化, 2006 (10) :70-72, 48.
嵌入式IP 篇6
嵌入式系统已成为计算机应用领域的一个重要组成部分，多种多样的以嵌入式系统为核心的数字化产品已开始成为信息处理的主流。随着后PC时代的到来，嵌入式系统将以PC机不可比拟的软、硬件可裁剪，结构灵活性，稳定性和经济性成为计算机领域的新的爆发点。随着嵌入式系统应用越来越广泛，人们自然想到了如何将Internet技术和嵌入式技术结合起来，使基于开放的、标准的、独立于系统平台的TCP/IP通信协议的Web技术在嵌入式系统中得到更广泛的应用和普及。
将精简后的TCP/IP协议引入到嵌入式系统中，尤其是低端的8位或16位处理器，实现的嵌入式Web服务器，利用已有的Internet网络通过B/S模式实现远程监测、远程控制和数据采集等功能。该结构费用低，操作、维护方便，适用范围广，将广泛地应用于工业自动化、信息家电、智能仪器仪表、虚拟现实中的应用、环境工程与自然、家庭医疗保健、安全保障服务业等领域，成为后PC时代研究的热点。本文主要介绍了嵌入式Web服务器的协议体系结构，并重点分析了各层协议的实现内容。
（二）精简TCP/IP协议栈的结构
TCP/IP协议是一个复杂的协议集，而嵌入式系统由于受到资源和速度的限制，不具有处理完整协议栈的能力，因此在具体实现时，必须对每一个协议进行仔细地评估，确定协议中哪些部分是必须的，从而根据系统要求有选择地加以实现，因此嵌入式Web服务器中并不实现所有的协议。在对TCP/IP协议进行精简时，以不影响网络基本功能为原则，以满足实用为目的，按照8位和16位等低端单片机的性能要求，对完整的TCP/IP协议进行一定程度的删减，量体裁衣。最终既要满足应用系统对数据传输和控制等功能的实际需要，又不能超出单片机系统的资源限制，实现联网功能。精简后的TCP/IP协议虽然功能不具备删减之前那样完善，但对于这种低端嵌入式系统的要求而言，还是完全可以胜任的。
TCP/IP协议在进行删减时应主要遵循两个原则：
1. 协议内容精简
嵌入式Web服务器的实现需要ARP, IP, TCP, ICMP等网络协议的支持，每一个完整协议都很庞大，全部实现是不现实的。应该在保证实现网络通信基本功能的前提下尽可能地精简协议，确定出协议的哪一部分是必需的，哪一部分可以省略，以满足系统要求。
2. 协议接口层次明确
TCP/IP协议分布在链路层、网络层、传输层和应用层上，协议是分层实现的，每一层只负责处理通信过程中的一部分问题。采用模块化的设计思路，如果需要修改哪个协议，只需修改相应模块的功能，其它模块不用改动。在网络系统中，按照分层的思想，从网络最底层开始每一层都为高层提供服务，明确层间接口对软件开发十分重要。
完整的TCP/IP协议是一个复杂的协议系统，但是在嵌入式Web服务器中并不是要实现所有的协议，应根据项目要求有选择地加以实现。以太网数据的传输是采用MAC地址来识别的，而ARP协议提供IP地址和数据链路层使用的MAC地址之间的转换功能，为了保证系统在以太网的通信，首先要实现ARP和RARP协议;嵌入式Web服务器与用户进行通信时，难免出现一些传输错误，为了保证计算机能够掌握网路和传输状态的准确信息，需要实现ICMP协议;由于嵌入式Web服务器要能在Internet上通信，在网络层一定要实现IP协议;在应用层，主要实现远端用户机通过浏览器的访问控制方式，所以要实现HTTP协议，而HTTP协议基于TCP协议实现传输的，加上TCP协议是面向可靠的数据流的传输，基于应用的需要和对可靠性的要求，在传输层采用TCP协议，并对TCP协议进行了简化处理，主要针对HTTP协议开发TCP协议。
考虑到系统的设计要求以及嵌入式系统的资源限制，最终在系统中实现了如下图所示几种协议，当然这并不是该协议子集的最优方案，但却是针对该系统的最恰当的方案，如图1所示。
（三）各层协议的具体实现
下文将详细阐述各层协议具体实现方案及其作用。
1. ARP协议
ARP (Address Resolution Protocol)也就是地址解析协议，是介于链路层与网络层之间，并不直接归属于具体的某一层。由于以太网底层硬件通过网卡的Mac地址进行寻址，而网络中传输的是含有IP地址的数据包。因此，当一台主机在以太网中要向另一台主机发送数据时，必须先找到与目标地址相对应的IP地址，换言之必须实现MAC地址到IP地址的映射，这就是地址解析协议的实质。
ARP协议主要有两种报文，即ARP请求报文和应答报文，该协议的实现主要是对这两种报文的实现，ARP协议的工作流程如下：当一台主机发送方要向另一台主机接收方发送数据时，发送方先在网络中广播含接收方IP地址的ARP请求报文，网络中所有主机都会收到这个请求。当接收方识别出该请求报文中的IP地址与自身相同时，它会返回一个包含自身MAC地址和IP地址的应答报文。发送方收到应答报文后，再根据接收方的MAC地址发送IP数据报。
在嵌入式WEB服务器环境中，服务器端一般是被动的接收来自客户的服务请求，为客户提供服务，也就是说服务器不会主动向某一IP地址发出数据帧。既然如此，始终处于被动状态的服务器完全不需要向任何主机发送ARP请求，因此，本方案中ARP协议只需能实现ARP应答报文即可。
2. IP协议
IP协议是TCP/IP核心协议之一，它负责将数据传输到正确的接收方，所有的TCP、UDP、ICMP及IGMP数据都封装在IP数据报内后再传输。
整个协议由数据报的接收和发送两个子程序构成。数据发送前，先对数据包添加20字节的IP报头形成IP数据报，再将构造好的数据报发送给对应IP地址的接收方。数据接收前，接收方先判断是否是发送给自己的IP数据报，再判断是哪种协议，是TCP协议，还是ICMP协议发送的数据，最后调用相应协议子程序来处理数据。
另外，无论是在接收还是发送的过程中，IP协议都会采取差错控制，通常使用计算校验和的方法来判断数据是否正确。
3. ICMP协议
IP数据报在网络中是不可靠传输的，很可能在传输过程中出错，为此，TCP/IP协议栈中专门设计了ICMP协议，将传输过程的错误或相关信息发送给发送方，还能实现故障检测、排除和优化网络性能。
ICMP协议的定义了五种差错报文和四种信息报文，对于本文所设计的系统，不必实现这样强大的功能。ICMP协议只需实现Ping(分组网间网探测器)响应。Ping响应的实质是利用回送请求与应答报文来检测网络是否可达，即检测网络的连通性。既可以查找数据分组的往返时间，还能统计出丢失的数据。当发送方向网络中发出回送请求，接收方将回送应答返回给发送方。如果应答回送成功，就表明该传输系统是连通的。
4. TCP协议
TCP (传输控制协议) 在IP协议软件提供的服务的基础上，支持面向连接的、可靠的、面向流的投递服务。TCP协议在进行数据传输时可分为建立连接、传输数据和关闭连接三个阶段，连接建立和终止过程通常叫做“握手”，TCP使用“三次握手”实现连接的建立，使用“四次握手”来终止连接。
要TCP协议的工作过程可以用状态变迁图来描述，完整的TCP协议状态变迁图是一个庞大的结构，所需的资源花费是巨大的。本论文设计中，根据系统的实际应用环境，Web服务器端只需要被动的接受用户的建立连接和终端连接的请求，因此，可以采用了一种简化的状态变迁图，如图2所示。
经过这样的裁减，整个状态变迁图显得结构简单易懂，实现起来也容易得多，同时又能满足嵌入式web服务器通信的需要，符合了设计方案对TCP协议精简的要求。
5. HTTP协议
HTTP (超文本传输协议) 协议是用来构建分布式、协同超媒体信息系统的应用层协议，它是一个通用的、无状态的协议。协议采用的是一种基于浏览器请求、服务器响应的工作模式，即B/S模式。
在已经建立TCP连接的基础上，一个HTTP会话包括两个过程：客户端发送请求数据报文，Web服务器端完成相应动作并发送应答数据报文。在HTTP协议的实现上，同样采用了精简的方法，Web服务器只响应GET方法，服务器端每当有请求报文到达时，先判断是否采用GET方法，如果是GET方法，准备符合协议的应答数据报文头部;从自身存储器中读出大量数据填入数据报文HTTP实体部分，并发送相应的网页，否则不做任何操作。
（四）结论
本论文提出应用于嵌入式系统的TCP/IP协议集，解决了TCP/IP的复杂性与低速处理器资源的有限性构成了一对较为尖锐的矛盾，从对Web服务器功能进行最小化定制的角度出发，通过两个层次来简化TCP/IP，缓解了这种矛盾，在低速处理器中实现简化的TCP/IP以实现功能最小化的Web服务器，具有较好的应用前景。
摘要：文章介绍在存储空间有限的嵌入式网络应用中, 通过合理选择TCP/IP协议子集, 实现了嵌入式Web服务器。详细分析了精简TCP/IP协议、嵌入式Web服务器在微嵌入式系统中的软件实现方法。
关键词：TCP/IP协议,嵌入式Web Server,精简
参考文献
[1]阿克塞尔森.嵌入式Ethernet和Internet通信设计技术[M].骆丽, 等译.北京航天航空大学出版社, 2006.
[2]WRichard Stevens.TCP/IP详解 (第1～2卷) [M].机械工业出版社, 2000.
[3]李刚.AduC8XX系列单片机原理与应用技术[M].北京航空航天大学出版社, 2002.
嵌入式IP 篇7
关键词：单片机,嵌入式TCP/IP,驱动引擎,软件复用
0引言
“人在回路”仿真系统,如飞机仿真系统、电站仿真系统等[1,2],会涉及人对设备的操纵及设备对仿真结果的反映。对于具有简单设备的系统,A/D(D/A)转换卡可很好地满足需求,但对于设备密集系统,布线和维护问题将变得难以控制。在工程实践中,人们更多地关注于具体控制技术的研究[3,4],却较少从软件工程的角度,对与硬件相关的软件可复用、开发模式等问题进行考虑,由此导致的非规范开发、重复开发、软硬件紧密依赖等问题对工程效率和质量产生了较大影响。本文采用通用部分和特定部分相分离的方法解决此类问题,涉及的具体研究内容包括: 1规范的系统体系结构;2可复用的软件系统;3简洁的硬件控制量表达法;4透明的通信介质和网络节点拓扑结构。
1系统体系结构
系统体系结构如图1所示,系统包括五大部分:嵌入式TCP/IP控制的设备群、驱动引擎、下位网、上位网、应用。每个设备由内置的单片机MCU(Micro Control Unit) 进行采样和驱动,采样数据经驱动引擎传给应用程序,来自应用程序的驱动数据经驱动引擎传给单片机。驱动引擎运行于工控机,TCP/IP[5]下位网络与单片机通信,经由TCP/IP网络[5]或反射内存实时网络[6]或二网结合构成的上位网络与应用程序通信。驱动引擎为可复用结构,可以集成任何数量的单片机而无需对结构做任何修改。驱动引擎的数量依赖于设备规模和实时性需求,一个配置有多块网卡NICs(Network Interface Cards)的驱动引 擎可满足大多数系统的需求。
系统软件配置结构如图2所示。其中,硬件配置文件AO.cfg,DO.cfg,AI.cfg,DI.cfg用于隔离特定硬件;下位网配置文件LowerComm.cfg用于隔离下位网通信节点; 上位网配置文件UpperComm.cfg用于隔离上位网通信节点和通信介 质;每个单片 机对应一 个动态链 接库DLL (Dynamic Link Library)。
2协议数据单元
存在两种协议数据单元:
(1)单片机至驱动引擎协议数据单元。
(2)驱动引擎至单片机协议数据单元。
3控制量二维标识规范
3.1控制量标识符
为适应控制量密集系统,每个硬件控制量以二维方式进行标识(见图3),规则如下:
(1)模出量:AO(面板号,控制量号)[:值范围]。
(2)模入量:AI(面板号,控制量号)[:值范围]。
(3)开出量:DO(面板号,控制量号)[:值范围]。
(4)开入量:DI(面板号,控制量号)[:值范围]。
根据以上规则,可对舱体内所有控制量做出标识,形成一个硬件标识图,为硬件驱动开发人员和仿真应用开发人员提供工作参考。
3.2控制量在程序中的访问方法
在C/C++程序中,硬件控制量按如下方法访问:
(1)驱动硬件。
AO(i,j)=x;// 以x值驱动AO(i,j)。
DO(i,j)=0;// 置DO(i,j)断开。
(2)采样硬件。
y=AI(i,j);//采样AI(i,j)存于y。
s=DI(i,j);//取DI(i,j)状态存于s。
3.3控制量规范实现
图4表示如何由二维标识定位控制量实际存储位置。 压缩二维索引依据硬件配置文件AO.cfg、AI.cfg、DO. cfg和DI.cfg确定。硬件配置文件遵循如下语法规则:
4单片机DLL
每个单片机对应一个DLL,该DLL输出函数Sample ()和Drive():
5驱动引擎
5.1下位网传输配置文件(LowerComm.cfg)
该文件语法规则如下:
驱动引擎从本地端点 <DrvEngineIP,DrvEnginePort >接收单片机发 来的采样 数据,从本地端 点 <DrvEngineIP,DrvEnginePort>向远程端点<McuIP,McuPort>发送驱动数据。
单片机DLL必须命名为McuName.dll,以便驱动引擎定位Sample()和Drive()函数。
5.2上位网传输配置文件(UpperComm.cfg)
该文件语法规则如下:
驱动引擎从本地端点 <DrvEngineIP,DrvEnginePort > 和 (或 )<DrvEngineRfmCardID,DrvEngineRfmAddr > 接收应用 程序发来 的驱动数 据,从本地端 点 < DrvEngineIP,DrvEnginePort>向远程端点<AppIP,AppPort>和(或)<AppRfmCardID,AppRfmAddr>发送采样数据。
5.3驱动引擎算法
驱动引擎关键算法步骤如下:
S1:(加载外部配置文件)加载外部配置文件AO.cfg、 AIcfg、DO.cfg、DI.cfg、LowerComm.cfg、UpperComm. cfg。
S2:(加载DLL和Sample/Drive)FOR LowerComm. cfg每一项DO。
S2.1:(加载DLL)调用LoadLibrary()[7]。
S2.2:(加载Sample/Drive)调用GetProcAddress ()[7]。
S3:(循环)DO S4至S5UNTIL结束。
S4:(下位通信)FOR LowerComm.cfg每一项DO。
S4.1:(接收MCU)IF<DrvEngineIP,DrvEnginePort >有数据到达THEN调用Sample()。
S4.2:(驱动MCU)调用Drive()。
S4.3:(发往MCU)从 <DrvEngineIP,DrvEnginePort >向<McuIP,McuPort>发驱动数据。
S5:(上位通信)FOR UpperComm.cfg每一项DO。
S5.1:(接收AOs/DOs)从<DrvEngineIP,DrvEnginePort>和(或)<DrvEngineRfmCardID,DrvEngineRfmAddr>接收AOs/Dos。
S5.2:(发送AIs/DIs)从 <DrvEngineIP,DrvEnginePort> 向 <AppIP,AppPort> 和 (或)<AppRfmCardID, AppRfmAddr>发送AIs/Dis。
6结语
嵌入式IP 篇8
过去嵌入式系统通常是深嵌于最终产品之中,以系统控制为基础,一般不与局域网(LAN)或互联网(Internet)连接。其微控制器在一个相当封闭的系统中工作,定时查询外设、收集数据、完成简单的处理工作,以及控制开关和LED指示灯。此外,微控制器也进行少量的数据操作或数据传输。
然而,这一切现在都改变了。现今的嵌入式系统一般都要连接到局域网,有时甚至有实时传输数据的需求,这样就有数十、甚至上百个控制器连接在一起。而且,随着嵌入式网络越来越复杂(因此需要更大的网络带宽和更远的传输距离),嵌入式以太网也开始涉足于工业控制、建筑物自动化、医疗和保安产品市场。
但是,要实现嵌入式设备的网络化,就必须有网络协议的支持。目前,网上使用的主要协议大都是基于TCP/IP协议栈的。鉴于嵌入式设备的局限性,不可能也没有必要实现标准TCP/IP协议栈中的所有内容。本文所采用的方法是:在详细分析标准TCP/IP协议栈的基础上,针对本嵌入式系统的实际需求对其进行适当裁剪,以确保移植之后的协议栈能正常运行。
2 TCP/IP协议栈分析
协议栈是指网络中各层协议的总和。其形象的反映了一个网络中文件传输的过程,由上层协议到低层协议,再由底层协议到上层协议。基于实际需求,在对TCP/IP协议进行分析的基础上,结合嵌入式系统资源限制和特定应用的需要,对完整的TCP/IP协议栈进行裁剪,保留系统必须的协议功能,将无关的协议裁减掉。
裁剪后的协议仍然需要符合规定的标准:
在链路层上,链路层的主要作用是为上层协议发送和接收数据包.由于网络接口采用以太网,系统必须要实现IEEE802.3所规定的CDMA/CD协议.网络层主要负责处理数据包在网络中的活动.在TCP/IP协议族中,网络层协议包括IP协议(网际协议)、ICMP协议(Internet控制报文协议),以及IGMP协议(Internet组管理协议)等.在网络层,由于系统要求能够通过网口和PC机进行通信,因此系统要实现IP协议.IP协议是TCP/IP协议栈的核心,所有的TCP、UDP以及ICMP数据都是以IP数据报文格式传输。IP协议主要负责IP报文报头的正确性,并且对UDP和ICMP报文实行分流.ICMP协议中规定了多种协议类型和代码,如果完全的实现也要耗费不少的系统资源,本嵌入式系统中,为了能够测试系统与网络的连接,系统只需实现ICMP协议中的Ping应答协议,Ping应答协议主要是检查网络是否连通.IGMP协议主要用于支持主机和路由器进行组播,在设计中不考虑实现IGMP协议.
ARP协议是属于链路层的协议。由于以太网上数据的传输是以网卡的MAC地址来进行识别的,而网络数据包中使用的是IP地址,这就要求协议栈要有实现IP地址到MAC地址转换的功能,也就是说,协议栈必须实现ARP协议。该协议把节点的IP地址解析成对应的以太网MAC地址(也叫物理地址)。ARP的执行通过ARP缓存表来完成IP地址和MAC的地址的映射。RARP(逆地址解析协议主要用于解决如何从MAC地址得到IP地址。
传输层主要为两台主机上的应用程序提供端到端的通信.传输层有两种不相同的传输协议:TCP(传输控制协议)和UDP(用户数据报协议).TCP是面向连接的,在不可靠的网络服务上提供端到端的可靠字节流。UDP协议是用来提供非面向连接的,它只是简单地把数据报从一台主机发送到另一台主机,但并不保证该数据报能到达另一端,可靠性必须由应用层来提供。在传输层,考虑到系统的简化及速度的要求,采用了UDP协议,为了确保UDP数据的到达,在应用程序中采用了重复发送、回复确认的方式来保证数据的正确性。
应用层协议主要是指用户进程。实时传输协议RTP(Realtime Transport Protocol):是针对Internet上多媒体数据流的一个传输协议。RTP被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上,但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输,并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务。实时传输控制协议RTCP(Realtime Transport Control Protocol):负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间,各参与者周期性地传送RTCP包,包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,能以有效的反馈和最小的开销使传输效率最佳化,故特别适合传送网上的实时数据。由于系统需要与外界进行实时数据传输,所以需实现以上两个协议。
经详细分析TCP/IP协议各层实现的功能,同时考虑到系统要求经网络接口传送一些测试数据到PC机,要求实时性好、传输速度快。根据这些要求,精简出的协议子集如表1所示。
3 ARP的详细分析与实现
IP地址有32bit,常见的以太网网络接口硬件地址长度为48bit,因此它们之间不存在简单的映射关系。此外,在一个网络上可能经常会有新的主机加入进来,或撤走一些主机。更换网卡也会使主机的硬件地址改变。可见在主机中应该存放一个从IP地址到硬件地址的映射表,并且这个映射表必须能够动态更新。如何实现这样的映射关系,是ARP协议所解决的主要问题,下面对其进行详细分析,为移植到系统中做准备。
3.1 ARP协议简介
地址解析协议(address resolution protocol,ARP协议)工作在链路层,是解决局域网中IP地址到MAC地址的映射问题,目的在于使网络节点间通信的数据帧能够在链路中正确的传输。每一个主机都设有一个ARP高速缓存(ARP cache),里面有所在局域网上的各个主机和路由器的IP地址到硬件地址的映射表,这些都是该主机目前知道的一些地址。
例如:当主机A欲向本局域网上的某个主机B发送IP数据包时,就先在自己的ARP高速缓存中查看有无主机B的IP地址。如果有,就可查出其对应的硬件地址,再将此硬件地址写入MAC帧,然后通过局域网将该MAC帧发往此硬件地址。如果无,主机A会先保留待发送的IP数据包,然后在本局域网广播一个询问目的主机硬件地址的ARP数据包,等收到回答后再将IP数据包发送出去。
ARP协议工作时有以下几种情况:
1)在同一个局域网中,本网中的某个主机希望发送数据包到另一个主机,这时,数据包首部中的IP地址需要映射为物理地址。
2)在同一个局域网中,路由器接收到了数据包,该数据包要转发给网络中的另一个主机,数据包中的目的IP地址就是必须映射为物理地址的那个逻辑地址。
由于路由器不会转发以太网层次上的广播消息,因此不在同一局域网中的H1与H2通信时,使用ARP将会失败,因为H2无法看到H1的广播ARP请求。有两个解决方案:
第一,可以对路由器进行配置,让它也响应对于H2所在网络的ARP请求。在这种情况下,H1将在ARP缓存表中增加一项(H2的IP地址,与H1相连路由器的IP地址),并且将发送给H2的流量发送给本地路由器。这种方案称为代理ARP。
有两种不同类型的代理ARP结点,可以通过arp命令及pub选项将它们加入到路由表中。
代理ARP结点的第一种类型:它允许将网络内的某一主机的IP地址填入到ARP高速缓存内。硬件地址可以设为任意值。如果本网中的主机H1不能实现ARP,那么可以使用这种类型的代理ARP结点。作为代理的主机代替H1回答所有的ARP请求,同时提供创建代理ARP结点时设定的硬件地址。这种类型的结点可以通过arp–a命令查看。
代理ARP结点的第二种类型:用于已经存有路由表结点的主机。该类型的代理ARP结点通常指明了作为代理ARP服务器的以太网地址。如果某代理ARP结点是为主机HD创建的,一般有以下步骤:
1)代理服务器收到来自主机HS的查找HD硬件地址的广播ARP请求,主机HS认为HD在本地网上;
2)代理服务器回答请求,并提供本机的以太网地址;
3)HS将发往HD的数据报发送给代理服务器;
4)收到发往HD的数据报后,代理服务器利用路由表中关于HD的信息将数据报转发给HD。
第二,让H1立即看到H2在另外一个远程网络上,并且将所有这样的流量都发送给一个默认的以太网地址,由它负责处理所有的远程流量。这种方案并不要求H1所在局域网的路由器知道它要为哪些远程网络提供服务。
3.2 ARP协议相关数据结构
根据RFC826标准,定义与ARP相关的主要数据结构如下:
ARP数据帧的头部结构arp
ARP报文被封装在以太网帧头部中传输,图1为ARP请求报文的头部格式。注意,以太网的传输存储是“大端格式”,即先发送高字节后发送低字节。例如,两个字节的数据,先发送高8位后发送低8位。所以接收数据的时候要注意存储顺序。
整个报文分成两部分,以太网首部和ARP请求/应答。
“以太网目的地址”字段:若是发送ARP请求,应填写广播类型的MAC地址FF-FF-FF-FF-FF-FF,意思是让网络上的所有机器接收到;
“帧类型”字段:填写08-06表示次报文是ARP协议;
“硬件类型”字段:填写00-01表示以太网地址,即MAC地址;
“协议类型”字段:填写08-00表示IP,即通过IP地址查询MAC地址;
“硬件地址长度”字段:MAC地址长度为6(以字节为单位);
“协议地址长度”字段:IP地址长度为4(以字节为单位);
“操作类型”字段:ARP数据包类型,1表示ARP请求,2表示ARP应答;
“目标硬件地址”字段:若是发送ARP请求,这里是需要目标机填充的。
ARP高速缓存表
ARP高速缓存一般设计成双向数据链的形式,这样整个缓存可以方便地动态增减。
3.3 ARP协议模块设计与实现
ARP整体模块图如图2。
3.3.1 控制模块:res_arp()
参数说明:
hardware硬件类型
target目标IP地址
函数说明:
该模块用来解析IP地址的MAC地址。
首先在映射表中查找与目标IP地址相对应的表项,如果有并且该表项为有效状态,则返回硬件地址;如果有但为无效(挂起)状态,则释放掉该数据报;如果没有找到,则需将数据报暂时挂起,并发送一个ARP请求包。在发送ARP请求到收到ARP应答之间,如果有多个发往同一个目的地址的IP数据报要发送,只有最近的一个IP数据报才被保留,之前的全部丢弃。实现流程图如图3。
3.3.2 输出处理模块:arp_output()
参数说明:
hardware硬件类型
target IP地址
函数说明:
发送ARP请求包。
该模块用于广播一个ARP请求。该模块建立一个ARP请求分组,并将它传输到接口的输出函数。
3.3.3 输入处理模块:arp_input()
参数说明:
接收到的ARP数据包
函数说明:
该模块用来处理接收到的ARP包。
首先验证ARP包格式是否正确,如果不正确,记录该差错,并丢弃该分组。然后查找目标端IP地址与我们接口的IP地址是否吻合,如果目标端IP地址是我们正在查找的地址,并且ARP是请求包,则根据表项中的相关内容构造一个ARP应答包,调用接口输出函数;如果目标端IP地址不是该接口的IP地址,但我们设置了代理ARP结点,并且ARP是请求包,则会产生代理ARP应答。以上两种情况均不满足,但ARP是逆地址请求包,则在映射表中查找是否有与目标端硬件地址相匹配项,有则依据找到的映射项构建逆ARP应答包,并调用接口输出函数。
3.3.4 ARP表处理模块:arp_lookup()
参数说明:
hardware硬件类型
ipaddr IP地址
函数说明:
该模块用来在ARP映射表中查找已知的IP地址。
如果找到符合输入参数类型的IP地址,则返回对应该结点的记录;否则没有找到,则返回NULL。
4 结束语
本文在分析标准TCP/IP协议栈的基础上,根据实际需求提出了裁剪协议栈和将其移植到嵌入式系统中的方法,并且重点对ARP的实现做出详细描述。对本文所提出的协议栈的检测,是通过两种方法完成的:第一,将本嵌入式系统通过以太网口连入局域网中,经该系统处理过的数据,局域网中的PC机都能正确接收;第二,经该系统处理过的数据,经路由器发往另一网络,该网络上的PC机仍能正确接收。通过以上方法的验证,确保了协议栈的正确性。
摘要：提出了嵌入式TCP/IP协议栈的一种实现方法,并重点介绍了ARP协议的数据结构和主要模块的详细设计,最终验证了该协议栈的正确性。
关键词：TCP/IP协议栈,ARP协议
参考文献
[1]王娜,庞艳霞,吴月萍.嵌入式Internet下TCP_IP协议栈中ARP的设计与实现[J].自动化技术与应用,2009,28(4):30-32.
[2]孔栋,郑建宏.嵌入式TCP/IP协议栈LWIP在ARM平台上的移植与应用[J].通信技术,2008(6).
[3]尤彩萍,张曦煌.嵌入式WEB中TCP_IP协议栈的分析与设计[J].淮阴工学院学报,2008(3).
[4]唐富年,殷少锋.一种嵌入式TCP_IP协议栈的设计与实现[J].电脑知识与技术,2007(6).
[5]陈英,马洪涛.局域网内ARP协议攻击及解决办法[J].中国安全科学学报,2007,17(7):126-131.
[6]雷必成.嵌入式系统中TCP/IP协议的精简与实现[J].微计算机信息,2006,22(17).
[7]谢希仁.计算机网络第五版[M].北京:电子工业出版社,2007.