DM9000调试血泪总结

2019-07-21 04:59发布

    因为需要使用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的教程严重滞后于原计划,看来只能放假回家加把劲了。唉,说多了都是泪啊,过去一个月那过的叫一个黑暗啊,有时候都怀疑自己的智商适不适合干这一行。
    写下一点小的调试经历,向那些因为一个小问题而奋战良久的程序猿致敬,因为选择了这条路,爬也要爬下去!
友情提示: 此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。