如果你认为所谓的毅力是每分每秒的“艰苦忍耐”式的奋斗，那这是一种很不足的心理状态。毅力是一种习惯，毅力是一种状态，毅力是一种生活。看了这么久的代码觉得是不是该写点东西了，不然怎么对得起某人口中所说的科研人员这个光荣称号。初见这十几二十万行的代码，着实看出了一身冷汗。现在想想其实也不是那么难，那么多革命先辈经过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处理器上使用的typedefunsigned 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协议栈熟悉的数据结构、将发送的数据包分解为芯片熟悉的数据结构就基本搞定了。最起码的，发送一个数据包函数和接收一个数据包函数需要被实现。
那就这样了吧，虽然写得草草，但终于在撤退之前搞定。好的开始是成功的一半，那这暂且先算四分之一吧。不晓得一个月、两个月或者更多时间能写完否。预知后事如何，请见下回分解。