Marvell8688模块调试

      这周终于能确认硬件连接Marvell8688没有问题了。之前一直出现CMD5指令超时的情况。当时换Atheros6002的模块也超时。因为当时是自己手工飞线焊的，所以也无法十分肯定是硬件问题还是飞线或软件的问题。后来换了一块WIFI模块板后CMD5指令通讯成功。于是终于松了口气，确认软件没有问题了。于是找硬件同事查WIFI的DEMO板故障，最后发现是有两个电阻没有贴上去。真是雷人得很，不过想想也很正常。因为很多时候，硬件设计的时候都会设计一些预留器件，实际上却不贴，是为了适应各种应用场合的需要。但这也埋下了很多隐患。这个时候，软件工程师的硬件测试水平就显得格外重要。因为只有有经验的软件工程师才能通过必要的硬件测试，得出是否是硬件故障导致软件问题的结论。如果软件工程师无法确定是硬件的问题，还是软件的问题，那么他会陷入很尴尬和被动的境地。硬件工程师一般不会承认自己的电路有问题的，呵呵。

      当硬件工程师交给我修复后的板子后，我测试SDIO的CMD引脚，发现CMD5指令的下发波形正确，但是后面就一直是高电平。没有回应信号。开始怀疑硬件还是有问题。后来联想到前一个模块板因为供电电压不是很规范，必须每次要物理断开模块一次就可以通信成功。于是我又找硬件同事帮我把WIFI模块的RESET脚接上，然后用GPIO对该脚进行复位操作。这个时候再发送CMD5指令，从示波器中可以看到一个完整的CMD5发送和相应指令波形。这个时候已经证明我的SDIO模块可以正常通信了。下周开始就要调后面的关键性指令CMD52、CMD53了。

      另外说个小插曲：高通6085平台下的源文件大约有1万多个（行数就无法统计了）。如果不幸修改了一个很多地方都被引用的头文件，那么编译一次需要的时间及其长。对于初期测试性调试很不利。一般一个工程重新编译加链接，需要两个半小时。大家可以想象一下，你只是加了一行打印信息想看看某个信息，就得等待1个多小时的编译过程，这是多么的可怕。也许你一天工作12小时，也就是加了5、6条打印语句。后来采用了一个分布式编译工具之后，整个工程的编译、链接过程立刻缩短至半个小时左右。一般情况下的编译、链接花费一刻钟。这样极大的提高了工作效率。不过分布式编译只对编译过程有效，对链接过程没有太大效果，不过已经很不错了。