基于ARM的嵌入式TCP/IP协议的实现 嵌入式, 网络应用, IP协议

我是MT

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