一个小问题的致命后果

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

 

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

 

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

 

2个人，4周时间，就被一个小小的中断耽误了这么多时间和精力，症结在哪里？我总结了几个原因：

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

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

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