LwIP 协议栈源码详解 ——TCP/IP 协议的实现（二：移植综述）

1  移植综述

如果你认为所谓的毅力是每分每秒的 “艰苦忍耐”式的奋斗，那这是一种很不足的心理
状态。毅力是一种习惯，毅力是一种状态，毅力是一种生活。看了这么久的代码觉得是不是
该写点东西了，不然怎么对得起某人口中所说的科研人员这个光荣称号。初见这如山如海的
代码，着实看出了一身冷汗。现在想想其实也不是那么难，那么多革命先辈经过 N 长时间
才搞出来的东东怎么可能让你个毛小子几周之内搞懂。我见到的只是冰川的一小角，万里长
征的一小步，九头牛身上的一小毛…再用某人的话说，写吧，昏写，瞎写，胡写，乱写，写
写就懂了。
我想我很适合当一个歌颂者，青春在风中飘着。你知道，就算大雨让这座城市颠倒，我
会给你怀抱；受不了，看见你背影来到，写下我度秒如年难捱的离骚；就算整个世界被寂寞
绑票，我也不会奔跑；逃不了，最后谁也都苍老，写下我，时间和琴声交错的城堡。我正在
਀的歌。扯远了… 
正题，嵌入式产品连入 Internet 网，这个 MS 是个愈演愈烈的趋势。想想，你可以足不
出户对你的产品进行配置，并获取你关心的数据信息，多好。这也许也是物联网世界最基ᴀ
的雏形。当然，你的产品要有如此功能，那可不容易，至少它得有个目前很 Fashion 的 TCP/IP
协议栈。LWIP 是一套用于嵌入式系统的开放源代码 TCP/IP 协议栈。在你的嵌入式处理器
不是很 NB，内部 Flash 和 Ram 不是很强大的情况下，用它还是很合适滴。
LWIP 的设计者为像我这样的懒惰者提供了详细的移植说明文档，当然这还不够，他们
还尽可能的包揽了大部分工作，懒人们只要做很少的工作就功德圆满了。纵观整个移植过程，
使用者需要完成以下几个方面的东西：
首先是 LWIP 协议内部使用的数据类型的定义，如 u8_t，s8_t，u16_t，u32_t 等等等等。
由于所移植平台处理器的不同和使用的编译器的不同，这些数据类型必须重新定义。想想，
一个 int 型数据在 64 位处理器上其长度为 8 个字节，在 32 位处理器上为 4 个字节，而在 16
位处理器上就只有两个字节了。因此这部分需要使用者根据处理器位数和和使用的编译器的
特点来编写。所以在 ARM7 处理器上使用的 typedef unsigned int u32_t 移植语句用在 64 位处
理器的移植过程中那肯定是行不通的了。
其次是实现与信号量和邮箱操作相关的函数，比如建立、删除、等待、释放等。如果
在裸机上直接跑 LWIP，这点实现起来比较麻烦，使用者必须自己去建立一套信号量和邮箱
相关的机制。一般情况下，在使用 LWIP 的嵌入式系统中都会有操作系统的支持，而在操作
系统中信号量和邮箱往往是最基ᴀ的进程通信机制了。 UC/OSII 应该算是最简单的嵌入式操
作系统了吧，它也无例外的能够提供信号量和邮箱机制，只要我们将 UC/OSII 中的相关函
数做相应的封装，就可满足 LWIP 的需求。LWIP 使用邮箱和信号量来实现上层应用与协议
栈间、下层硬件驱动与协议栈间的信息交互。LWIP 协议模拟了 TCP/IP 协议的分层思想，
表面上看 LWIP 也是有分层思想的，但从实现上看，LWIP 只在一个进程内实现了各个层次
的所有工作。具体如下：LWIP 完成相关初始化后，会阻塞在一个邮箱上，等待接收数据进
行处理。这个邮箱内的数据可能来自底层硬件驱动接收到的数据包，也可能来自应用程序。
当在该邮箱内取得数据后，LWIP 会对数据进行解析，然后再依次调用协议栈内部上层相关
处理函数处理数据。处理结束后，LWIP 继续阻塞在邮箱上等待下一批数据。当然 LWIP 还
有一大串的内存管理机制用以避免在各层间交互数据时大量的时间和内存开销，这将在后续
讲解中慢慢道来。当然，但这样的设计使得代码理解难度加大，这一点让人头大。信号量也
可以用在应用程序与协议栈的互相通信中。比如，应用程序要发送数据了，它先把数据发到
LWIP 阻塞的邮箱上，然后它挂起在一个信号量上；LWIP 从邮箱上取得数据处理后，释放
一个信号量，告诉应用程序，你要发的数据我已经搞定了；此后，应用程序得到信号量继续
运行，而 LWIP 继续阻塞在邮箱上等待下一批处理数据。
其其次，就是与等待超时相关的函数。上面说到 LWIP 协议栈会阻塞在邮箱上等待接收
数据的到来。这种等待在外部看起来是一直进行的，但其实不然。一般在初始化 LWIP 进程
的时候，都会同时的初始化一些超时事件，即当某些事件等待超时后，它们会自动调用一些
超时处理函数做相关处理，以满足 TCP/IP 协议栈的需求。这样看来，当 LWIP 协议栈阻塞
等待邮箱之前，它会精明的计算到底应该等待多久，如果 LWIP 进程中没有初始化任何超时
事件，那好，这种情况最简单了，永远的挂起进程就可以了，这时的等待就可以看做是天长
地久的….有点暧昧了。如果 LWIP 进程中有初始化的超时事件，这时就不能一直等了，因
为这样超时事件没有任何被执行的机会。LWIP 是这样做的，等待邮箱的时间设置为第一个
超时事件的时间长度，如果时间到了，还没等到数据，那好，直接跳出邮箱等待转而执行超
时事件，当执行完成超时事件后，再按照上述的方法继续阻塞邮箱。可以看出，对一个 LWIP
进程，需要用一个链表来管理这些超时事件。这个链表的大部分工作已经被 LWIP 的设计者
完成了，使用者只需要实现的仅有一个函数：该函数能够返回当前进程个超时事件链表的首
地址。LWIP 内部协议要利用该首地址来查找完成相关超时事件。
其其其次，如果 LWIP 是建立在多线程操作系统之上的话，则要实现创建一个新线程的
函数。不支持多线程的操作系统，汗…表示还没਀过。不过 UC/OSII 显然是支持多线程的，
地球人都知道。这样一个典型的 LWIP 应用系统包括这样的三个进程：首先启动的是上层应
用程序进程，然后是 LWIP 协议栈进程，最后是底层硬件数据包接收发送进程。通常 LWIP
协议栈进程是在应用程序中调用 LWIP 协议栈初始化函数来创建的。注意 LWIP 协议栈进程
一般具有最高的优先级，以便实时正确的对数据进行响应。
其其其其次，其他一些细节之处。比如临界区保护函数，用于 LWIP 协议栈处理某些临
界区时使用，一般通过进临界区关中断、出临界区开中断的方式来实现；又如结构体定义时
用到的结构体封装宏，LWIP 的实现基于这样一种机制，即上层协议已经明确知道了下层所
传上来的数据的结构特点，上层直接使用相关取地址计算得到想要的数据，而避免了数据递
交时的复制与缓冲，所以定义结构体封装宏，禁止编译器的地址自动对齐是必须的；还有诸
如调试输出、测量记录方面的宏不做讲解。
最后，也是比较重要的地方。底层网络驱动函数的实现。这取决于你嵌入式硬件系统
所使用的网络接口芯片，也就是网卡芯片，常见的有 RTL8201BL、 ENC28J60 等等。不同的
接口芯片厂商都会提供丰富的驱动函数。我们只要将这些发送接收接口函数做相应的封装，
将接收到得数据包封装为 LWIP 协议栈熟悉的数据结构、将发送的数据包分解为芯片熟悉的
数据结构就基ᴀ搞定了。最起码的，发送一个数据包函数和接收一个数据包函数需要被实现。
那就这样了吧，虽然写得草草，但终于在撤退之前搞定。好的开始是成功的一半，那
这暂且先算四分之一吧。不晓得一个月、两个月或者更多时间能写完否。预知后事如何，请
见下回分解。