一个小问题的致命后果

最近在做openvg驱动方面的事情&＃xff0c;由于原有的驱动和应用都是基于linux操作系统的&＃xff0c;我需要把这个移植到我们的平台上面&＃xff08;我们的平台是运行在我们写的操作系统上面&＃xff09;。移植大概花了一周时间&＃xff0c;调试大概花了一周时间&＃xff0c;没有起色。

于是请求一个同事帮忙先把linux驱动和应用跑起来&＃xff0c;结果发现硬件中断没有接入&＃xff0c;硬件组同事修改了版本之后&＃xff0c;中断搞定。这又花了一周时间。继续跑linux版本&＃xff0c;结果仍然没出任何结果。怎么办&＃xff1f;我做了个实验&＃xff0c;把硬件测试的程序转化为软件测试的例子&＃xff0c;证明硬件除了中断之外都没有问题。那问题究竟出在哪里呢&＃xff0c;仍然没有头绪。

没办法&＃xff0c;最后只好请求技术支持。对方公司的技术支持给我们想了很多办法&＃xff0c;开始效果不是很理想。忙活了一周之后&＃xff0c;技术支持人员终于瞧出了端倪&＃xff0c;认为我们的中断有问题。对方公司把测试硬件中断的程序给了我们硬件人员&＃xff0c;硬件人员一测试&＃xff0c;果然有问题。仔细询问&＃xff0c;原来硬件中断有是有&＃xff0c;但从来没有测试过。

2个人&＃xff0c;4周时间&＃xff0c;就被一个小小的中断耽误了这么多时间和精力&＃xff0c;症结在哪里&＃xff1f;我总结了几个原因&＃xff1a;

1. 硬件设计人员太粗心&＃xff0c;没有测试硬件中断就断定硬件没有问题。而且硬件设计人员应该主动跟对方公司提出我们需要这个测试程序&＃xff0c;否则无法证明硬件没有问题。

2. 软件人员调试程序时候发现&＃xff0c; 一旦程序读中断寄存器&＃xff0c;程序就飞掉&＃xff0c;没有大胆怀疑硬件的问题&＃xff0c;而只是把范围定为于软件&＃xff0c;思维太局限。要大胆假设&＃xff0c;小心求证。

3. 对方公司粗心大意&＃xff0c;居然把这么关键的测试程序没有给我们的硬件人员。这是一个细节问题。