windowCE_BSP开发

BSP开发目录板级支持包（BSP）简介BSP的结构开发BSP板级支持包（BSP）简介BSP是板级支持包，是介于主板硬件和操作系统之间的一层，应该说是属于操作系统的一部分,主要目的是为了支持操作系统，使之能够更好的运行于硬件主板。BSP与开发板一一对应•它所对应的是某块具体的开发板/产品板,而不是某款CPU,也不是某类CPU体系结构。BSP是相对于操作系统而言的•不同的操作系统对应于不同定义形式的BSP,例如VxWorks的BSP和Linux的BSP相对于某一CPU来说尽管实现的功能一样，可是写法和接口定义是完全不同的，所以写BSP一定要按照该系统BSP的定义形式来写。BSP的编程过程大多数是在某一个成型的BSP模板上进行修改，这样才能与上层OS保持正确的接口，良好的支持上层OS。板级支持包（BSP）简介BSP的主要功能系统启动时，完成对硬件的初始化。•例如，对系统内存、寄存器、以及设备的中断进行设置。为驱动程序提供访问硬件的手段。BSP的结构BSP主要由4部分组成：OEM抽象层、引导程序、设备驱动程序和配置文件。OEM抽象层（OAL）OAL:OEM抽象层位于WindowsCE系统内核和目标板硬件之间，负责操作系统和目标板的通信。由引导程序调用，随后进行目标板的初始化工作，包括中断服务，实时时钟，内部计时器，调试部件，中断使能等等。OAL的代码在物理上是内核的一部分，经编译链接，OAL成为内核的一部分。由硬件OEM厂商提供。引导程序(BootLoader)引导程序(BootLoader)是在硬件开发板上执行的一段代码。主要功能初始化硬件加载操作系统映像到内存跳转到操作系统代码去执行EBoot:BootLoader通过以太网从工作站下载操作系统映像到目标机，然后把映像放到内存里执行，称之为EBoot(EthernetBoot的简称)。配置文件配置文件是一些包含配置信息的文本文件。BSP中的配置文件包括文件.BIB,.DB,.REG,.DAT：这些文件告诉MakeImage工具如何生成操作系统映像。Sources,DIRs：告诉构建系统如何构建代码。CEC：BSP可与PlatformBuilder集成。设备驱动程序设备驱动程序也是BSP的一个重要组成部分，支持相关外围设备以及动态安装的设备。对于某个特定的BSP来说，BSP当中应该包含在这块开发板上的所有的外设驱动程序。通过BSP包含的设备驱动程序操作系统能够发挥此开发板的最大效能。创建BSP的两种方法编写全新的BSP需要编写所有的部分包括OEM抽象层,驱动,引导程序大约消耗20人/月工作量改写现有的BSP对与目标板具有相似硬件组成的BSP的基础上进行某些改写，使其适用与目标板，这是最简单的方式。BSP向导下面是创建基于WindowsCE的BSP的一般步骤，典型的情况下会产生一个.cecw文件Platform-BSPWizardBSP开发流程如果操作系统映象可以直接引导，引导程序不是必须的但通常使用一个引导程序，以便日后的扩充。另外也可以用于支持制造过程中的下载测试引导程序的重要性在于可以支持开发过程中的运行时映象加载功能，也就是说在系统运行过程中，动态加载需要调试的模块引导程序(可选)引导程序的功能初始化目标设备内存和中断控制器设置时钟和内存管理单元直接引导现存的flash或RAM映象下载之前清空RAM内存读写测试下载WindowsCE映象到RAM或flash:并口网卡引导程序的加载引导菜单引导程序的开发实现OEM的应用程序接口（API）.连接Microsoft提供的库引导程序的任务黑体字标识的函数需要由OEM厂商来实现.控制流图C:\WINCE420\PUBLIC\COMMON\OAK\DRIVERS\ETHDBG\BLCOMMON引导程序–StartUp函数硬件复位和运行时复位需要执行的第一条指令设置为超级用户模式执行必须的硬件初始化:CPU内存控制器系统时钟串口缓存快表(TLBs)根据使用的CPU修改Startup.s引导程序--EbootMainEbootMain是C代码运行的入口调用BLCOMMON库BLCOMMON库源文件在Blcommon.c文件中，路径为%_WINCEROOT%\Public\Common\Oak\Drivers\Ethdbgdirectory引导程序–OEMDebugInit用来初始化串行口，作为调试输出OEMDebugInit初始化完成后,一个WindowsCE的标记会出现，表示这个接口可以使用了.引导程序--OEMPlatformInit各种OEM硬件平台初始化函数，包括时钟,PCI接口,或者NIC接口.NIC接口用于下载映象，另外服务于后面一些函数.引导程序--OEMPreDownload在加载一个运行时映象时首先被BLCOMMON调用.查找硬件设备的IP地址，并与宿主机相连如果出错返回-1引导程序--OEMLaunchOEMLaunch是引导程序的最后一个需要运行的函数.负责跳转的到需要运行的映象.跳转到由dwLaunchAddr指定的第一条指令，这条指令在运行时映象的启动函数里.OAL开发类似于引导程序的开发可以重用引导部分的代码OAL架构内核开发黑体显示的函数需要由OEM厂商来实现内核工作流KITL这样的设计可以很容易加入任何调试服务功能把通信协议和与之直接通信的硬件层分离开来减少用户在创建硬件独立层的工作量在系统映象中包含对KITL的支持1.CPU加电，跳转到复位向量2.[可选]引导程序从Startup()开始执行3.执行OAL中的Startup()4.KernelStart()[KernelInitialize()Forx86]5.Kernel调用OAL中的OEMInit()6.完成内核初始化7.内核加载Filesys.exe8.FileSys初始化注册表9.内核加载在HKEY_LOCAL_MACHINE\Init中列出的应用程序启动流程驱动程序开发参见前面的课程.利用BSPWizard可以添加到BSP中举例:分析MotorolaDragonBallBSP我们已经学习过什么?我们系统、完整地学习了WindowsCE开发流程.从设备制造商得到硬件和BSP需要设计硬件?设计实现你的硬件为硬件设计BSP需要定制平台?从设备制造商处得到平台和SDK定制你的WinCE平台导出你的SDK编码、测试发布产品WindowsCE测试工具包(CETK)Tux“server”Kato日志引擎设备驱动加载以及TUX扩展(DDLX)常规TUX测试综述CETK结构ClientSide.exeTuxTestDLLTuxTestDLLTuxTestDLLsKato.dllCETEST.EXEDesktopWindowsCEDeviceTUX.EXEDevice.EXETUXTestDLLDDLXMicrosoft提供了自动测试体系结构Client/Server结构支持远端测试通过“Tux”加载自动测试实际的测试是以DLLs的形式通过TUX加载到系统中通用日志引擎“Kato”DLLexposesCandC++APIforloggingtotheserverCETKServer利用TUX启动特定的测试保存日志以及产生报告运行于桌面系统以便进行远程测试WindowsCE测试工具包(CETK)TUXServerTUX.EXE监控TUX测试DLLs的程序实际的测试是以DLL的形式进行的通过TUX.EXE加载测试DLL由远端用户界面应用程序发起运行桌面系统上的CETEST.EXE也可以在设备上独立运行KATO日志引擎DLL：提供API，以便将测试结果保存成日志C++类库C函数从TUX测试抽象出日志机制本地文件远端连接设备驱动加载以及TUX扩展(DDLX)允许测试DLL加载到设备管理进程空间允许对APIs和功能的测试仅仅对设备管理模块可用设备管理模块直接向驱动提供APIs驱动可以直接为其他驱动提供服务常规的TUX测试TUXSKEL微软提供的TUX测试构架作为一个最初的“模板”用来创建常规TUX测试IDENewProjectWizard产生一个基于TUXSKEL结构的常规TUX测试比手工复制和修改TUXSKEL要简单