因为需要使用DM9000，因此就有了这条血泪之路。话说那是一个月前，板子刚回来，感觉难度不大，因为此前搞过F4板子上的网络，对LWIP的移植和使用相对比较熟悉，所以花了3天的时间就把DM9000的驱动写好了，其实就是FSMC的配置，然后就是内部寄存器的读写，这个不难，驱动写完以后就是LWIP的移植，花了2个小时左右就移植成功了，成功以后开ping，ping成功，兴奋啊！但是在做webserver的时候发现网速很慢，而且很容易就会挂掉的！因此做了一次稳定性测试，就是连续的ping好几个小时，但是发现ping到0.5-2个小时的时候就会挂掉！！心碎啊，没办法，度娘，找各种DM9000在STM32上的程序，发现就那么几个，大多是就与RTT的DM9000例程修改的，就是在RTT例程的基础上修改一下IO口而已。而RTT对LWIP做了修改，而且移植方法和常用的不同，因此就排除了RTT的例程。但是将RTT的例程做了小修改，在我的板子上可以跑下去，这样可以确定板子硬件有没有问题！经过测试ping很稳定，时间基本小于1ms的。这说明什么？说明我的代码有问题啊，初步怀疑是接收和发送函数有问题，接着又是各种度娘啊，还是没有什么用啊，当时那个心情啊！本以为很容易的一件事结果拖了好几个星期了！！心急啊，但是又有什么办法啊，面对庞大的UCOSII和LWIP协议栈，顿时慌了手脚啊，当时感觉那个无助啊，就像被抛弃到了一个荒岛一样！前两天再看其他参考例程的时候突然灵光一现，发现虽然其他代码都使用了DM9000的中断，但是却没有一个在DM9000的中断中接收数据，而是在中断中发送一个信号量(参考的代码都是带系统的)，其他的任务接收该信号量，做任务同步，数据的接收在专门的接收任务中完成！！而我的数据接收是直接放在了DM9000的中断服务函数中，在进入中断的时候是要关闭中断的，这样有新的数据来时就会塞进MD9000的RX SRAM中，很容易导致overflow！接着就是死掉！昨天把数据的接收放到了一个任务中，中断里面也只是发送一个信号量，这样关中断时间就大大减小了，经过测试，ping好几个小时都没有挂掉，ping的时间基本也小于等于1ms。至此，找到了这个困扰了我一个月的问题所在，12号放假，终于赶到放假之前搞定了这个问题。项目也被拖了好几周，导致的严重后果就是EMWIN的教程严重滞后于原计划，看来只能放假回家加把劲了。唉，说多了都是泪啊，过去一个月那过的叫一个黑暗啊，有时候都怀疑自己的智商适不适合干这一行。
    写下一点小的调试经历，向那些因为一个小问题而奋战良久的程序猿致敬，因为选择了这条路，爬也要爬下去！