|
- UID
- 824598
|
| 在我担任软硬件工程师的生涯中，曾被指派过一项任务是为一款多年前所做的设计决定导致其后的意外结果进行除错。当时我们采用的是执行于pSOS实时操作系统(RTOS)上的VMEBus系统。这种系统使用“光纤分布式数据介面”(FDDI)网络架构，加上其独特的系统配置，我们认为如果能在系统上执行某种内建自测试(BIT)应该是个不错的办法。 9年后，我们合作的CPU板制造商决定为其产品系列进行改款。忽然间，我们原有的FDDI BIT测试开始出现问题了。由于我记得这家供应商实际上供应这种BIT(内建于电路板卡内的硬件)，因而我对这部份抱持强烈的怀疑。 我们公司自行编写的BIT测试执行程式用于启动测试，等过了一段时间后，再读取状态暂存器以确认是否通过测试。其实我自己也已经使用VMEBus分析器watchful eye测试过了。我一开始进行测试就发现错误，随即读取状态暂存器后就看到测试通过了！ 但在这个节骨眼上，我察觉到事情有点不太对劲。我将VMEBus分析器改变为非同步模式并执行BIT，同时交换新旧CPU板。一开始，我注意到新的CPU执行一个VMEBus读取的时间大约只需要旧CPU读取时间的60%。然后，我又发现BIT测试执行程序仍不断地读状态暂存器。 最后我终于完成软件部份并证实了原先的怀疑： BIT测试执行程序正执行一个读取回路，固定次数地不断读取状态暂存器，然后再与测试通过(pass)的状态进行比较。由于新的CPU速度更快，它在FDDI卡完成其BIT测试之前就已经完成了n次的读取次数。 我想你可能会说这不就是个“延迟编程”(lazy programming)的问题吗？反正你还是得读取暂存器啊！那么为什么不干脆直接读取“n”次呢？其实，还有一个更好的办法就是“等待”(WAIT)，利用pSOS内建测试的时间或什至递减CPU暂存器：这是一种相当可靠的技术，因为时间间隔是基于CPU时脉速度，而非接口速度。不过，真的这么做的话，千万也别忘了建档(Document)！那么以后像我这样的可怜虫就不必非得连续工作好几个礼拜才找到问题的症结了！ |
|
