最近在一款ARM11的开发板上移植WinCE6.0，碰到了一些问题，也收获了一些经验。虽然ARM+WinCE的开发已经做过一段时间了，但开始用一款新的MCU时，总会碰到这样那样的问题。
首先是DataSheet，看惯了三星的文档，总觉得DataSheet就该那么写，条理清晰，方便查看。但不同厂家的文档有不同风格，起初调试时很不习惯Telechips的文档编排方式，要找到想看的内容得翻半天。这大概是先入为主的原因。芯片文档在开发过程中是很重要的资料，提高看文档的速度也就能提高开发的速度。所以在使用一款新MCU时，尽量放下先前的包袱，甚至经验，以快速适应该芯片的风格。事实证明，后来花一个多小时快速浏览了整篇DataSheet后，再去找相关的内容就快多了，大大提高了工作效率。磨刀不误砍柴工，有些时间是必须花的，而且也不会白花。
熟悉完DataSheet后，接下来就要看BSP了。相对于DataSheet，BSP的目录组织比较规范，一般都遵循PQOAL的标准。这里主要看一下细节上的差异，如Telechips的BSP中，将对硬件操作的部分封装在Src\LIB\SOC的目录下，而这个目录正是BSP移植过程中的一个重要根据地，绝大多数的修改都在该目录下进行。蛇打七寸，牛牵鼻头，抓住关键点，接下来就可以动手了。
以前曾简单介绍过WinCE6.0的移植步骤，WinCE的功能模块一般是按Bootloader、OAL、LCD驱动、外设驱动的顺序，MCU的功能模块一般按GPIO、UART、IIC、SPI等的顺序，总之是按时间先后，由简单到复杂。目前手上拿到的BSP，已经可以让WinCE6.0跑起来，WinCE的功能模块的调试可以直接进入外设驱动部分，而对应MCU的功能模块可以选择GPIO或者UART。
应项目需求，需要调试的有GPS、HDMI和CMMB。这里以GPS和HDMI的调试过程为例简单总结一下。我觉得这两个是典型，可以分别代表两类设备，GPS相对简单，硬件原理也很清楚，而HDMI是从没玩过的高级货，好些东西得现Google。
先说GPS的调试，驱动主要有两个工作要做，一个是GPS模块的供电由一个GPIO来控制，另外一个是调试与GPS模块连接的UART。GPIO的控制比较简单，大家的用法也一样，有功能寄存器、控制寄存器、方向寄存器和数据寄存器，配置完成后就可以控制相应的IO了。实现完这个简单的控制驱动后，先用万用表测一下相应的引脚，是否可以正常控制，能否让GPS模块工作起来。在实际调试过程中，发现MCU端的IO可以控制，但GPS模块并没有能正常工作，后来经硬件工程师帮忙查看，发现是该IO与GPS模块之间少焊了一个磁珠，事实上后来调试时发现很多小器件都没有焊，不过有晓峰支持，这些问题并没有耽误太多时间。解决了这个问题后，再用示波器测GPS模块的TXD引脚，果然有输出，不过电平不对，被拉低了。经晓峰排查，是MCU把这个引脚拉低了，应该是软件问题。到这里，硬件的问题基本解决了，看起来简单，但很重要。软件依赖于硬件，硬件不通，软件再怎么调也是无济于事的。所以，对于硬件原理比较清楚的接口，最好先从硬件处下手，排查可能由于原理、焊接等造成的意外，然后再调试软件。否则，本末倒置会严重影响调试效率和心情。回过头去看BSP有关串口的驱动，带着GPS模块TXD被拉低的问题去看，很快就能定位到问题了，原来现有BSP中没有对该串口做正确配置，仍然工作在IO的模式下，从而将GPS的TXD拉低。改完后，GPS的TXD的输出就正常了。又前进一步！接下来又碰到新问题。Telechips的串口使用方式与先前用的MCU都不一样，它分为PORT和CH两部分，6个PORT和6个CH。不同的PORT可以对应的不同的CH上，可任意动态映射。第一次接触这种使用方式，有点捉摸不透。翻来覆去看文档，找动态映射的规则，看了好久，恍然大悟。PORT是UART的硬件信号端口，CH是UART的控制寄存器。根据该规则，修改驱动和注册表，再试一下，GPS的信息就乖乖的打印出来了。至此，GPS模块基本调通，共花了半天时间，比预想的快一些，我想调试步骤恰当是主要原因，否则，很有可能在这简单的问题上折腾很久，还严重影响心情。所以对于这个种硬件接口清楚的，最好先调试硬件，排查硬件的意外问题后，再调试软件，不能本末倒置。
HDMI是什么东东，以前真不知道，现在百度百科里查一下。对于调试这类不知其所以然的设备，要从硬件下手不太现实。所以，先研究一下驱动和应用的程序结构，把驱动、应用编译好，放在板子上面跑去，看看到底是什么样的，运气好也许什么都不用改，直接就通了。呵呵，敢情调试就是碰运气？事实证明，运气没那么好，不改是不能正常工作的。怎么改，改哪里，这个问题就比较关键了。硬件不了解，工作不正常，唯一能用的就是串口调试信息，串口打印信息中，有一个明显的提示，HDMI启用失败，这是非常关键的线索，也是唯一可用的线索。顺着这个线索往前查，步步为营，最终确定这个问题出在IIC的配置上。再看串口的其他调试信息，也豁然开朗了，读了一堆的0xFF，肯定是有问题了。修改完代码，再试，竟然就有输出了，敢情运气也不是那么坏。不过，颜色有些偏差，有点花屏。虽然改动不大，但到这一步，还是小有进展。接下来就需要排查花屏的原因。经大家分析，怀疑可能是线的问题、软件的问题或者是匹配的问题，基本上是一种怀疑一切的态度。只有液晶显示屏已经在电脑上测试过，没有问题。所有的嫌疑犯都需要一个一个审查。找了一个别的号称支持HDMI的设备想检测一下线有没有问题，捣鼓了半天，似乎它根本就不支持HDMI输出，放弃。后来找了一个SONY的DV，效果相当好，确定不是线的问题。那很有可能就是代码的问题。将同样的代码编译到原厂开发板上跑了一下，效果也很好，但原厂的板子是用的普通的HDMI接口，而自己的是“Mini HDMI”（都这么叫，但似乎官方并没有这个说法），经张工出马确认，发现是把“Mini HDMI”的线序搞错了，飞线一把再试，完美！依然改动不大，但这调试的方法很关键，至少得找到一个下手的地方。
综合以上说的两种情况，可以归结为两头入手往中间靠，哪头好搞先搞哪头。写了这么多，记流水账似的，但有时候很多事情真的需要像流水一样，顺势而为才能游刃有余。对于WinCE的调试，抓住一些基本的调试方法，按部就班的调试总会有收获，如果方法不对，努力得越多越郁闷。最后贴上HDMI的效果图，M8拍的。
