wince 移植

最近在一款ARM11 的开发板上移植WinCE6.0 ,碰到了一些问题,也收获了一些经验。虽然ARM+WinCE 的开发已经做过一段时间了,但开始用一款新的MCU 时,总会碰到这样那样的问题。

首先是DataSheet,看惯了三星的文档,总觉得DataSheet就该那么写,条理清晰,方便查看。但不同厂家的文档有不同风格,起初调试时很不习惯Telechips的文档编排方式,要找到想看的内容得翻半天。这大概是先入为主的原因。芯片文档在开发过程中是很重要的资料,提高看文档的速度也就能提高开发的速度。所以在使用一款新MCU时,尽量放下先前的包袱,甚至经验,以快速适应该芯片的风格。事实证明,后来花一个多小时快速浏览了整篇DataSheet后,再去找相关的内容就快多了,大大提高了工作效率。磨刀不误砍柴工,有些时间是必须花的,而且也不会白花。

熟悉完DataSheet后,接下来就要看BSP了。相对于DataSheetBSP的目录组织比较规范,一般都遵循PQOAL的标准。这里主要看一下细节上的差异,如TelechipsBSP中,将对硬件操作的部分封装在Src\LIB\SOC的目录下,而这个目录正是BSP移植过程中的一个重要根据地,绝大多数的修改都在该目录下进行。蛇打七寸,牛牵鼻头,抓住关键点,接下来就可以动手了。

以前曾简单介绍过WinCE6.0的移植步骤,WinCE的功能模块一般是按BootloaderOALLCD驱动、外设驱动的顺序,MCU的功能模块一般按GPIOUARTIICSPI等的顺序,总之是按时间先后,由简单到复杂。目前手上拿到的BSP,已经可以让WinCE6.0跑起来,WinCE的功能模块的调试可以直接进入外设驱动部分,而对应MCU的功能模块可以选择GPIO或者UART

应项目需求,需要调试的有GPSHDMICMMB。这里以GPSHDMI的调试过程为例简单总结一下。我觉得这两个是典型,可以分别代表两类设备,GPS相对简单,硬件原理也很清楚,而HDMI是从没玩过的高级货,好些东西得现Google

先说GPS的调试,驱动主要有两个工作要做,一个是GPS模块的供电由一个GPIO来控制,另外一个是调试与GPS模块连接的UARTGPIO的控制比较简单,大家的用法也一样,有功能寄存器、控制寄存器、方向寄存器和数据寄存器,配置完成后就可以控制相应的IO了。实现完这个简单的控制驱动后,先用万用表测一下相应的引脚,是否可以正常控制,能否让GPS模块工作起来。在实际调试过程中,发现MCU端的IO可以控制,但GPS模块并没有能正常工作,后来经硬件工程师帮忙查看,发现是该IOGPS模块之间少焊了一个磁珠,事实上后来调试时发现很多小器件都没有焊,不过有晓峰支持,这些问题并没有耽误太多时间。解决了这个问题后,再用示波器测GPS模块的TXD引脚,果然有输出,不过电平不对,被拉低了。经晓峰排查,是MCU把这个引脚拉低了,应该是软件问题。到这里,硬件的问题基本解决了,看起来简单,但很重要。软件依赖于硬件,硬件不通,软件再怎么调也是无济于事的。所以,对于硬件原理比较清楚的接口,最好先从硬件处下手,排查可能由于原理、焊接等造成的意外,然后再调试软件。否则,本末倒置会严重影响调试效率和心情。回过头去看BSP有关串口的驱动,带着GPS模块TXD被拉低的问题去看,很快就能定位到问题了,原来现有BSP中没有对该串口做正确配置,仍然工作在IO的模式下,从而将GPSTXD拉低。改完后,GPSTXD的输出就正常了。又前进一步!接下来又碰到新问题。Telechips的串口使用方式与先前用的MCU都不一样,它分为PORTCH两部分,6PORT6CH。不同的PORT可以对应的不同的CH上,可任意动态映射。第一次接触这种使用方式,有点捉摸不透。翻来覆去看文档,找动态映射的规则,看了好久,恍然大悟。PORTUART的硬件信号端口,CHUART的控制寄存器。根据该规则,修改驱动和注册表,再试一下,GPS的信息就乖乖的打印出来了。至此,GPS模块基本调通,共花了半天时间,比预想的快一些,我想调试步骤恰当是主要原因,否则,很有可能在这简单的问题上折腾很久,还严重影响心情。所以对于这个种硬件接口清楚的,最好先调试硬件,排查硬件的意外问题后,再调试软件,不能本末倒置。

HDMI是什么东东,以前真不知道,现在百度百科里查一下。对于调试这类不知其所以然的设备,要从硬件下手不太现实。所以,先研究一下驱动和应用的程序结构,把驱动、应用编译好,放在板子上面跑去,看看到底是什么样的,运气好也许什么都不用改,直接就通了。呵呵,敢情调试就是碰运气?事实证明,运气没那么好,不改是不能正常工作的。怎么改,改哪里,这个问题就比较关键了。硬件不了解,工作不正常,唯一能用的就是串口调试信息,串口打印信息中,有一个明显的提示,HDMI启用失败,这是非常关键的线索,也是唯一可用的线索。顺着这个线索往前查,步步为营,最终确定这个问题出在IIC的配置上。再看串口的其他调试信息,也豁然开朗了,读了一堆的0xFF,肯定是有问题了。修改完代码,再试,竟然就有输出了,敢情运气也不是那么坏。不过,颜色有些偏差,有点花屏。虽然改动不大,但到这一步,还是小有进展。接下来就需要排查花屏的原因。经大家分析,怀疑可能是线的问题、软件的问题或者是匹配的问题,基本上是一种怀疑一切的态度。只有液晶显示屏已经在电脑上测试过,没有问题。所有的嫌疑犯都需要一个一个审查。找了一个别的号称支持HDMI的设备想检测一下线有没有问题,捣鼓了半天,似乎它根本就不支持HDMI输出,放弃。后来找了一个SONYDV,效果相当好,确定不是线的问题。那很有可能就是代码的问题。将同样的代码编译到原厂开发板上跑了一下,效果也很好,但原厂的板子是用的普通的HDMI接口,而自己的是“Mini HDMI”(都这么叫,但似乎官方并没有这个说法),经张工出马确认,发现是把“Mini HDMI”的线序搞错了,飞线一把再试,完美!依然改动不大,但这调试的方法很关键,至少得找到一个下手的地方。

    综合以上说的两种情况,可以归结为两头入手往中间靠,哪头好搞先搞哪头。写了这么多,记流水账似的,但有时候很多事情真的需要像流水一样,顺势而为才能游刃有余。对于 WinCE 的调试,抓住一些基本的调试方法,按部就班的调试总会有收获,如果方法不对,努力得越多越郁闷。

你可能感兴趣的:(wince 移植)