到目前为止我给4种不同的MAC编写过了软件, 在加电后, 无一例外都需要等待1-2秒后才能正常工作. 由于Windows DDK中的NE2000驱动源程序同样等待了2秒钟, 在很长一段时间我都认为这种愚蠢等待的代码是天经地义的.
在一年前我甚至还跟一个测试DM9003的说, 尽管这个芯片有各种其它问题, 但是等待2秒后才能正常工作不算它的问题.
PA6488集成了MAC, 在PA648C视频压缩模块板上我们用了一个单独的PHY芯片.
上周我注意到syslog的调试信息PHY linked总是能收到. 这样我就能在中断处理程序中马上开始其它网络工作如DHCP, 而不用再漫无目的死等2秒钟了.
在过去的AR1688开发中, 绝大多数的网络改进都同时更新回了PA1688. 不过这次PA6488结构上太不同了, 以至于我无法再改回去.
没有在RTL8019AS上使用93C46导致了PHY的连接信息无法检测到. 而在AR168MK VoIP模块使用的KSZ8842上,
因为没有使用中断处理程序, 由每隔1秒的定时器检测出来的PHY连接状态也不会让总体等待时间有效下降.
由于PA1688和AR1688都有DSP处理语音, 在控制器方面, 网络处理就是它最重要的工作了, 我们因此没有使用中断处理网络工作. 而在PA6488上, 最繁忙工作的是进行视频处理, 因此我们就把全部网络任务集中在了中断处理程序中.
2015年3月10日更新
在2012年的时候我把PA6488网络工作从中断中改到了主循环中, 希望能够提高cache的性能. 检测网络连接状态同样改到了主循环, 这样我可以尽快开始DHCP.
这个聪明的主意其实也能用到KSZ8842上,不过不知道什么原因我当时没有这么去做.
PA3288方案中使用的ENC28J60网络芯片是我编写软件的第5个MAC. 当我完成让它跟PA6488的MAC以同样方式工作后,
我突然意识到我能把这个也用到KSZ8842上. 这样在6年多以后, 我把2秒的等待从KSZ8842的初始化过程中去掉了.
其结果是0.63.026的AR168P网络电话和AR168MT网络语音VoIP模块测试软件.
|
