一个小问题的致命后果
2010-08-10 15:39
134 查看
最近在做openvg驱动方面的事情,由于原有的驱动和应用都是基于linux操作系统的,我需要把这个移植到我们的平台上面(我们的平台是运行在我们写的操作系统上面)。移植大概花了一周时间,调试大概花了一周时间,没有起色。
于是请求一个同事帮忙先把linux驱动和应用跑起来,结果发现硬件中断没有接入,硬件组同事修改了版本之后,中断搞定。这又花了一周时间。继续跑linux版本,结果仍然没出任何结果。怎么办?我做了个实验,把硬件测试的程序转化为软件测试的例子,证明硬件除了中断之外都没有问题。那问题究竟出在哪里呢,仍然没有头绪。
没办法,最后只好请求技术支持。对方公司的技术支持给我们想了很多办法,开始效果不是很理想。忙活了一周之后,技术支持人员终于瞧出了端倪,认为我们的中断有问题。对方公司把测试硬件中断的程序给了我们硬件人员,硬件人员一测试,果然有问题。仔细询问,原来硬件中断有是有,但从来没有测试过。
2个人,4周时间,就被一个小小的中断耽误了这么多时间和精力,症结在哪里?我总结了几个原因:
1. 硬件设计人员太粗心,没有测试硬件中断就断定硬件没有问题。而且硬件设计人员应该主动跟对方公司提出我们需要这个测试程序,否则无法证明硬件没有问题。
2. 软件人员调试程序时候发现, 一旦程序读中断寄存器,程序就飞掉,没有大胆怀疑硬件的问题,而只是把范围定为于软件,思维太局限。要大胆假设,小心求证。
3. 对方公司粗心大意,居然把这么关键的测试程序没有给我们的硬件人员。这是一个细节问题。
于是请求一个同事帮忙先把linux驱动和应用跑起来,结果发现硬件中断没有接入,硬件组同事修改了版本之后,中断搞定。这又花了一周时间。继续跑linux版本,结果仍然没出任何结果。怎么办?我做了个实验,把硬件测试的程序转化为软件测试的例子,证明硬件除了中断之外都没有问题。那问题究竟出在哪里呢,仍然没有头绪。
没办法,最后只好请求技术支持。对方公司的技术支持给我们想了很多办法,开始效果不是很理想。忙活了一周之后,技术支持人员终于瞧出了端倪,认为我们的中断有问题。对方公司把测试硬件中断的程序给了我们硬件人员,硬件人员一测试,果然有问题。仔细询问,原来硬件中断有是有,但从来没有测试过。
2个人,4周时间,就被一个小小的中断耽误了这么多时间和精力,症结在哪里?我总结了几个原因:
1. 硬件设计人员太粗心,没有测试硬件中断就断定硬件没有问题。而且硬件设计人员应该主动跟对方公司提出我们需要这个测试程序,否则无法证明硬件没有问题。
2. 软件人员调试程序时候发现, 一旦程序读中断寄存器,程序就飞掉,没有大胆怀疑硬件的问题,而只是把范围定为于软件,思维太局限。要大胆假设,小心求证。
3. 对方公司粗心大意,居然把这么关键的测试程序没有给我们的硬件人员。这是一个细节问题。
相关文章推荐
- 由一个浮点数问题引发的致命问题
- 今天调试程序遇到了一个致命问题语法错误操作符丢失
- 初学ASP编程易犯的一个致命程序问题及解决办
- 一个menuconfig 配置引起的致命问题——一生难忘!
- 一个伪内存泄漏问题
- git(osx)上的一个git commit无法正确提交的问题
- 一个Service问题的求解历程
- 在做JAVA和UCENTER整合登陆时一个要注意的问题
- 对异常处理中的一个问题的思考(出现异常,程序仍能继续运行)
- 3389远程连接问题的一个解决办法
- java读取UTF-8的txt文件发现开头的一个字符问题
- 一个二元二次有理式最值问题
- const和volatile修饰同一个变量的问题
- 一个奇怪的崩溃问题
- Linux+Windows双系统删除其中一个的问题(引导程序问题)
- 今天搞懂了一个由byte 转为unsigned byte 的问题
- C语言中的一个关于基本类型的输出问题
- android 异常问题 Scrollview中嵌套webview出现大面积空白(第二次打开同一个地址下面才出现空白)
- 遇到一个关于调用javascript语句不起作用的问题
- 调试使用了函数模块的程序时需要注意的一个小问题