I've been asked why we used the name "Yamazaki" as a codename for CE 6.0 - There's some history behind the naming of Windows CE versions, here's the short version...

Before the Windows CE product was released we had an internal set of tools known as the Oem Adaptation Kit also known as the OAK - an OAK of course is a type of tree.

The initial releases of Windows CE were therefore named after trees, as follows.

• Windows CE 1.0 - Alder (Nov 1996)
• Windows CE 2.0 - Birch (Nov 1997)
• Windows CE 3.0 - Cedar (Apr 2000)

Interestingly, there was a second team within the Windows CE group that worked on the tools, I guess you could consider tools to be something that makes a job easier, or cuts the job down to size - therefore the tools releases were named after things that cut down trees  - as follows...

• Windows CE 1.0 - Alder - Tools: Axe
• Windows CE 2.0 - Birch - Tools: Buzzsaw
• Windows CE 3.0 - Cedar - Tools: Chainsaw

For Windows CE 4.0 the original plan was to call the O/S DougFir (DouglasFir), the thing that cuts down DougFir trees was going to be Dozer (BullDozer) - interestingly, at Windows CE 4.0 the o/s team and tools teams merged together to form a new, combined team - the codenames for the operating system and tools also changed at this time from trees/tools to <drumroll>Whiskeys</drumroll> - so the codenames for Windows CE 4.0 onwards are as follows.

• Windows CE 4.0 - Talisker (Jan 2002)
• Windows CE 4.1 - Jameson (Jun 2002)
• Windows CE 4.2 - McKendric (Apr 2003)
• Windows CE 5.0 - Macallan (Aug 2004)
  • Windows CE 5.0 Network Device Feature Pack - Tomatin (Apr 2006)
• Windows CE 6.0 - Yamazaki (Sep 2006)

Don

*originally posted on Mike Hall's Weblog

以上内容引用自：http://blogs.msdn.com/testembedded/archive/2006/09/29/777063.aspx

从CE 4.0开始的都是些威士忌酒名：

Talisker 产地：爱尔兰

Jameson 产地：苏格兰

McKendric  产地：美国

Macallan  产地：苏格兰

Yamazaki 产地：日本

现在，微软公司正在日以继夜地研发新一代的Windows Mobile 7系统。据说，它将会给微软自己的移动设备操作系统带来的第一次“革命性”的改变。

绚丽多彩的Windows Mobile 7系统（点击查看大图）

　　最近，在微软公司的一份内部文档上，详细地介绍微软公司打算要在Mobile 7系统中引入“触摸(Touch)”和“动作(Gesture)”操控的计划。除此之外，在这份微软内部文档中，相关人士还用多达上百页的篇幅，详细阐述了关于Windows Mobile 7系统的各种设计和创意，以及微软公司是如何计划去改变我们与移动设备之间的交互方式的。

　　一、Windows Mobile 7将有哪些新的改进？

　　Windows Mobile 7将会显著地改变我们使用移动设备的方式。它将着重推荐消费者通过对设备的触摸，以及预先设定的手势动作，来操控自己的移动设备。很显然，微软公司从当下大红大紫的苹果iPhone手机中汲取了相关灵感，并打算“用其人之道，还制其人之身”。

　　Windows Mobile 7系统将会运用上触摸识别技术(Touch Gestures)。当然，具体形式和苹果iPhone手机非常的相似。你将能通过自己的指尖在屏幕上轻轻划动，方便地翻阅联系人名单、设置面板和各种各样的文件夹。微软公司在Windows Mobile 7上倾注了极大的心血，以便让用户能够更加方便地在不同功能或位置之间快速切换。比如说，微软新提供了一个滚动手柄功能，能够让用户以多种方式，快速地检索到自己想要查找的东西。

　　Windows Mobile 7系统将会为移动设备引进革命性的动作识别技术，而这一创新，是现在的苹果iPhone手机所不具备的。为了实现这一功能，它将不会使用某种复杂难解的物理定位装置。反而，Windows Mobile 7将创新地利用手机上的摄像头，来侦测设备当前的运动状态，并做出与之相应的、被预先设定好的系统反应。你将能够通过摇晃、旋转或其它方式，来方便地操控自己的手机，并完成相应的工作。当屏幕向下翻转达到一定角度的时候，Windows Mobile 7手机将能够知道，并做出相应的反应；当手机被放进用户的口袋或背包中时，它也能够知道。

　　Windows Mobile 7系统将拥有一款令人激动的锁定屏幕 —— 你可以用随意玩耍它，在它上面画画，摇晃它，或是以其他什么方式，将它搞的“一塌糊涂”。

　　Windows Mobile 7系统的视觉外观也将获得极大的改进。和苹果iPhone手机的清爽靓丽不同，这个全新的图形界面将更加类似于Windows Vista所拥有的、深色的未来派视觉效果。它将会提供图形的渐变、精细的光影效果，以及其它种种视觉改进，从而让它更吸引人的眼球。

　　 Windows Mobile 7将会拥有更加卓越的娱乐功能：它不但将拥有更加先进的多媒体播放器和和图片浏览程序，还将拥有一个专门的游戏模式。移动版的Internet Explorer网络浏览器将能够在一个符合最低限度要求的屏幕上全屏显示网页，并且它还提供了先进的“标签式”网页浏览功能。根据材料上的信息，你还将能够通过摇晃手机，在不同的标签页面之间进行切换。

　　Windows Mobile 7的键盘功能也得到了改进。但是，原本打算要在这套系统中提供一款像苹果iPhone手机那样的，完全接触式的键盘计划，被推迟到了下一个版本的Windows Mobile系统中去实现。

　　下面，就是我从这份微软内部文档中所摘录出的详细笔记。从中，你可以了解到有关于Windows Mobile 7系统的方方面面，有些部分可能略显粗糙，但另外一些部分却是堪称详尽。

　　二、新用户图形界面的目标

　　Windows Mobile 7系统所拥有的这套代号“Phosphur”和“Starburst”的全新图形界面，涵盖了许多方面的内容：触摸识别、动作识别、屏幕滚动和直接操控。

　　整体目标：对手指操控进行最优化 —— 要让系统的使用者无论在任何地方，都能够获得同等状况下最佳的触摸操控体验。

　　用户需求：简单、容易记忆和有趣;具有一致性、可预见性和趣味性;自然的运动、自然的动画显示和视觉效果的过渡;要增强移动设备的使用体验，而不是降低它。

　　设备适用性的目标：要能够适用于各种类型的硬件设备，包括只拥有按钮操控的硬件设备、同时拥有按钮操控和触摸屏的硬件设备，以及只拥有触摸屏的硬件设备。在这里，只拥有触摸屏的硬件设备被特别指定为 “苹果iPhone手机的竞争产品”。

　　用户使用体验方面的要求：要具有贯穿整个设备的，一致性的图形界面交互体验，但这种一致性不能被滥用。新的图形界面将不会强制参与到应用程序的运行当中，只是推荐这样做，从而保证与较早应用程序之间的兼容性。在新的图形界面中，将会提供一个专门的“游戏模式(Game Mode)”，该模式能够让系统中的电子游戏凌驾于整个图形界面的操控规范之上，从而让电子游戏能够提供比普通应用程序更加复杂的操控体验。

　　Windows Mobile 7将会在适当的情况下，向使用者提供视觉和听觉的反馈。比如说：指示出一份列表的顶部和底部，显示出屏幕上那些进行触摸操控的对象，以及当你的手指在屏幕上按压的时候，会在指尖周围显示出一个燃烧的光环。

　　Windows Mobile 7是专门为手指操控所设计的。微软公司的研究团队专门对用户手指尺寸进行了深入的研究。现在，他们决定以自己认为最合适的指尖尺寸(7.6平方毫米)为标准，对Windows Mobile 7进一步地优化。优化的终极目标是：让用户可以在单手持握移动设备时，只用大拇指，就能够自如地操控整个设备。

　　图形界面上的各种元素尺寸都能够被动态地设定，以让它们能够被更加容易地点击到。那些位于屏幕角落上的元素，诸如关闭按钮、滚动手柄、图标和标题栏，都将能够自动地放大，以方便用户的点击。

　　对指尖触摸操控的识别包括了：纵向或横向的屏幕滚动，访问不同的任务或菜单，点击或压住控制，展开对象，拖放操作，以及建立快捷方式。当指尖在屏幕上的移动速度加快时，设备将能够自动识别，以加快屏幕的滚动速度。

　　滚动条将会在触摸屏幕上完全消失;用手指在屏幕上压住不放，将会弹出右键菜单;当窗口切换或是缩小的时候，将可能会有相应的视觉和音响效果。

　　除此之外，微软也在考虑给Windows Mobile 7添加“多手指触摸操控(Multi-finger touch)”的功能，以方便用户用对图片或视频进行编辑。

　　三、动作识别(Motion Gestures)

　　除了各种各样的触摸操控之外，Windows Mobile 7系统还将具有先进的动作识别功能(Motion Gestures)。它能够通过手机上的摄像头，感知自己当前的运动状态，从而做出相应的反应。简而言之，你可以通过摇晃一下手机，选择播放下一首歌曲。

　　由于Windows Mobile 7是完全通过手机上的摄像头来侦测自己的运动状态变化的，这也就要求移动设备上的摄像头要时时开启，这显然会对设备的电池使用时间造成影响;但与此同时，由于这种实现方案完全不依赖于陀螺仪或加速计等物理设备，这也就意味着现有的Windows Mobile设备可以通过软件升级的方式，获得Windows Mobile 7系统的全部功能。

　　微软公司在这份内部文档中阐释到， Windows Mobile 7所识别的操控动作应当直观、方便、易于使用，并且同时它们也应当有趣，能够对用户的操控动作做出积极的反馈。这些能够被识别的操控动作，包括了移动设备被摇晃的次数、方向、力道，以及诸如此类的其它动作。

　　根据微软的这份内部资料透露，运行着Windows Mobile 7系统的移动设备，将能够通过动作识别技术完成以下工作：

　　1. 根据手机的倾斜角度，自动调整屏幕的显示方向。当你以与地面水平的方向拿着手机的时候，手机显示屏也将会自动调整为水平显示。

　　2. 当在手机上浏览图片的时候，用力向左或向右摇晃手机，就可以跳转到前一张或后一张图片。如果是前后摇晃手机，就可以让所有的图片在屏幕上散乱排列开来。当你在手机上播放音乐的时候，也是同样的。

Windows Mobile 7 中的个性的浏览

　　正如你所看见的那样，新的多媒体播放器十分注重与音乐相关的专辑图片和其他新酷的视觉效果。而从前突兀的电池时间和无线信号强度等指示图标，现在已被巧妙的隐藏在了屏幕的最底部，从而节省了宝贵的屏幕空间。

　　3. 当你在运行某个全屏显示的多媒体程序的时候，比如照片浏览程序，按住屏幕下方的方向键不放，前后晃动你的手机，就可以放大或者是缩小显示图片。

　　4. Windows Mobile 7中的网络浏览器也将具有动作识别功能。你将能通过晃动手机，在网络浏览器当中执行前进或后退操作。

Windows Mobile 7中网络浏览器的动作识别

　　值得注意的是，这张内部图片当中所展示的Windows Mobile 7网络浏览器，与现有版本相比有很大的不同。首先是Internet Explorer的外观获得了极大的改进，变得更加简洁、更加漂亮了。在整个界面上，只有一个地址栏和一个访问按钮，而它所显示出的网页是与桌面系统一样的完全版本。此外，新的移动浏览器还提供了先进的标签浏览功能，可以通过动作识别，在一系列不同网页的缩略图之间进行自由切换，这真是令人赞叹！

　　5. Windows Mobile 7系统还可以通过摄像头感知周围光线的明暗变化，从而做出相应的反应。比如说，当你将手机放入口袋或背包中时，Windows Mobile 7将会自动地关闭屏幕显示，甚至是自动地将手机铃声调大一点，或是开启振动模式。

　　四、唤醒WM7设备

　　你可以通过晃动手机，将它从休眠模式中唤醒：

晃动手机，就能唤醒休眠模式（点击查看大图）

　　下面的这张图片，详细地展示了运行着Windows Mobile 7系统的移动设备，从休眠状态到唤醒状态所经历的整个过程：

Windows Mobile 7系统的唤醒过程

　　正如你所看到的那样，在整个唤醒过程中，移动设备的屏幕经历了十分精致的渐变效果。

　　五、在锁定的屏幕上涂鸦

　　为了增添移动设备的使用乐趣，微软公司在新的Windows Mobile 7系统中提供了“屏幕涂鸦(Doodle)”功能。当设备的触摸屏幕处于锁定状态时，用户可以用手指在屏幕上画出各种图案。

屏幕涂鸦

　　你甚至可以将自己的涂鸦作品设定为系统的桌面背景：

涂鸦也能设为系统桌面

　　五、触摸控制

　　在Windows Mobile 7系统中，用户可以通过指尖的轻触，在各种功能之间自如地切换，滚动屏幕，或是浏览系统中的不同位置。

　　下面的这张图片，显示了在不同功能之间进行切换时，Windows Mobile 7屏幕上的相应显示效果：

不同功能间的切换（点击查看大图）

　　用户也可以通过指尖的滑动，快速浏览自己Outlook收件箱中的电子邮件：

快速浏览Outlook 电子邮件

　　在使用类似于Windows Live Maps的网络服务的时候，你也可以完全依靠指尖的触摸来操控地图的滚动或缩放：

　　当你用指尖点击屏幕上的按钮或图标的时候，Windows Mobile 7将会采用先进的智能锁定技术，判断出你想要点击的究竟是哪一个按钮。因此，既便是对于那些手脚不太灵便的用户来说，他们也能够轻易获得自己所需要的结果。

　　当你在使用屏幕上的虚拟键盘的时候，你所点击到的字母将会自动放大。但你高亮选中某段文本的时候，一个缩放/编辑框将会自动出现在它的上方，显示出你所选中的内容。当你在移动版IE浏览器中使用完整模式浏览网页的时候，如果点击选中某个包含有超链接的区域，这个区域将会自动被放大，以方便你选中自己所需要的链接。

Windows Mobile 7系统中的虚拟键盘

　　Windows Mobile 7系统将会提供强大的办公处理功能。请注意看上图中的Word移动版，它居然拥有Office 2007中才引进的全新Ribbon操控面板。而移动版的OneNote软件也将提供强大的手写输入功能。

　　当你在使用这些软件的时候，用指尖在屏幕上压住不放，就会激活并弹出相应的右键菜单：

右键菜单

　　要想在长长的列表中快速找到自己所想要的项目，你可以在键盘上点击相应对象的名字的第一个字母：

快速选择

　　此外，使用屏幕上所显示的滚动手柄，也能加快屏幕的滚动速度：

屏幕上的滚动手柄

　　除非必要，滚动条永远都不会在Windows Mobile 7的图形界面上出现。替代它的是电影胶片视图、标签页面或缩略图等多种更加绚丽的视觉效果。

来源：中电网 | 作者：杨振坤 甘朝晖 蒋旻

　　引言

　　近年来，嵌入式技术发展迅速，嵌入式系统在各行各业得到了广泛的应用。然而，由于嵌入式计算机的专用性，系统的硬件、软件结构千差万别，其输入设备也不再像通用计算机那样单一。

　　嵌入式计算机的输入设备一般有鼠标、键盘、触摸屏、按钮、旋钮等，而光电编码器（俗称“单键飞梭”）作为一种输入设备，由于其具有输入灵活，简单可靠等特点，因此特别适合应用在嵌入式仪器和手持式设备上，整个系统可以只用一个键作为输入。触摸屏由于其方便灵活、节省空间、界面直观等特点也备受青睐，但存在寿命短，长时间使用容易产生误差等缺点。如果用光电编码器辅助触摸屏作为输入设备，必将大大增强系统的可靠性，使得人机接口更加人性化。但由于光电编码器并不是WinCE的标准输入设备，因此其驱动程序在嵌入式操作系统Windows CE Platform Builder中并未给出。本文以三星公司S3C2410（ARM9芯片）为CPU的嵌入式系统开发板为平台，详细阐述了嵌入式操作系统WinCE下光电编码器驱动程序的设计方法，以供同行参考。

　　1 光电编码器的工作原理

　　光电编码器（Optical Encoder）俗称“单键飞梭”，其外观好像一个电位器，因其外部有一个可以左右旋转同时又可按下的旋钮，很多设备（如显示器、示波器等）用它作为人机交互接口。下面以美国Greyhill公司生产的光电编码器为例，介绍其工作原理及使用方法。光电编码器的内部电路如图1所示，其内部有1个发光二极管和 2个光敏三极管。当左右旋转旋钮时，中间的遮光板会随旋钮一起转动，光敏三极管就会被遮光板有次序地遮挡，A、B相就会输出图2所示的波形；当按下旋钮时，2、3两脚接通，其用法同一般按键。

图1 光电编码器的内部电路

图2 光电编码器的输出波形

　　当顺时针旋转时，光电编码器的A相相位会比B相超前半个周期；反之，A相会比B相滞后半个周期。通过检测A、B两相的相位就可以判断旋钮是顺时针还是逆时针旋转，通过记录A或B相变化的次数，就可以得出旋钮旋转的次数，通过检测2、3脚是否接通就可以判断旋钮是否按下。其具体的鉴相规则如下：

　　① A为上升沿，B＝0时，旋钮右旋；

　　② B为上升沿，A＝1时，旋钮右旋；

　　③ A为下降沿，B＝1时，旋钮右旋；

　　④ B为下降沿，A＝0时，旋钮右旋；

　　⑤ B为上升沿，A＝0时，旋钮左旋；

　　⑥ A为上升沿，B＝1时，旋钮左旋；

　　⑦ B为下降沿，A＝1时，旋钮左旋；

　　⑧ A为下降沿，B＝0时，旋钮左旋。

　　通过上述方法，可以很简单地判断旋钮的旋转方向。在判断时添加适当的延时程序，以消除抖动干扰。

　　2 WinCE提供的驱动模型

　　WinCE操作系统支持两种类型的驱动程序。一种为本地驱动程序，是把设备驱动程序作为独立的任务实现的，直接在顶层任务中实现硬件操作，因此都有明确和专一的目的。本地设备驱动程序适合于那些集成到Windows CE平台的设备，诸如键盘、触摸屏、音频等设备。另一种是具有定制接口的流接口驱动程序。它是一般类型的设备驱动程序。流接口驱动程序的形式为用户一级的动态链接库（DLL）文件，用来实现一组固定的函数称为“流接口函数”，这些流接口函数使得应用程序可以通过文件系统访问这些驱动程序。本文讨论的光电编码器就属于流接口设备。

　　2.1 流设备驱动加载过程

　　WinCE.NET系统运行时会启动负责流驱动的加载进程DEVICE.exe。DEVICE.exe进程对驱动的加载是通过装载注册表列举器（RegEnum.dll）实现的。在WinCE.NET中，所有设备的资源信息都由OAL负责记录在系统注册表中，RegEnum.dll一个一个扫描注册表项HEKY_LOCAL_MACHINE\Driver\BuiltIn下的子键，发现新设备就根据每个表项的内容进行硬件设备初始化。

　　2.2 中断与中断处理

　　如果一个驱动程序要处理一个中断，那么驱动程序需要首先使用CreateEvent函数建立一个事件，调用 InterruptInitialize函数将该事件与中断标识绑定。然后驱动程序中的IST就可以使用WaitForSingleObject函数来等待中断的发生。在一个硬件中断发生之后，操作系统进入异常处理程序，异常处理程序调用OAL的OEMInterruptHandler函数，该函数检测硬件并将中断标识返回给系统；系统得到该中断标识便会找到该中断标识对应的事件，并唤醒等待相应事件的线程(IST)，然后IST进行中断处理。处理完成之后，IST需要调用InterruptDone函数来告诉操作系统中断处理结束，操作系统再次调用OAL中的OEMInterruptDone函数，最后完成中断的处理。

图3为WinCE.NET中断处理的流程框图。

图3 WinCE.NET中断处理流程框图

　　3 光电编码器驱动程序的设计

　　3.1 光电编码器与S3C2410的硬件接口

　　光电编码器与S3C2410的接口电路如图4所示。光电编码器的A、B相为集电极开路输出，由于S3C2410的I/O口电平为3.3 V，所以将其通过电阻上拉到3.3 V后再分别接到CPU的EINT0和EINT1上；将P1直接接到3.3 V，P2通过电阻下拉到GND。当旋钮按下时，P2口输出为高电平，否则输出为低电平。

图4 光电编码器与S3C2410的接口电路

　　工作状态下，将EINT0、EINT1配置成上升沿和下降沿均触发的外部中断，将EINT2配置成上升沿触发的中断，旋钮按下时EINT2引脚产生上升沿触发中断。

　　3.2 外部中断初始化及中断服务程序的编写

　　首先必须完成CPU的I/O口和中断的初始化工作，然后再编写中断处理程序。具体分为4个步骤：

　　① 初始化I/O口。在Port_Init()函数中，将EINT0和EI

NT1初始化为上升沿和下降沿均触发的中断，将EINT2初始化为上升沿触发的中断。

　　② 添加中断号。在oalintr.h下添加光电编码器中断向量的宏定义。代码为

　　#define SYSINTR_OED(SYSINTR_FIRMWARE+20)

　　③ 添加中断的初始化、禁止、复位等函数,分别在OEMInterruptEnable()、OEMInterruptDisable()、OEMInterruptDone()等函数中加入相关代码。

　　④ 返回中断标识,由OEMInterruptHandler()函数返回中断标识（SYSINTR_OED）。

　　3.3 编写流接口驱动程序

　　Windows CE.net把中断处理分成两个部分：中断服务程序（ISR）和中断服务线程（IST）。ISR通常要求越短、越快越好，它的唯一任务就是返回中断标识。正由于ISR很小，只能做少量的处理，因此中断处理器就调用IST执行大多数的中断处理。中断服务线程（IST）在从 WaitForSingleObject()函数得到中断已经发生的信号前一直保持空闲；当接收到中断信号后，它就在本机设备驱动程序的PDD层调用子程序，这些程序反过来访问硬件以获得硬件的状态。IST使用InterruptInitialize()函数来注册自己，然后使用 WaitForSingleObject()函数等待中断信号。如果这时中断信号到来，则应将光电编码器的状态记录下来，保存在变量OED_Status 中。OED_Status＝1表示旋钮按下，OED_Status＝2表示旋钮逆时针旋转，OED_Status＝3表示旋钮顺时针旋转。

　　这里还有一种比较简单的鉴相规则，具体步骤是，当创建线程时读出EINT1的电平状态并保存在变量PreEINT1中，每次中断到来时首先判断 EINT2是否为高电平。如果为高电平，则说明按钮按下；如果EINT2为低电平，则判断EINT0电平是否与PreEINT1相同。如果相同，则说明旋钮逆时针旋转；反之，旋钮顺时针旋转，判断的流程如图5所示。

图5 光电编码器鉴相流程框图

　　Windows CE流接口驱动程序模型要求驱动程序开发者编写10个接口函数，针对光电编码器的驱动主要应完成设备初始化和数据读取2个函数的编写。Windows CE设备文件名前缀由3个大写字母组成，操作系统使用这3个字母来识别与流接口驱动程序相对应的设备。这里定义设备文件名前缀为“OED” （Optical Encoder），其中设备初始化函数OED_Init()在Windows CE装载驱动程序时用于创建中断事件和中断服务线程。在函数OED_Read()中将光电编码器的状态（OED_Status）返回。

　　3.4 封装驱动程序并加入到WinCE中

　　根据上述方法编译出动态链接库（DLL）还不够，因为它的接口函数还没有导出，还需要告诉链接程序输出什么样的函数，因此必须建立一个后缀名为def的文件。在本设计中为OpticalEncoder.def。下面是此文件的内容：

LIBRARY OpticalEncoder
　　EXPORTS
　　OED_Close
　　OED_Deinit
　　OED_Init
　　OED_IOControl
　　OED_Open
　　OED_PowerDown
　　OED_PowerUp
　　OED_Read
　　OED_Seek
　　OED_Write

一个具体的流接口驱动程序和注册表是密不可分的。向WinCE内核添加注册表项的方法有两种：一种是直接修改Platform Builder下的reg文件；另一种是自己编写一个注册表文件，通过添加组件的方法将动态链接库文件添加到内核中。这里用第2种方法，将 OpticalEncoder.dll添加到内核中。编写的注册表文件内容如下：

[HKEY_LOCAL_MACHINE\Drivers\Built In\STRINGS]
　　Index=dword :1
　　Prefix=OED
　　Dll=OpticalEncoder.dll
　　Order=dword :0

　　最后编写一个CEC文件，完成对定制内核注册表部分的修改并将OpticalEncoder.dll添加到系统内核中去,然后在Platform Builder中就可以直接添加已经编写好的驱动程序了。

　　结语

　　本文主要介绍了光电旋转编码器的原理及应用方法，并详细介绍了WinCE驱动程序的结构，成功地开发出了光电编码器在嵌入式操作系统WinCE下的驱动程序。实验证明，该方法正确可行，程序运行稳定可靠。

[新闻]苹果已然取代微软地位成行业众矢之的]]>http://www.cnblogs.com/harber/archive/2008/01/19/1045606.htmlWindowsCEWindowsCESat, 19 Jan 2008 09:33:00 GMThttp://www.cnblogs.com/harber/archive/2008/01/19/1045606.htmlhttp://www.cnblogs.com/harber/comments/1045606.htmlhttp://www.cnblogs.com/harber/archive/2008/01/19/1045606.html#Feedback1http://www.cnblogs.com/harber/comments/commentRss/1045606.htmlhttp://www.cnblogs.com/harber/services/trackbacks/1045606.html原文：: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1334401

1、基础知识：

1）系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件细节，在应用程序看来硬件只是一个设备文件，应用程序可以像操作普通文件一样对硬件设备进行操作。设备驱动是内核的一部分。

2）驱动程序完成以下功能：

——对设备初始化和释放；

——把数据从内核传送到硬件和从硬件读取数据；

——读取应用程序传送给设备文件的数据和回送应用程序请求的数据；

——检测和处理设备出现的错误。

3）上层应用程序运行在用户模式（非特权模式，Ring 3），代码被严格约束执行。如不能执行硬件IO指令。所有的这些被阻止的操作如果想运行必须通过陷阱门来请求操作系统内核。

4）操作系统内核运行在内核模式（特权模式，Ring 0），可以执行所有有效的CPU指令。包括IO操作，可访问任何内存区。

5）整个硬件系统资源在驱动程序面前是赤裸裸的，驱动可以使用所有系统资源，编写驱动程序时我们必须格外小心驱动代码的边界条件，确保它们不会损坏整个操作系统。

2、Windows支持的驱动：

1）虚拟设备驱动程序（Virtual Device Driver）：Windows3.1（Windows95/98/Me）

2）内核模式驱动程序（Kernel Mode Driver）：Windows NT

3）Win32驱动程序模型（Win32 Driver Mode）：从Windows98开始使用。

其中WDM是目前主流，然而在WinCE系统中，由于硬件资源有限和嵌入式系统的特点，对其的支持非常有限。

3、WinCE系统驱动简介：

1）WinCE毕竟是一个嵌入式系统，有其自身的特殊性，为了提高运行效率，所有驱动皆为动态链接库，驱动实现中可以调用所有标准的API。而在其他Windows系统中可能的驱动文件还有.vxd， .sys和动态链接库。

2）WinCE驱动从结构上讲分为本地驱动（Native Driver）和流接口驱动（Stream Driver）。

——本地驱动主要用于低级、内置的设备。实现它们的接口并不统一，而是针对不同类型的设备相应设计。因此开发过程相对复杂，没有固定的模式，一般做法是通过移植、定制现有的驱动样例来实现。

——流接口驱动是最基本的一种驱动结构，它的接口是一组固定的流接口函数，具有很高的通用性，WinCE的所有驱动程序都可以通过这种方式来实现。流接口驱动程序通过文件系统调用从设备管理器和应用程序接收命令。该驱动程序封装了将这些命令转换为它所控制的设备上的适当操作所需的全部信息。

流接口驱动是动态链接库，由一个叫做设备管理程序的特殊应用程序加载、管理和卸载。与本地驱动程序相比，所有流接口驱动程序使用同一组接口函数集，包括实现函数：XXX_Init、XXX_Deinit、XXX_Open、XXX_Close、XXX_Read、XXX_Write、XXX_PowerUp、XXX_PowerDown、XXX_Seek、XXX_IOControl，这些函数与硬件打交道。用户函数：CreateFile、DeviceIoControl、 ReadFile、 WriteFile，这些函数方便用户使用驱动程序。

3）WinCE下驱动的加载方式：

——通过GWES（Graphics, Windowing, and Events Subsystem）：主要加载与显示和输入有关的驱动，如鼠标、键盘驱动等。这些驱动一般为本地驱动。

——通过设备管理器：两种结构的驱动都加载，加载的本地驱动主要由PCMCIA Host Controller，USB Host Controller driver，主要是总线类的驱动；流接口驱动主要有音频驱动，串并口驱动。

——动态加载：前两者都是系统启动时加载的，动态加载则允许设备挂载上系统时将驱动调入内核，主要有外接板卡驱动，USB设备驱动等。

4、流接口驱动函数介绍：

1）DWORD XXX_Init(LPCTSTR pContext, LPCVOID lpvBusContext)；

pContext：指向一个字符串，包含注册表中该流接口活动键值的路径

lpvBusContext：

该函数是驱动挂载后第一个被执行的。主要负责完成对设备的初始化操作和驱动的安全性检查。由ActiveDeviceEx通过设备管理器调用。其返回值一般是一个数据结构指针，作为函数参数传递给其他流接口函数。

2）BOOL XXX_Deinit(DWORD hDeviceContext)；

hDeviceContext：XXX_Init的返回值。

整个驱动中最后执行。用来停止和卸载设备。由DeactivateDevice触发设备管理器调用。成功返回TRUE。

3）DWORD XXX_Open(DWORD hDeviceContext, DWORD AccessCode , DWORD ShareMode)；

hDeviceContext：XXX_Init的返回值。

AccessCode：访问模式标志，读、写或其他。

ShareMode：驱动的共享方式标志。

打开设备，为后面的操作初始化数据就够，准备相应的资源。应用程序通过CreateFile函数间接调用之。返回一个结构指针，用于区分哪个应用程序调用了驱动，这个值还作为参数传递给其他接口函数XXX_Read、XXX_Write、XXX_Seek、XXX_IOControl。

4）BOOL XXX_Close(DWORD hOpenContext)；

hOpenContext：XXX_Open返回值。

关闭设备，释放资源。由CloseHandle函数间接调用。

5）DWORD XXX_Read(DWORD hOpenContext, LPVOID pBuffer, DWORD Count)；

hOpenContext：XXX_Open返回值。

pBuffer：缓冲区指针，接收数据。

Count：缓冲区长度。

由ReadFile函数间接调用，用来读取设备上的数据。返回读取的实际数据字节数。

6）DWORD XXX_Write(DWORD hOpenContext, LPCVOID pBuffer, DWORD Count)；

hOpenContext：XXX_Open返回值。

pBuffer：缓冲区指针，接收数据。

Count：缓冲区长度。

由WriteFile函数间接调用，把数据写到设备上，返回实际写入的数据数。

7）BOOL XXX_IOControl(DWORD hOpenContext, DWORD dwCode, PBYTE pBufIn, DWORD dwLenIn, PBYTE pBufOut, DWORD dwLenOut, PDWORD pdwActualOut)；

hOpenContext：XXX_Open返回值。

dwCode：控制命令字。

pdwActualOut：实际输出数据长度。

用于向设备发送命令，应用程序通过DeviceIoControl调用来实现该功能。要调用这个接口还需要在应用层和驱动之间建立一套相同的命令，通过宏定义CTL_CODE(DeviceType, Function, Method, Access来实现。如：

#define IOCTL_INIT_PORTS \ CTL_CODE(FILE_DEVICE_UNKNOWN,0X801,METHOD_BUFFERED,FILE_ANY_ACCESS)

8）void XXX_PowerDown(DWORD hDeviceContext)；

hDeviceContext：XXX_Init的返回值。

负责设备的上电控制。

9）void XXX_PowerUp(DWORD hDeviceContext)；

hDeviceContext：XXX_Init的返回值。

负责设备的断电控制

10） DWORD IOC_Seek(DWORD hOpenContext, long Amount, WORD Type)

hOpenContext：XXX_Open返回值。

Amount：指针的偏移量。

Type：指针的偏移方式。

将设备的数据指针指向特定的位置，应用程序通过SetFilePointer函数间接调用。不是所有设备的属性上都支持这项功能。

5、流接口驱动的加载和注册表设置：

系统启动时启动设备管理程序，设备管理程序读取HKEY_LOCAL_MACHINE\Drivers\BuiltIn键的内容并加载已列出的流接口驱动程序。因此注册表对于驱动的加载有着关键作用。下面是一个例子：

【HKEY_LOCAL_MACHINE\Drivers\BuiltI\IOControler】

“Prefix”=”XXX”

“Dll”=”drivername.dll”

其中，“Prefix”＝“XXX”中的XXX要和XXX_Init等函数中的一样。CreateFile创建的驱动名前缀也必须和它们一致。

6、驱动程序的编写、编译及其相关目录、配置文件的格式和修改：

1）首先必须在PB相应平台的的driver目录下建立要创建的驱动所在的目录。如在x:\Wince420\platform\smdk2410\drivers目录下建立一个IOCtrol目录。

2）修改Drivers目录下的dirs文件。

3）创建驱动源文件XXX.c，在该文件中实现上述流接口函数。并且加入DLL入口函数：

BOOL DllEntry(HINSTANCE hinstDll, /*@parm Instance pointer. */

DWORD dwReason, /*@parm Reason routine is called. */

LPVOID lpReserved /*@parm system parameter. */

)

4）创建Makefile和Sources和.def文件，控制编译。

5）使用CEC Editor修改cec文件，编译添加的新特性。

6）复制新生成的4个文件到Release目录下，修改注册表文件platform.reg和platform.bib文件。

7）Make Image。

8）DownLoad Image。

[新闻]Intel 收购 Poky Linux ,为 MID 注入新的动力]]>http://www.cnblogs.com/harber/archive/2008/01/16/1041888.htmlWindowsCEWindowsCEWed, 16 Jan 2008 12:59:00 GMThttp://www.cnblogs.com/harber/archive/2008/01/16/1041888.htmlhttp://www.cnblogs.com/harber/comments/1041888.htmlhttp://www.cnblogs.com/harber/archive/2008/01/16/1041888.html#Feedback0http://www.cnblogs.com/harber/comments/commentRss/1041888.htmlhttp://www.cnblogs.com/harber/services/trackbacks/1041888.html原文：http://www.eepw.com.cn/article/72294.htm

来源：单片机与嵌入式系统应用

引 言

　　Windows CE为支持多线程、多任务、抢占式的嵌入式操作系统。随着Windows CE 6.0的发布，其内核性能的明显提升和源代码开放，将促使其在消费电子、工业控制、移动通信等领域得到广泛的应用。通常Platform Builder中给出了支持多种CPU常用设备驱动程序，如LCD驱动、鼠标驱动、USB驱动、串口驱动等;但有时由于平台采用了其他特定的硬件设备，其驱动程序在Platform Builder并没有给出，这时就需要用户针对实际的硬件自行开发，以满足个性化的需求。本文所涉及的SPI接口驱动就属于此类。

　　1 SPI总线及S3C2440芯片介绍

　　串行外围设备接口SPI(Serial Peripheral Interface)总线是Freescale公司推出的一种三线同步接口。接口采用同步串行3～4线方式进行通信，即1条时钟线SCK、1条数据输入线 MOSI、1条数据输出线MISO，另外还有1条从选线NSS(可选)，用于CPU与各种外围器件进行全双工、同步串行通信。SPI接口在众多的移动存储和高速通信芯片上得到广泛应用。

　　根据时钟极性和时钟相位的不同，MOSI和MISO上的数据支持4种数据传输格式。SPI的主要特点为：可以同时发出和接收串行数据，可以当作主机或从机工作，提供频率可编程时钟，发送结束中断标志，写冲突保护和总线竞争保护等。

　　S3C2440是一款基于ARM920T的16/32位RISC微处理器，主频可达400 MHz。该芯片性价比高，功耗低，含有丰富的片内外设，主要用于手持设备和移动终端。S3C2440中与SPI相关的寄存器有：

　　2 Windows CE的驱动程序

　　2.1 Windows CE下驱动程序的基本概念和分类

　　驱动程序是一个抽象物理设备或者虚拟设备的功能软件，驱动程序管理这些设备的操作并将设备的功能导出给操作系统和应用程序。根据驱动程序导出接口的不同，windows CE中驱动可以分为本机设备驱动程序(native device driver)和流式驱动程序(streams device driver)。本机设备驱动适于集成到基于Windows CE平台的设备。这些设备驱动程序是一些硬件所必需的，是由原始设备制造商创建的，用来驱动如键盘、LED、触摸屏等。本机驱动在编译时被静态链接到GWES，系统运行时由GWES加载。流式驱动程序也称"可安装驱动程序"，是由设备管理器(device.exe)动态加载用户模式的DLL。对流式驱动程序来说，不管需要控制的设备是什么类型，所有流式驱动都使用相同的接口并导出一组相同的函数--流接口函数。流式驱动适用任何在逻辑上可以被认为是一个数据源或者数据存储的I/O设备。

　　2.2流式驱动程序工作原理

　　在Window CES中，流式驱动程序负责将设备抽象成一个文件，应用程序便能够使用系统提供的API(ReadFile、writeFile、IOControl等) 对其进行读写。应用程序使用文件API访问设备时，请求经过文件系统(Filesys.exe)过滤被送到device.exe;device.exe根据请求调相关的流式驱动程序接口，从而完成与硬件的交互。

　　2.3 设备驱动的中断处理

　　在windows CE系统中，当中断发生时，OEM抽象层(OEM Abstraction Layer，OAL)把物理中断信号映射成OEM定义的逻辑中断供操作系统和驱动程序调用。为了满足实时性要求，系统将中断处理过程分为2个阶段，即处于内核模式的中断服务例程(Interrupt Service Routine，ISR)和处于用户模式的中断服务线程(Interrupt Service Thread，IST)。ISR主要负责将物理中断映射为逻辑中断，然后由操作系统根据逻辑中断激发所关联时间对象的内核，使等待该事件内核对象的线程 IST开始执行中断处理程序。

　　具体中断处理过程如图1所示。中断发生后，信号发往异常处理器，并且中断支持处理器调用OAL函数OEMInterruptDisable关闭来自该硬件的中断。ISR被内核调用并返回结果，且通过内核设置Event事件来触发IST。IST被唤醒后调用各种I/O函数完成中断处理并返回 InterruptDone通知内核。内核调用OEMInterruptDone通知硬件重新开启中断。

3 SPI总线驱动设计

　　综上所述，SPI总线驱动分为2部分，即处于内核模式OAL层将物理中断映射成逻辑中断的ISR，以及处于用户模式流式驱动。其中包括执行中断处理线程IST。

　　3.1 初始化中断以及ISR实现

　　SPI通信是通过读写SPI寄存器来完成的，通过读写上述6个SPI寄存器中的状态字可以检测和控制SPI总线的行为。在OAL层中需要完成的工作如下：

　　①在中断头文件oalintr.h中添加SPI的中断宏定义，供ISR返回调用。

　　#(define SYSINTR_SPIO (SYSINTR_FIRMWARE+22)

　　注意：定义时要使中断号满足该文件中MapIrq2SysIntr中所要求的范围。WinCE4.2版本支持最大中断数为32，WinCE5.0版支持最大中断数为64。

　　②在OAL实现文件cfw.c中，添加中断初始化和禁止中断实现代码。

　　③在中断处理实现文件armint.c的OEMInterruptHandler函数中添加ISR程序代码，返回逻辑中断号。代码如下：

　　3.2 流式驱动的实现

　　驱动被加载后需要完成设备的初始化工作，包括地址空间申请和映射、全局变量的初始化、IST的加载等。初始化的代码简化如下：

　　需要说明的是，在本程序中使用了CEDDK中MmMapIoSpace库函数，故另需在头文件中添加#include和#pragma comment(lib,"ceddk.lib")。至此，g_SPIReg在其他的驱动实现函数中就可以调用，直接读写其指向的寄存器的代码即可完成相关的操作。还需要实现的函数有：SPI_Deinit、SPI_Read、SPI_write、SPI_Seek、SPI_Open、 SPI_Close、SPI_IOCntrol。限于篇幅，本文仅给出驱动初始化的代码。

　　(编者注：源代码见本刊网站www.mesnet.com.cn。)

　　3.3 驱动与应用程序的通信设计

　　在Windows CE中，用户模式下每个进程与其他进程所占有的内存空间被虚拟内存机制隔离，进程间无法实现直接互访。在驱动程序和应用程序通信过程中，驱动程序位于 device.exe的进程空间中，由于上述原因，驱动程序向应用程序发起的单向通信存在困难。通常的解决方法是在内核空间中共享同步对象，建立消息队列或者通过指针映射来完成。上述方法都无法回避进程间的数据复制过程，因而只适用于少量的数据传输。对于大量的数据或者实时性要求较高的情况，可以在虚拟地址为Ox4200 0000～0x7fff ffff的空间中建立命名的内存映射来实现内存共享，从而能够避免数据在进程空间中的复制。相关的API为CreateFileMapping和MapView()fFile。

　　3.4 驱动程序的封装和安装

　　驱动接口函数编写完后将其接口以dll的形式导出，再编写一个简单的注册表文件，指明驱动安装的路径、前缀以及索引。至此驱动程序设计工作就完成了，将驱动及注册表添加到当前的平台中即可。

　　结 语

　　本文详细介绍了Platform Builder下SPI接口驱动程序设计以及驱动程序同应用程序交互的实现。驱动例程已经成功地应用于基于nRF2401的嵌入式系统无线通信当中，具有很高的参考价值。

Posted by: Sue Loh

This material is drawn from a talk that Travis Hobrla gave at MEDC 2006 (thanks Travis!) and contributed to by the whole Windows CE BSP team.

The driver changes that I have already written about the biggest CE6 differences that OEMs would care about.  Much less significant are the CE6 OAL changes.  The OAL, or OEM Adaptation Layer, is somewhat analogous to a HAL (Hardware Adaptation Layer).  The OAL plus a set of drivers comprise the BSP (Board Support Package), the software that makes the Windows CE OS run on the OEM’s hardware.

One big OAL detail that did not change: the production quality OAL initiative, or PQOAL.  PQOAL is a directory organization, a highly componentized set of libraries you can pick and choose from to compose your OAL.  The following illustration shows how all of the components come together to build a complete OAL which interfaces between the kernel and the hardware.

PQOAL was introduced in CE5, and is optional.  You can create CE5 and CE6 BSPs without using the PQOAL organization.  But it is easier to port a PQOAL BSP from CE5 to CE6.  If you have a non-PQOAL BSP that you want to port to CE6, you may choose whether to port to PQOAL while you are porting to CE6.  Our BSP team recommends adopting PQOAL; their expectation is that you will find the componentized organization easier to maintain and easier to port to new OS versions over time.  If you already have a BSP that uses the CE5 PQOAL organization, you’ll find the directory structure and available libraries to be quite similar in CE6.

So what did change?  In CE6 we split up three components that previously linked together to make the kernel executable, nk.exe.  CE5 the kernel, OAL and the Kernel Independent Transport Layer (KITL) all linked into nk.exe.  In CE6 these are broken into kernel.dll, oal.exe and kitl.dll.

The primary reason for this change was updateability.  In the past, if Microsoft released a kernel update, the OEM would have to take the updated kernel and link it again with their OAL to produce a new nk.exe.  Now the OEM only has to distribute Microsoft’s new kernel.dll.

Another benefit of this change is that it formalizes the interface between the kernel, OAL and KITL.  These components exchange tables of function pointers and variable values to communicate with each other, and cannot invoke functions other than those in the tables.  In CE5 and earlier OS versions, some OEMs found that since the OAL and kernel linked together into the same executable, they could call undocumented kernel APIs.  The problem with this is that Microsoft did not support the APIs being called this way.  Some of them had special cases or calling rules that OEMs would not know about.  Security holes and stability problems were possible.  Supportability was also a risk; kernel hotfixes between releases could potentially break OEM code.

An additional benefit of the kernel / OAL / KITL separation is that each module now has its own debug zones and can be debugged independently.  It is also a step on the way toward a dynamically loadable KITL – that’s not yet possible in CE6, but hopefully will be possible in the future.

So let’s dig further into the details of the separation of these binaries.

In Windows CE 5.0, the BSP directories built three different versions of the kernel exe.

• OAL + Kernel = kern.exe
• OAL + Kernel + KITL = kernkitl.exe
• OAL + Kernel + KITL + Profiler = kernkitlprof.exe

Maintaining these three different directories could be bothersome, and some OEMs chose only to maintain kern.exe.  This choice meant they could not use KITL for debugging or use the kernel profiler to measure performance bottlenecks.  I cannot emphasize enough how strongly we at Microsoft believe it is worth your time to set up KITL.  It is an up-front investment that will save you much debugging time as you work.

In Windows CE 6, we don’t build multiple versions of the OAL.  The separation of KITL into kitl.dll gets rid of the distinction between kern.exe and kernkitl.exe.  And we now recommend that OEMs always build profiling support into their OAL, getting rid of the need for separate kernkitl.exe and kernkitlprof.exe.  As a result, the platform directory only needs to build one executable: oal.exe.
A side note about profiling from an observer who is definitely not impartial.  :-)  Profiling support is not actually required, unless you want to use the kernel profiler.  But the required code to implement profiling is small, and won’t impact OS performance as long as the profiler is not actually running.  I believe the benefits of the profiler justify the small amount of work needed to set it up.  You could look at our sample BSPs to see how they implement profiling, or you could look at the previous blog post I wrote for an explanation of a simple profiling implementation.

We tried to simplify the CE6 OAL modularization as much as possible, to ease porting of CE5 OALs to CE6.  Each module builds a table of function pointers for use by the other modules.  The kernel exports NKGLOBAL (See the CE6 %_WINCEROOT%\public\common\oak\inc\nkglobal.h).  This table is too large to reproduce meaningfully here, but there are function pointers for things like debug output, interrupt hooking, synchronization objects, virtual memory operations, registry access, string operations, and other kernel interfaces.  There are also shared global variables passed via the NKGLOBAL table.

But OEMs don’t need to completely revise their OAL code to call kernel functions using these pointers.  We hid the existence of the kernel and KITL function pointer tables inside a library of wrapper functions that the OAL can use (nkstub.lib), so that exactly the same set of functions are available to the OAL as in the past.  For example, to use a critical section, the OAL doesn’t need to call the function table entry pNKGlobal->pfnEnterCS().  Instead, nkstub.lib has a wrapper function EnterCriticalSection() for the OAL to call as it did in the past:
%_WINCEROOT%\private\winceos\coreos\nk\nkstub\nkstub.c:

void WINAPI EnterCriticalSection (LPCRITICAL_SECTION lpcs)

{

g_pNKGlobal->pfnEnterCS (lpcs);

}

This library of wrapper functions should make it easier to port OAL code to CE6.  All you have to do is link nkstub.lib into the OAL in order to call the kernel APIs.

Similarly, the OAL exports an OEMGLOBAL table (%_WINCEROOT%\public\common\oak\inc\oemglobal.h) with OAL functions and global variables.  Many of the functions in this table are required; the OS won’t work unless the OEM assigns the function pointers.  Others are optional; the OAL can pass NULL pointers and the OS would continue to work.  Required exports will be assigned to OEMGLOBAL by oemmain.lib (explained below), while you will need to assign optional exports inside your OEMInit routine.  For example, the OAL exports used to implement kernel profiling are optional.  So the Aspen7750R sample BSP assigns the profiling exports as follows.

%_WINCEROOT%\platform\Aspen7750R\src\oal\oallib\init.c:

void OEMInit()

{

// other code removed

g_pOemGlobal->pfnProfileTimerEnable = OEMProfileTimerEnable;

g_pOemGlobal->pfnProfileTimerDisable = OEMProfileTimerDisable;

}

To find out which OAL exports are optional and which are required, see the CE6 Platform Builder help for OEMGLOBAL.

As with NKGLOBAL, there is a wrapper library oemstub.lib that wraps the OAL exports.  Kitl.dll can use oemstub.lib to call OAL functions.

%_WINCEROOT%\private\winceos\coreos\nk\oemstub\oemstub.c:

BOOL OEMGetRealTime(LPSYSTEMTIME pst)

{

return g_pOEMGlobal->pfnGetRealTime (pst);

}

Besides nkstub.lib and oemstub.lib, there are a few additional libraries in CE6 for OEM use:

• Kitlcore.lib: This is a replacement for kitl.lib, implementing the KITL protocol and the initialization of the kitl.dll interface with the NKGLOBAL and OEMGLOBAL structures.  You should link this library into kitl.dll instead of kitl.lib.
• Nkldr.lib: This library implements KernelInitialize / KernelStart, to link into oal.exe.
• Oemmain.lib: This library implements the OEMInitGlobals function which exchanges function pointers with the kernel.  Link this into oal.exe.

The resulting work to port a CE5 BSP to CE6 would be to revise the platform directory structure slightly, and link with different libraries.  The old CE5 directory structure:

CE5 Directory

Builds

%_WINCEROOT%\platform\BSP_NAME\src\kernel\oal

oal.lib

%_WINCEROOT%\platform\BSP_NAME\src\kernel\kern

kern.exe

%_WINCEROOT%\platform\BSP_NAME\src\kernel\kernkitl

kernkitl.exe

%_WINCEROOT%\platform\BSP_NAME\src\kernel\kernkitlprof

kernkitlprof.exe

Now becomes:

CE6 Directory

Builds

%_WINCEROOT%\platform\BSP_NAME\src\oal\oallib

oal.lib

%_WINCEROOT%\platform\BSP_NAME\src\oal\oalexe

oal.exe

%_WINCEROOT%\platform\BSP_NAME\src\kitl

kitl.dll

Oal.lib is exactly the same as before, so the remaining porting steps between CE5 and CE6 boil down to building oal.exe and kitl.dll.

1. The oalexe directory is the same as the old \kernel\kern\*, with nkldr.lib, oemmain.lib and nkstub.lib added to the sources file.
2. The kitl directory comes from taking the KITL specific elements out of the old \kernel\kernkitl.  Convert it from an EXE to a DLL, remove the non KITL related binaries, and add nkstub.lib and oemstub.lib.  You will also need to add some global variables that used to be common with the OAL.

There are other small changes you’ll run into, related to differences in the sets of PQOAL libraries available between CE5 and CE6, but they’re relatively minor and not related to the OAL / kernel / KITL separation.

As a side note, the separation of OAL and KITL is actually optional, so your other choice could be:

CE6 Directory

Builds

%_WINCEROOT%\platform\BSP_NAME\src\kernel\kern

oal.exe

%_WINCEROOT%\platform\BSP_NAME\src\kernel\kernkitl

oalkitl.exe

As I mentioned previously:  Anecdotal experience from our beta partners said that BSP porting to CE6 took them mostly between one day and one month.  Travis Hobrla, a member of our BSP team, developed an awesome demo for MEDC 2006 (Mobile & Embedded DevCon) where he ported the CE5 CEPC OAL to CE6 in about 15 minutes.  If you are an OEM, your experiences may vary, but we don’t anticipate it being too painful.  It was our goal to make it an easy port.

Note!  Travis’ demo is also being developed into an online “eHowTo” you could follow as a porting exercise.  I don’t see it yet on http://msdn.microsoft.com/embedded/getstart/basics/tutorialsce/default.aspx but that’s where I’d look for it.

The main area where you may have to make big changes is if your CE5 OAL called kernel APIs that we did not intend to expose to the OAL.  In CE6 you would have to move that functionality out of the OAL, into a kernel-mode driver.  You might need to design the OAL to expose IOCTLs to work together with the kernel-mode driver to implement the old functionality.

One final detail you should be aware of is that for security reasons, the OS only exposes a few OAL IOCTLs to user-mode code.  By default, applications and user-mode drivers can’t call OAL IOCTLs that Microsoft didn’t specifically expose to user mode.  For more detail, see the “OAL IOCTL Codes” section of http://blogs.msdn.com/ce_base/archive/2006/11/14/application-compatibility-in-windows-ce-6-0.aspx.

Filed under: Author: Sue Loh

[新闻]中国互联网战争局势图]]>http://www.cnblogs.com/harber/archive/2008/01/03/1025130.htmlWindowsCEWindowsCEThu, 03 Jan 2008 14:11:00 GMThttp://www.cnblogs.com/harber/archive/2008/01/03/1025130.htmlhttp://www.cnblogs.com/harber/comments/1025130.htmlhttp://www.cnblogs.com/harber/archive/2008/01/03/1025130.html#Feedback3http://www.cnblogs.com/harber/comments/commentRss/1025130.htmlhttp://www.cnblogs.com/harber/services/trackbacks/1025130.html做CE的兄弟们肯定会经常遇到的一个问题是系统在OEMInit()执行完之后停止。什么信息也没有。最近在google上高人总结的一些可能情况，如下：

1. OEMAddressTable中内存映射错误
2. Config.bib中内存分配错误
3. 中断配置问题
4. 系统时钟配置问题
5. 底层内存管理配置问题(MMU,caching等)
6. 使用了未初始化的指针

。。。

解决方法：

检查相关代码

打开全部调试信息选项。如在OEMinit中call OALLogSetZones(0x0000FFFF)；获取更多的信息。

[新闻]开源多点触摸技术试运行]]>http://www.cnblogs.com/harber/archive/2008/01/03/1025104.htmlWindowsCEWindowsCEThu, 03 Jan 2008 13:50:00 GMThttp://www.cnblogs.com/harber/archive/2008/01/03/1025104.htmlhttp://www.cnblogs.com/harber/comments/1025104.htmlhttp://www.cnblogs.com/harber/archive/2008/01/03/1025104.html#Feedback0http://www.cnblogs.com/harber/comments/commentRss/1025104.htmlhttp://www.cnblogs.com/harber/services/trackbacks/1025104.htmlChris Tacke
OpenNETCF Consulting
March 2007 

摘自：http://community.opennetcf.com/articles/cf/archive/2007/08/31/debugging-without-activesync.aspx

Introduction

If you've tried to debug a native or managed application with Microsoft Visual Studio 2005 on any device other than a Windows Mobile device, you're likely very aware of how painful it can be to just get connected.  Typically it's a process requiring the proper alignment of planets, holding your tongue just right and often a visit to Stonehenge.

We hope that this short white paper  along with CeDbgSetup.exe will take a lot of the pain out of the process. 

Requirements and Assumptions

Before proceeding, make sure you have the following:

• Visual Studio 2005, Standard Edition or better with Service Pack 1 (SP1) installed. If you don't have SP1, CeDbgSetup.exe will deploy the wrong CoreCon files for your environment and Studio will only laugh at you with a very unhelpful "Cannot Connect" message.
• CeDbgSetup.exe. This is a free, shared source tool that we've written to do a lot of the grunt work on the device for you. As usual it's provided as-is and without warranty, but if you have a problem let us know.
  As of this writing CeDbgSetup.exe supports only ARMv4I and x86 devices. Sorry to you MIPS and SHx developers, but I don't have a device with one of those processors, so I can't build or test the tool for those architectures. If you have an SDK for one of them, let us know and we may be able to update the tool.
• As of this writing we've only verified that this works with Studio running on Windows XP.
• You probably should shut off or put an exception in firewalls and other security stuff that might interfere with the transport
• We've tested with the PC and the device running 802.11 connections, so yes, this work wireless on either or both sides
• You don't need ActiveSync. Need we say more?

Configure the device

1. First make sure the device has a valid IP address. Record the IP for future use.
   Using a fixed IP, especially on networks where the DHCP lease is short and addresses change frequently. If the device IP address changes, this entire process must be done again.
2. Deploy and Run CeDbgSetup.exe on the device. This application is provided for free from OpenNETCF Consulting. If your device has a mechanism to persist the file and auto-launch it on boot, then we recommend that you do so to make things simple.
   When successfully run, shortcuts will be added to the device desktop. In normal operation you should not actually need to use these shortcuts.

Configure the PC

1. Verify you can ping the device the ensure that there is a solid communication channel.

Configure Visual Studio

1. Enable the Device toolbar by right-clicking on Studio's toolbar and checking ‘Device'
   
2. Select your target device. In this example we'll choose the iCOP eBox 2300, which is running CE 6.0. You'll see that I've got several other devices to choose from.
   
3. Open the Devices option window by either clicking the ‘Device Options' button on the Device toolbar or using the following menu path Tools->Options->Device Tools->Options.
   
4. Select your platform from the "Show devices for Platform" dropdown.
5. In the "Devices" list, select your target device. At thins point it may be useful to rename the device. You can also "clone" any device by clicking "Save As" which can be helpful if you want to have different transports or IP addresses for the same type of target device.
6. Select your device in the "Devices" list and click "Properties"
   
7. Click on the "Configure" button
   
8. Select the "Use specific IP address" radio button and enter device's IP address you recorded way back at the start of this process.
9. Click the "OK" button on all 3 dialogs to bring you back to Studio.
10. Click the "Connect to Device" button on the Device toolbar
    
    You should see the following:

At this point Visual Studio can communicate with the device and you're ready to develop.

http://blogs.msdn.com/windowsmobile/archive/2005/09/07/462187.aspx

When was the last time you saw a Windows Mobile device that couldn't do color?  (It's a trick question.  The last grayscale device predates the name change to "Windows Mobile.")  Subtle differences in screen quality aside, all WM devices have had the same ability to show colors--65536 of them.  Modern LCD screens, however, are capable of showing four times that many (262144).  So I've been asked, "Why doesn't WM allow OEMs to make use of these better screens?"

The short answer is: "We do."

The medium answer is: "But don't be so sure you want them to."

And the long answer is ... well the rest of this entry.

Kibbles and Bits
That medium answer is pretty shocking.  "How could I possibly not want them to have more colors?  Having more colors is a good thing, isn't it?"  To understand this answer, we're going to have to understand how computers show colors.  65536 isn't an arbitrary number.  It's the number of combinations possible in 16 bits of information (a "bit" is a number that can either be 1 or 0). 

Every dot on the screen (the technical term for "dot on the screen" is "pixel") is represented by 16 bits of information.  Those 16 bits give the color of that dot.  If you're really interested, it's broken up into 5 bits for the red intensity, 6 bits for the green, and 5 bits for the blue.  This format is known as "RGB 565." 

Modern mobile CPUs are extremely good at dealing with 32 bits of data at a time.  They're pretty good at dealing with 16 bits of data at a time, and they're reasonably good at dealing with 8 bits of data at a time.  They're pretty lousy at dealing with other amounts, though.

What's it take to do 262144 colors?  18 bits.  Since that’s not 8, 16, or 32, it's not a particularly CPU-friendly number.  For those keeping track of image formats, this would be 6 bits of red, green, and blue, or "RGB 666." 

I was Framed!
The next thing to understand is how the bits turn into colors on the screen.  Say you've got a typical PocketPC with a resolution of 240x320 and 65536 colors.  That means you've got 320 rows of 240 pixels (dots), each of which has 16 bits of data representing its color.  All of that information is stored in a chunk of memory known as the "Frame Buffer."  The LCD hardware takes whatever is in the Frame Buffer and converts it directly to what's on the screen.  Want to change what's on the screen?  Change what's in the Frame Buffer and the screen will update.

Okay, so we need 16 bits for every pixel, and we've got 240 times 320 dots.  16 bits is two bytes, so that's a total of 153600 bytes, or 150K of RAM used to hold what's on the screen. 

A Packing Problem
You need the CPU to write things into the Frame Buffer.  Since a pixel is 16 bits and the CPU really likes to deal with data 32 bits at a time you just write 2 pixels at once.  This makes everything happy.  But what would happen if you had 18 bits per pixel?  The first pixel would line up on a boundary that the CPU is happy with.  But the next one wouldn't.  Neither would the one after that.  Things wouldn't line up again until the 16th pixel.  So, 15 out of every 16 pixels are handled in a way that's really inefficient for the CPU.  18 bits just don't fit together well in a world of 32s. 

For this reason, the RGB 666 pixel format (18 bit) just doesn't exist.  It's not natively supported in any operating system I'm aware of.  Not CE, XP, Mac, Unix, Palm, or Symbian.

But wait.  There's a competitor's phone out right now that advertises having a 262144 color screen.  They must support 18 bit color, right?  Actually, no they don't.  They support 24 bit color, and then they throw away the data from 6 of the extra 8 bits. 

Have you ever tried to fit two suitcases into a trunk only to find that they're just a tiny bit too big to fit?  What did you do?  Most likely, you put a smaller suitcase in the extra space.  But what if you didn't have a smaller suitcase?  In that case, you probably put the one suitcase in the trunk and left a lot of wasted space around it.  That's what's happening with anyone who is supporting an 18 bit screen.  Because the 18 bits don't pack together well, they leave empty space around them.

Bitfield Wasteland
There are two ways to do 24 bit color.  In both cases, there are 8 bits for red, green, and blue (RGB 888).  In the first case, each pixel has 24 bits, and in the second it has 32 bits (the remaining 8 bits are either used for transparency or are unused). 

The 32 bit case is the best for the CPU.  It's one pixel for every 32 bits, so everything is guaranteed to line up the way the CPU likes it.  The 24 bit case isn't as good as 32, but it's way better than 18 bits.  At least everything in 24 bits lines up on an 8 bit boundary, and you get back to a full 32 bit boundary every 4 pixels.  But, remember, while the system thinks it's doing 24 bits of color information, the screen is only using 18 of those bits.  The rest are being thrown away.  So, depending on how you implement this, you're either wasting 6 bits of every 24, or you're wasting 14 bits of every 32. 

Enough mumbo jumbo.  What does this really mean?
It comes down to this.  If you want to make use of those extra colors, your frame buffer needs to be either 50% or 100% bigger than it is now.  Filling that frame buffer will be correspondingly 50% to 100% slower.  Things that require the screen be updated frequently (watching movies, taking pictures, playing games) will go slower.  Games in particular, are hard hit.  Games based on the old Game API (GAPI) will need to do a slow conversion, or they won't work at all.  Newer DirectDraw games will do better, but will still be slower on a 24 bit system than on a 16 bit one. 

Windows CE supports both forms of 24 bit color (24 and 32 bits).  If an OEM really wants to "make use" of that 18 bit screen, they can.  The question you need to be asking yourselves, however, is whether or not it's worth the cost.  Is a marginally better image worth slower graphics? 

It is my belief that the tradeoff isn't worthwhile.  I see this as a marketing battle, not a technical one.  The competition wants to put the bigger number in their bullet points so they can be "better" even though, in my opinion at least, it makes them worse. 

Here's a quick and dirty desktop app written by one of our hardware guys.  It lets you load a 24 bit image and compare it to what it would look like in 18 and 16 bit.  Because it's so hard to see a difference, the app also shows a 12 bit image.  Nothing does 12 bit anymore, but you can look at the faults in that image to give you an idea where to look for differences in the 16 and 18 ones.  The App requires that you have .net 2.0 installed.  Sorry, it's what we had handy on short notice.  You can decide for yourself whether the differences in 18 and 16 bit are worth the corresponding ram and speed costs.

So, when will we see more colors?
I believe two things need to happen before this will be worthwhile. 

First, we need screens that use all 24 bits.  You pay the same speed penalty for 24 bit color as you do for 18.  But 18 is just a tiny bit better than 16.  Let's not take the hit until we get the full benefit out of it.

Second, we need devices to get fast enough that the speed hit isn't significant.  The desktop is there.  Mobile devices aren't yet.  Mobile devices are getting faster, but they're still RAM and CPU constrained. 

Alternately, a clever hardware company could make a mobile LCD controller that takes a 16 bit Frame Buffer and dithers up to 18 bits to match the screen.  That would get you some benefit out of the better screen with no hit in speed.  We would very much like to see this happen, but, to my knowledge, it hasn't yet.

Posted: Wednesday, September 07, 2005 4:15 PM by windowsmobile

Filed under: MikeCal

[新闻]Mac OS X 10.5.5 Build 9F23 测试版和 Safari 4 预览版]]>