LPC1768在RreeRTOS上lwip网络协议栈的实现（DM9161）

在调试LPC1768的lwip网络协议栈是遇到N多问题，但又不得不干，现在终于调试通了把问题整理如下：

网上多的是DP83848的配套驱动，相比于DM9161，其实驱动差别不大，主要注意以下几个寄存器就可以了

首先是PHY的偏移，不同的PHY的MDIO读写偏移是不一样的，DP83848的偏移一般是0x0500,而DM9161或DM9162的偏移是0x0300。

第二、就是PHY的ID值，因为PHY默认是要通过MDIO进行PHY读写配置和状态获取的，但前提是能读到正确的ID，因为ID都读写对了 ，就说明前面说的偏移和读写方法都是没有问题的，当然也有遇到ID读写对了但是在配置自动识别功能时出错，这种一般是PHY没有焊接好导致的。

第三、Dp83848的配置成为PHY_AUTO_NEG功能后需要等待状态正常，获取当前的自动识别状态，是100M还是10M，是Full还是falf，Dp83848和DM9161都是根据状态寄存器BMSR （01）来获取。

第四、在配置完成PHY_AUTO_NEG功能以后还需等待link staus置位，dp83848的状态位是PHY Status Register (PHYSTS), address 0x10 第0位，而DM9161的确是Basic Mode Status Register (BMSR) - 01 的第0位。

贴上我们遇到的一个麻烦问题：

1、最早工程代码是一个同事直连电脑调试的，而且当时只能用10M（为啥只能用10M，说是100M不稳定）后来在应用场景却是通过小hub转接多台设备到电脑，问题是直连电脑或用大型的交换机很正常，但是小hub就会经常连接不上要么就是ping不通，要放电好一会才能用。后来发现强制调到100M就ok了，总结为貌似小hub对10M支持不好。

2、强制100M是可以了 但是新的问题又来了，用ping测试会发现ping的事件越久 断包概率越大，而且我们有三套板子，效果都还不一样，有个最好，压根就重来不断。不用想就感觉是硬件问题，所以我们硬件工程师（我老大）就基本上把周围的硬件全换掉，还是不行，问技术支持吧，说是软硬件很简单的。最后实在没办法了，请大牛，大牛直接来一句估计是网络协议栈的问题。好，现在该我上场搞他，现网上多的是lpc1768和lwip1.3.x的配合基本没有更高的版本，就比较奇怪，我就在lwip官网http://download.savannah.gnu.org/releases/lwip/下了个1.4.1的版本（为啥要下1.4.1 不用2.0.0,因为我看到他两个版本间间隔时间2012-2017，查看下就知道其实1.4.1已经很可靠的版本了，至于2.0.0是外加了很多网络协议栈6lowpan啥的 觉得没必要），这里想说的是不要觉得lwip很大，由移植恐惧症，其实人家给你做好了考虑，只需要改些相关的接口就ok了，有个三五年经验的半天就搞定了。终于我是大半天搞定，终于功夫不负有心人，没有超时的ping包出现了 最多也是ping包多少ms，但是后面实测的tcp通讯 你会发现ping的好不如通讯好，话句话说就是通讯有延时，而且有时很很长，（哎，治标不治本啊）。而且你会发现除了没有解决问题，还引入了新的问题：很容易卡死掉，查看map可以看到1.4.1的lwip版本比1.3.2的版本多出个10K内存（lpc1768自带64K）.

最后没办法了 再找FAE，人家也没办法了，撂了一句“不会是买的歪的吧”，我们就让他给寄了几个正品过来换上马上ok！！！！简直无语了。。。

最后终结下，估计是买的片子有问题或焊接过烫导致，如果遇到硬件复位不能正常恢复的话80%是硬件问题，从软件查问题也可以，只是可能会比硬件查问题要耗时久一下，还有就是有时间大佬说的也不一定全是对的。

最后奉上改的实例源码：

http://download.csdn.net/download/u014159143/10196717