嵌入式LED显示屏控制系统应用研究 第10页
31
union{//传输层数据包头
struct tcphdr*th;
struct udphdr*uh;
struct icmphdr*icmph;
struct igmphdr*igmph;
struct iphdr*ipiph;
struct spxhdr*spxh;
unsigned char*raw;
}h;
union{//网络层数据包头
struct iphdr*iph;
struct ipv6hdr*ipv6h;
struct arphdr*arph;
struct ipxhdr*ipxh;
unsigned char*raw;
}nh;
union{//链路层数据包头
struct ethhdr*ethernet;
unsigned char*raw;
}mac;
struct dst_entry*dst;//指明发送地址
char cb[48];//存放每一协议层可以自由使用的一段空间
unsigned int len;//当前协议数据包长度
unsigned int data_len;
unsigend int csum;//校验和
unsigned char__unused,cloned,pkt_type,ip_summed;
__u32 priority;
atomic_t users;
unsigned short protocol;
unsigned short security;
unsigned int truesize;//分配到的内存空间大小
unsigned char*head;//指向内存中数据区的起始地址
unsigned char*data;//指向协议数据的起始地址
unsigned char*tail;//指向协议数据的结束地址
unsigned char*end;//指向内存中数据区的结束地址
void(*destructor)(struct sk_buff*);
……
}
这个数据结构中最有用的部分是描述传输层包头、网络层包头和链路层包头这三个联合（h、nh
和mac）。这些联合包含了几个结构，依赖于具体的数据包中使用的协议。应该注意的是传输层包头
和网络层包头可能是指向内存中的同一位置。这是TCP数据包可能出现的情况，其中h和nh都应
当被看做指向IP头结构的指针。也就是说尝试通过h->th获取一个值，并认为该指针指向一个TCP
头，将会得到错误的结果。因为h->th实际上是指向IP头，与nh->iph得到的结果相同。东南大学硕士学位论文
32
4.3 UDP协议简介
在TCP/IP协议族中，用户数据报协议（UDP）提供应用程序之间传输数据报的基本机制。UDP
使用底层IP协议在各机器之间传输报文，提供和IP一样的不可靠、无连接的数据报交付服务。它
没有使用确认来确保报文到达，没有传入的报文排序，也不提供反馈信息来控制机器之间信息流动
的速度。因此，UDP报文可能会出现丢失、重复、或乱序到达的现象。而且，分组到达的速率可能
大于接收进程能够处理的速率。所以使用UDP的应用程序要承担可靠性方面的全部工作。
图4.3为UDP数据报的字段格式。
0 16 31
源端口目的端口
报文长度校验和
数据
……
图4.3 UDP数据报的字段格式
值得注意的是UDP校验和覆盖的范围超出了UDP数据报本身的范围。为了计算校验和，UDP
把伪首部引入数据报中。校验和包括伪首部、UDP首部和用户数据。伪首部格式如图4.4所示。
0 8 16 31
源IP地址
目的IP地址
零协议UDP长度
图4.4计算UDP校验和时伪首部格式
4.4基于Linux的UDP传输
在Linux环境下采用UDP传输数据时不用考虑底层实现，因为操作系统已经承担了绝大部分事
情，使用Berkeley套接字可以很方便的达到目的。套接字有三种类型：流式套接字（SOCK_STREAM）、
数据报套接字（SOCK_DGRAM）和原始套接字。面向连接的流式套接字使用TCP，面向无连接的
数据报套接字使用UDP。
如果使用无连接的数据报套接字编程，程序的流程可以用图4.5表示。
图4.5基于Linux的UDP传输流程第四章基于Linux的软件设计
33
程序首先用socket()函数生成一个套接字，然后用bind()函数将套接字绑定到指定端口（这一步
有时是可省略的，譬如需要系统随机选择发送端口）。主要发送和传输内容由sendto()函数和recvfrom()
函数完成，recvfrom()是阻塞函数，程序在接收到有效内容前不会往下执行。最后通讯完成，关闭套
接字。
4.5 TFTP协议简介与存在的问题
简单文件传输协议（TFTP）是为客户和服务器间不需要复杂交互的应用程序而设计的。TFTP
仅限于简单文件传输操作，不提供访问授权。由于TFTP局限性较大，TFTP软件比FTP小得多。
TFTP不需要可靠的数据流交付服务，它运行在UDP或其他人和不可靠分组传输系统上，使用超时
和重传保证数据块到达。发送端采用固定大小（512字节）的块传输文件，并在发送下一块前等待
对每个块的确认。接收端每收到一个块后都加以确认。
TFTP的规则很简单。发送的第一个分组请求文件传输，并建立客户与服务器之间的交互，分组
指明了文件名，并指定是要传输方向（读/写）。文件块从1开始连续编号。每个数据分组包括一个
首部，指明传输块的数目，并且每个确认包含被确认的块数。少于512字节的块标志文件尾。可以
在数据或确认的位置上发送差错报文，差错将中止文件传输。
一旦发出了读或写请求，服务器使用客户的IP地址和UDP协议端口号识别后续操作。因此data
报文和ack消息都不需要指明文件名。
由于对称性，TFTP重传非同寻常。通信双方各自实现超时和重传。如果发送端超时，它将重传
丢失的数据块。如果负责确认的一端超时，它将重传丢失的确认，让两端都参与重传将有助于保证
在丢失单个分组时传输不会失败。
在Linux下，使用TFTP传输文件是必须采用基于命令行的软件tftp或其他类似独立软件。采用
这种方法虽然保证了基于UDP传输的可靠性等问题，但是无法整合到自己编写的程序中去。不论是
上位机PC或者是嵌入式系统上的应用程序编写，采用TFTP传输的想法是没有可行性的，但是其实
现思路与原理却可以借鉴，也就是让自己编写的应用程序实现与TFTP协议类似的文件传输或数据
传输
4.6 TCP协议简介
IP协议提供不可靠、无连接和尽力投递的服务，构成了因特网数据传输的基础。TCP（传输控
制协议）在IP协议提供的服务基础上，TCP协议软件增加了若干机制，提供面向连接的可靠的流投
递服务。具体包括如下特性：
面向流。应用程序之间传输的数据可视为无结构的字节流（或位流），流投递服务保证收发
的字节顺序完全一致。
面向连接。数据传输之前，TCP模块之间需要建立连接（类似虚电路），其后的TCP报文
在此连接基础上传输。
可靠性。接收方根据所收到的报文中的校验和，判断传输的正确性：如果正确，进行应答，
否则丢弃报文。发送方如果在规定的时间内未能获得应答报文，自动进行重传。
缓冲传输。TCP模块提供强制性传输（立即传输）和缓冲传输两种手段。缓冲传输允许将
应用程序的数据流积累到一定的大小，形成报文，再进行传输。
全双工。TCP模块之间可以进行全双工的数据流交换。
流量控制。TCP模块提供滑动窗口机制，支持收发TCP模块之间的端到端流量控制。
同UDP协议相同，TCP协议以IP协议为传输基础，同时又可面向多种应用程序提供传输服务。
为了能够区分出对应的应用程序，使用TCP端口甄别。东南大学硕士学位论文
34
TCP端口与一个16位的整数值相对应，该整数值也被称为TCP端口号。需要服务的应用进程
与某个端口号进行绑定（使用bind()函数），这样TCP模块就可以通过该TCP端口与应用进程通信。
由于IP地址只对应到因特网中的某台主机，而TCP端口号可对应到主机上的某个应用进程，因此，
TCP模块采用IP地址和端口号的对偶来标识TCP连接的端点。一条TCP连接实质上对应了一对TCP
端点。图4.6为TCP端口说明。
图4.6 TCP端口说明
4.7基于Linux的TCP传输
在Linux环境下，采用TCP传输数据同样不用考虑底层实现。TCP采用流式套接字
（SOCK_STREAM），
如果使用无连接的数据报套接字编程，程序的流程可以用图4.7表示。
图4.7基于Linux的UDP传输流程
服务器程序首先用socket()函数生成一个套接字，然后用bind()函数将套接字绑定到指定端口，
接下来开始通过listen()函数监听端口，监听到客户机发出的连接请求时使用accept()接收请求建立连
接，然后基于所建立的连接，用recv()和send()函数完成数据接收和发送，最后关闭套接字。
客户机程序也必须先建立一个套接字，然后绑定到指定端口（这一步可省略），采用函数connect()
向服务器发出连接请求，建立成功后开始传输数据，最后关闭套接字。
在顺序上，必须先由服务器程序监听端口，再由客户机发出连接请求，否则connect()将失败。第四章基于Linux的软件设计
35
采用客户机/服务器（C/S）模型是多对一的模型，广泛存在于互联网应用中。如果需要一对一
的点对点通讯，只需要将服务器端同意建立的客户数控制在1个状态即可。但是与UDP不同的是，
TCP传输必须有一方担任监听的角色，令一方发出连接申请，然后建立连接，这是必不可少的。
在本系统中，嵌入式LED大屏幕控制器部分应当扮演服务器角色，不停的监听端口，因为作为
客户机的远程PC终端仅需要在特定时候同嵌入式LED大屏幕控制器通讯，完成系统复位或图像传
输等功能，远程PC终端是连接的请求一方。东南大学硕士学位论文
第五章基于uC/OS-II的软件设计
5.1 uC/OS-II的移植
5.1.1 uC/OS-II移植的主要工作
1.编写OS_CPU.H文件：修改数据类型，编写开关中断程序，定义堆栈方向等。
2.编写OS_CPU_C.C文件：编写OSTaskStkInit（）函数初始化任务堆栈以及其余9个钩子函
数。
3.编写OS_CPU_A.S文件：编写OSStartHighRdy（）、OSCtxSw（）、OSIntCtxSw（）、OSTickISR
（）四个汇编函数，分别完成使就绪态任务中最高优先级任务运行、任务级任务切换、中
断级任务切换、时钟节拍中断处理的功能。这几个函数相对稍难。
4.编写其余配置文件，调试等等。
5.1.2移植注意点及处理方法
1.运行模式的选择
ARM处理器有7种运行模式，除系统/用户模式外皆为异常模式。系统复位后处理器处于
SVC特权模式，而SWI软中断也进入SVC模式，这样就必须在调用SWI指令前将R14_svc和
SPSR_svc压栈保护。本移植中任务级任务切换靠SWI软中断服务程序实现。尽管很多人喜欢在
SVC特权模式下运行模式，尽管有些类似移植也基于SVC模式，但是因为在SVC模式运行时
再调用SWI软中断产生异常将增加移植难度，所以我们只能在系统或用户模式中选择。由于在
用户模式下处理器模式不可切换，我们最终有两种方案：
①直接将uC/OS-II运行于系统模式，该方案调式时方便。
②将uC/OS-II运行于用户模式，而在任务切换时从IRQ或者SVC模式切换到系统模式处
理堆栈（因为系统/用户模式使用的是同一组物理寄存器）。该方案较安全。
实际上这两种方案相差不大。方便起见，我们选择方案①。
2.时钟节拍中断的选择
OSTickISR（）函数是一个时钟节拍中断服务程序，由硬件产生的10-100Hz的中断作为一
个周期性时钟源，调用OSTickISR（）进行节拍服务。在很多移植中，大家喜欢使用芯片内部
定时器做时钟源。请注意，AT91RM9200的系统定时器（ST）部分为我们提供了一个RTOS专
用时钟源，系统定时器时钟为连续的32768Hz时钟源，通过设置相关寄存器，本移植设置时钟
节拍中断频率为50Hz。
3.任务堆栈的设计
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>
嵌入式LED显示屏控制系统应用研究 第10页下载如图片无法显示或论文不完整，请联系qq752018766
