基于ARM的嵌入式TCP/IP协议的实现

摘要：介绍嵌入式TCP/IP协议在低速处理器中的一种简化实现方案，并成功应用于某分布式监控系统中。 关键词：TCP/IP协议 嵌入式 ARM 在网络应用日益普遍的今天，越来越多的嵌入式设备实现Ｉｎｔｅｒｎｅｔ网络化。ＴＣＰ／ＩＰ协议是一种目前被广泛采用的网络协议。嵌入式Ｉｎｔｅｒｎｅｔ的技术核心是在嵌入式系统中部分或完整地实现ＴＣＰ／ＩＰ协议。由于ＴＣＰ／ＩＰ协议比较复杂，而目前嵌入式系统中大量应用低速处理器，受内存和速度限制，有必要将ＴＣＰ／ＩＰ协议简化。 图1 协议处理 １ ＴＣＰ／ＩＰ协议的实现 嵌入式ＴＣＰ／ＩＰ协议一般实现：ＡＲＰ／ＲＡＲＰ、ＩＰ、ＩＣＭＰ、ＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ、ＦＴＰ、ＴＥＬＮＥＴ等协议，协议处理的主要流程如图１所示。 １．１ ＴＣＰ协议的实现 工业控制领域传输层采用ＴＣＰ协议、不用ＵＤＰ协议，是考虑到实时监控系统中传输量并不大，而可靠性要求较高。ＴＣＰ协议是面向连接的、端对端的可靠通信协议。它采用了许多机制来保证可靠传输，应用于嵌入式系统显得过于复杂。 ＴＣＰ协议数据传输可分为三个阶段：建立连接、传输数据和断开连接。它的实现过程可以用状态机来描述。建立连接有两种方法，即主动打开和被动打开。服务器端是一种被动打开，它一直在侦听连接请求；而客户端是一种主动打开，它发送连接请求以建立连接。研究发现，如果ＴＣＰ层的上层实现服务器端的应用，可以将标准ＴＣＰ状态机建立连接过程中客户端建立连接的状态机部分简化掉。同理，如果应用是基于客户端的，可以将服务器端建立连接的状态机部分简化掉。断开连接有两种方式：一是主动断开连接；另一是被动断开连接。被动断开连接的处理较为简单，但标准ＴＣＰ协议的主动断开连接的状态机部分过于复杂。经过实验发现，在需要主动断开连接的时候，发送一个Ｆｉｎ数据报；接收到对Ｆｉｎ数据报的确认后，再发送一个Ｒｅｓｅｔ数据报，即可顺利完成一次主动断开连接。 标准的ＴＣＰ协议使用慢启动的滑动窗口机制。滑动窗口是一种在流量控制和网络传输效率之间折中的方案。它允许发送方在等待一个确认之前发送多个窗口，其确认是一种批量的确认。研究滑动窗口协议发现，滑动窗口的一个极限情况，是只使用单个窗口，就变成了一种简单确认的处理方法。使用该方法后，所有的处理只是对单个数据报的发送和确认，节约了系统的资源，也使维护更加方便。为了协议的兼容性，需要通信的另一方也使用简单确认方法。因为如果对方使用较大的窗口，就可能造成处理器被淹没。这个问题可以通过设置待发送数据报的ＴＣＰ头部的Ｗｉｎｄｏｗｓ字段的大小解决。 在上述基础上，简化实现ＴＣＰ协议的流程图如图２所示。其中“不同状态的相应处理”指根据接收到的ＴＣＰ报文准备待发送数据报并将其发送到以太网上。这部分根据ＴＣＰ所处的不同状态，所做的处理是不一样的。 １．２ ＩＰ协议 ＩＰ协议是ＴＣＰ／ＩＰ的基础，为不同网络的主机之间发送数据报的操作序列提供无连接服务。通过在数据报前添加ＩＰ协议头，使每个数据报具有寻址能力。嵌入式系统只把ＩＰ作为传输工具，进行简化以完成主要的操作。得到ＩＰ包后，检验ＩＰ头部的版本、目的地址、校验和正确否，解析出协议类型字段，由此交给相应的高层协议处理。发送ＩＰ包时，将缓冲区内的源地址与目的地址互换，设置校验和，然后交给下层协议处理。不符合要求，则将此包丢弃。ＩＰ包最大可以为６５ＫＢ，可以分段传输，而在嵌入式系统里根本无法容纳如此大的数据包，因此一般不支持分段传输。所以限制ＭＣＵ发送和接收数据包的方式以避免分段传输，从而减少程序复杂度。 １．３ 其它协议 ＡＲＰ协议为３２位ＩＰ地址到对应的４８位以太网地址之间提供动态映射。嵌入式系统中仅响应ＡＲＰ请求，发送ＡＲＰ回答包。请求者广播出包含ＡＲＰ请求的以太帧、目的以太网地址为全１的广播地址。本机收到后，由目的ＩＰ地址发现自己是目的主机，发送一个ＡＲＰ回答。ＩＣＭＰ通过ＩＰ协议传输其报文。ＩＰ协议是无连接的，它无法将报文和错误信息传到最初的主机，ＩＣＭＰ将状态信息和错误信息发送到发报文的主机。 ２ 前端设备的系统设计 ＴＣＰ／ＩＰ协议扩展到工业控制级，将企业内部计算机网络应用于工业现场实时信息的发布和显示，通过Ｉｎｔｅｒｎｅｔ浏览器对现场工业信息进行动态监视。下面是笔者在某公司一分布式监控系统中的应用实例。基于ＴＣＰ／ＩＰ协议的前端设备系统软件结构如图３。前端嵌入式设备处理器是Ｓａｍｓｕｎｇ公司的Ｓ３Ｃ４５１０Ｂ（ＡＲＭ核）。该芯片是用在基于以太网系统的高性价比、高性能的１６／３２位ＲＩＳＣ微控制器。通信部分采用ＢＮＣ接口方式，信号输出经耦合隔离变压器由ＲＪ４５接头联入集线器，此外还设计了液晶显示和键盘输入当地接口功能。 在ＴＣＰ／ＩＰ协议中多处用到超时和重发机制。这种机制对于确保两个或多个彼此独立的通信结点从通信错误或故障状态自动恢复到正常状态是非常有效的，但也增加了软件结构的复杂性。因为对超时的处理通常独立于正常程序流程，也就是与正常的程序流程异步。要实现的ＴＣＰ／ＩＰ协议软件中有四处要用到定时器：第一是在ＡＲＰ高速缓存的维护中，被添加到ＡＲＰ高速缓存中的表项在一段时间后要置为无效；第二是在等待对发出的ＡＲＰ请求返回响应时，可能会在指定的超时时间内还未收到返回的响应；第三是在ＩＰ组装收到分片时，由于部分分片在一定时间内没有收到而丢弃整个ＩＰ包；第四是在ＴＣＰ等待接收方对数据段的确认时。如果在指定时间内还未收到对某个数据段的确认，需重新发送。从上述可见，要实现的定时器具备以下特点： %26;#183;对定时的精度要求都不是很高，基本都是秒级的精度。这样，完全可以稍滞后一些来处理定时器超时，不把超时处理放在时钟中断处理程序中。 %26;#183;对同一类超时处理可以由同一处理程序来完成，只是传入到相应的处理程序中的参数不同而已。例如一个ＡＲＰ高速缓存中的表项超时时，需要将其置为无效，可以统一用一个处理程序，参数中放入相应的表项地址即可。 首先，定义一定时器的数据结构，如图４所示。每一类超时都是由一个超时控制块和其所属的一个由超时事件项组成的链表管理。整个链表按超时事件将要发生的时间顺序排列，先发生的超时事件排列在前。超时控制块中的ｈｅａｄ＿ｐｔｒ用以指向一个超时事件项链表的首项；ｔｉｍｅｏｕｔ＿ｐｒｏｃｅｓｓ是超时事件发生时处理程序的入口地址。在每个超时事件项中，ｎｅｘｔ＿ｐｔｒ指向链表中的下一项；ｒｅｌａｔｉｖｅ＿ｔｉｍｅ是本表项的超时事件相对于上一表项的超时事件发生的相对时间。所以某个表项表示的超时事件距离当前的时间是它以前所有表项（包括自身）中的ｒｅｌａｔｉｖｅ＿ｔｉｍｅ的和。ｒｅｌａｔｉｖｅ＿ｔｉｍｅ的基本单位是ｇｒａｎｕｌａｒｉｔｙ。 定时器任务使用一个信号量作同步。信号量有两个变量：ｃｏｕｎｔ和ｗａｉｔｉｎｇ＿ｔａｓｋ。ｃｏｕｎｔ对事件计数，当ｃｏｕｎｔ大于０时，表示有ｃｏｕｎｔ个事件发生并等待处理；当ｃｏｕｎｔ小于０时，表示有某个任务在等待事件的发生，此时ｗａｉｔｉｎｔ＿ｔａｓｋ保存相应任务控制块的地址。信号量有两个操作：ｓｅｍ＿ｕｐ和ｓｅｍ＿ｄｏｗｎ。ｓｅｍ＿ｕｐ首先使ｃｏｕｎｔ加１，然后看ｃｏｕｎｔ是否为０，若为０表示有任务在等待，通过ｗａｉｔｉｎｇ＿ｔａｓｋ中记录的任务控制块的地址把等待任务的状态设为就绪，否则返回。ｓｅｍ＿ｄｏｗｎ首先使ｃｏｕｎｔ减１然后看ｃｏｕｎｔ是否小于０，若小于０会使当前任务成为等待状态并引发任务管理器对任务的调度，否则返回。 每当时钟中断服务程序计数到ｇｒａｎｕｌａｒｉｔｙ个时钟中断，给定时器任务使用的信号灯作ｓｅｍ＿ｕｐ操作。当定时器任务被调度执行时，它遍历每一个超时控制块，对每一个超时控制块作如图５所示的处理，最后对信号灯调用ｓｅｍ＿ｄｏｗｎ。