在CE4.2/5.0里面滚打多年的兄弟应该经常用这个函数吧。这个函数方便驱动和应用程序范围任何的物理地址，包括物理内存啊，设备控制器的寄存器啊，甚至GPIO也可以在AP里面随便拉上拉下。

这个函数虽然方便，但是并不安全，你想你好不容易把一个功能完善的image给build出来了，结果碰到了一个写AP的“高手”，把你的寄存器和共享内存中的数据修改得一塌糊涂，最后报出bug来说你驱动的你会不会晕倒！

还好从CE6.0开始我们可以安枕无忧了，因为AP再也不能调用VirtualCopy函数来直接访问物理地址了，但因此带来了一些应用上的不便。

VirtualCopy的限制来源于CE6.0之后kernel的巨大变革，在CE5.0之前的Windows CE操作系统中，kenrel就仅仅是kern.exe（nk.exe），这个exe其实是OAL、KITL和Kernel三个的合体，nk.exe是运行于内核模式（kernel mode），也就具有了访问特殊地址的权限，然后除此之外的代码默认都是运行于用户模式（user mode），所以它们的驱动和AP都是等级的，都在用户模式运行，要运行在kernel模式也可以，调用一个API SetKmode（）就行了。因为驱动是肯定要访问物理地址的，所以CE5.0以前的OS都是运行用户模式的程式访问物理地址的，然后又为了方便做从物理地址到虚拟地址的映射，就提供了一系列的帮助函数，virtualcopy就是最常用的函数之一。

CE6.0开始，kernel模式变得比较正规，类似于台式机上的windows系统了，驱动和ap的权限是严格区分的，大部分的驱动程序运行在kernel模式，它们可以用virtualcopy读写物理地址对应的物理设备，但用户模式的AP将从此没有直接访问物理地址的权限，virtualcopy每次调用都会失败返回。

在这里还要注意的是，其实并不是用户模式就不能使用virtualcopy，virtualcopy只是不能在用户模式的AP中使用，但是却还可以在用户模式的驱动使用，但是在用户模式的驱动中使用也有条件，那就是必须在对应的注册表中设置可以访问的内存地址的范围才行。

在某些场合，一些特殊功能的AP确实需要访问物理地址的，比如设置保存物理内存指定位置的全局变量，开发读写GPIO的测试工具等等。在这种情况下一种简单的方法是实现一个最简单的跑在kernel模式的流驱动，提供一个deviceiocontrol的接口来帮助AP申请对应于物理内存地址的虚拟内存地址。

除了virtualcopy之外，CE6下还有很多API是AP和user模式的驱动不能调用的，给大家参考一下，大家要把CE50下的AP移植到6.0下一定要注意找到替代

Virtual Memory APIs
CeVirtualSharedAlloc
LockPages
LockPagesEx
UnlockPages
UnlockPagesEx
VirtualAllocCopyEx
VirtualCopyEx
VirtualSetAttributes
CreateStaticMapping
NKDeleteStaticMapping
VirtualCopy

File System APIs
ReadRegistryFromOEM
SetStoreQueueBase
WriteRegistryToOEM

Power APIs
PowerOffSystem （很多测试AP用到）

Miscellaneous APIs
SetOOMEvent

　　Windows CE 6.0的新变革

　　Windows CE 6.0依旧把眼光投注在ARM架构中，新的BSP与编译器也都支持了ARM的最新体系，但是其它嵌入式处理器的支持也没有被忽视，威盛公司最新的处理器也在不久前宣称支持了Windows CE 6.0操作系统。而6.0版也是微软首个导入次世代档案系统ExFAT的操作系统，虽然到目前为止其细节还不明了，但是根据已有的信息指出，ExFAT在Windows CE 6.0中，担当了总管所有外接储存媒体的中界层的角色，广为产业界所称赞的是，这能够解除过去传统FAT档案系统的32GB单一容量限制。ExFAT同样也解除了单一档案只能在2GB以下的限制，这对于硬件厂商以Windows CE发展大容量储存管理伺服架构，有著相当大的帮助。加上一些安全机制，我们可以把ExFAT视为Windows CE 6.0上的NTFS加强版。

　　VoIP也是Windows CE 6.0另一个持续加强的重点，除了在应用程序层的整合更进一步以外，操作系统核心也具备直接支持的能力，因此硬件开发上可以更容易的在Windows CE环境上进行各种网络的语音通讯服务。而因应这样的趋势，6.0版自然也把过去5.0版的缺失补正过来，在网络堆叠协定方面，直接支持了802.11i、WAP2、802.11e（无线QoS）、蓝牙A2DP/AVRCP的AES加密等等，为无线通讯建立了一个稳定、安全以及可靠的应用环境。

　　而从使用者观点来看，Windows CE 6.0扩展了超越以往版本总和的承诺，这些功能包括了最新的多媒体能力，诸如Windows Media 10/11的支持、，对于网络多媒体装置的原生整合能力，在Platform Builder开发工具中，甚至也加入了行动媒体中心的支持，可以藉由Windows Media Connect 2.0大幅强化多媒体应用的支持能力，并且可以与其它微软的操作系统或硬件装置做同步统合的动作。这些功能包含了以下项目：

　　■ TIFF编解码器的支持
　　■ HD-DVD的解码器支持
　　■ MPEG-2解码器
　　■ 更多的影音编码与格式支持
　　■ UDF 2.5格式的支持
　　■ 虚拟环绕声道的支持
　　■ 多轨音效的支持
　　■ 强化DirectDraw，可支持电视使用的交错显示模式
　　■ USB OTG功能加入，可作为USB的控制端

　　虽然在核心部分做出这么大的更新，但是Windows CE 6.0的储存上并没有如微软其它操作系统般的飞涨（Vista甚至需要超过10GB的初始储存安装空间！），相较起5.0版，6.0在体积上也不过增加了5％左右，虽然这对嵌入式系统产业来说是理所当然，但对于微软可以说是另一项奇迹。

　　Windows CE 6.0带给开发者的好处

　　在开放原始码的历史中，微软要写下另一个新的里程碑，100％对产品开发者释放出原始码，且可允许厂商进行自订的变更或订做，而无须释放出经过修改的程序码，虽然在广义上并不能视为真正开放，但是为这些喜欢藏私留一手的厂商来说，无疑是增加竞争力的最佳手段之一。而作为开发工具的Visual Studio 2005 PRO将会作为Windows CE 6.0的整体套件之一，内建的许多开发工具与定义对于开发者来说相对便利许多。

　　Windows CE 6.0支持了Windows .NET Compact Framework 2.0作为应用程序管理开发以及Win32、 MFC、 ATL、 WTL和STL等程序开发界面提供给开发原生应用程序的开发者使用。具备了如此势力庞大以及完整的开发环境作为支持，开发者与制造商也可确保后续的支持不虞匮乏。

　　而在硬件方面，根据微软方面的说法，在不变更原有的硬件架构之下，导入Windows CE 6.0可以大幅改善原有程序的执行效率，并且也容许同时间有更多程序同步执行，由于每个程序都具备有独立的执行空间，特定程序当掉，也不会影响到其它应用程序或系统执行，提供给使用者比起以往旧版系统更强的稳固性与更大的弹性。而目前逐渐风行的多核心处理架构上，Windows CE 6.0也可以在不变更程序开发者原有程序模型的状况之下，提供最佳化的核心工作自动分配与指定，当然，如果有需求的话，程序开发者依然可以自行决定指定核心的方式。

　　市场上的实际应用与结论

　　截至目前为止，台湾已经有研华科技在针对物流、仓储管理、公共服务以及领域维护方面的应用，进行基于Windows CE 6.0操作系统下的工业级掌上型终端机的开发，而精技计算机则是开发了可应用于搜集资料、RFID、BarCode管理的垂直市场PDA，采用Windows CE 6.0中的cell core元件，缩短GPRS端的资料传输设计时程。而各大手持式智能装置的开发者也都已经在着手导入Windows CE 6.0，实际产品预计将会于2007年第二季之后逐渐浮现台面。

　　100％开放原始码的创举对于微软来说是个相当大的突破，虽然这有一大部分是因为嵌入式Linux所带来的竞争挑战所致，但是鹬蚌相争的结果，带给开发伙伴的好处也远大于过去采用封闭模式的流程，而延续过去Windows CE 5.0的成果，Windows CE 6.0也将会继续在嵌入式应用、行动装置、GPS、智能型手机等市场继续攻城掠地，不过在面对市场上诸多对手的竞争，微软仍须做出更多的改进。比如在修正漏洞方面可以更快速的反应、并且提供给开发者更大的支持力度等等，当开发者甜头吃的够多，自然也会对Windows CEWindows CE架构更为忠诚，出现在市面上的产品自然也会更为成熟。

　　进入作者专栏

RELEASETYPE
指定发布的类型,实际上就是编译后的文件的存放位置可选项为
SDK|DDK|PLATFORM|LOCAL|CUSTOM 其余选项等效OAK

DLLENTRY|EXEENTRY|NODLLENTRY
指定入口点

_TGTCPUFAMILY 

指定处理器所属家族可选x86|MIPS|SH|ARM

LINT_TYPE
可选all | lob | ind

TARGETEXEFILES
控制输出文件 可选NOLINK---不链接

TARGETTYPE
输出文件的类型 可选DYNLINK|PROGRAM|LIBRARY

WINCEDEBUG
文件发布类型 可选retail|debug 空=debug

CDEBUG_DEFINES
调试编译选项 WINCE_LMEM_DEBUG|DISABLE_OPTIMIZER|WINCESHIP|WINCE_OVERRIDE_CFLAGS

TARGET_PDB_NAME
PDB文件名

WINCEPROFILE
可选0|1

TGTCPUISANAME
处理器名称

编译器
x86

cxx cl386 -nologo
asm ml -nologo
-machine:iX86

SH3

cxx clsh -nologo
asm shasm
-machine:sh3

SH4
cxx clsh -nologo
asm shasm
-machine:sh4

MIPSII
cxx clmips -nologo
asm mipsasm
-machine:mips /-machine:-machine:mipsfpu

ARMV4                :

cxx clarm -nologo
asm armasm -coff
-machine:arm

ARMV4T
ARMV4I
clthumb -nologo
asm armasm -coff
-machine:thumb

    // Initialize default clients
    NewClient (KITL_SVC_DBGMSG, KITL_SVCNAME_DBGMSG, FALSE);
    NewClient (KITL_SVC_PPSH,   KITL_SVCNAME_PPSH,   FALSE);
    NewClient (KITL_SVC_KDBG,   KITL_SVCNAME_KDBG,   FALSE);

    return fStartKitl? StartKitl (TRUE) : TRUE;
}
这段代码主要完成两个动作：
1.装载函数指针，为后续代码的执行装载入口点。
2.注册kitl客户端，这些客户端实现传输层以后就是我们所需要的调试界面。
输入参数决定是否立即启动KITL服务，如果false的话就仅仅进行初始化等待后续动作使用startKitl来启动kitl.

我们再来看看NewClient的原型
static PKITL_CLIENT NewClient (UCHAR uId, LPCSTR pszSvcName, BOOL fAlloc)
{
    DEBUGCHK(IS_VALID_ID(uId));
    DEBUGCHK (!KITLClients[uId]);
    if (!fAlloc) {
        DEBUGCHK(IS_DFLT_SVC(uId));
        KITLClients[uId] = &DfltClnts[uId];
    } else if (!(KITLClients[uId] = (PKITL_CLIENT) AllocMem (HEAP_KITLCLIENT))) {
        return NULL;
    }
    memset (KITLClients[uId], 0, sizeof(KITL_CLIENT));
    KITLClients[uId]->ServiceId = uId;
    strcpy (KITLClients[uId]->ServiceName, pszSvcName);

    return KITLClients[uId];
}
这个被称为NewClient的函数所完成的功能十分的简单，先检查所需要创建的结构是否是系统默认服务所需要的，如果是的话就直接将该结构的指针指向全局结构DfltClnts并初始化结构，如果不是就申请相应的空间完成该结构的初始化。默认的服务有 KITL_SVCNAME_DBGMSG， KITL_SVCNAME_PPSH， KITL_SVCNAME_KDBG分别对应Debug信息的发布通道(Debug message)，文本控制台界面(PPshell)，和内核调试界面(kernel debug),在这里大家可能会问：为什么不统一使用固定的全局结构来存放这些服务的信息呢？原因很简单，因为这些"client"在WindowSCE下是可以注册扩充和注销的，这样用AllocMem所分配的内存空间在不再需要这些服务的时候可以释放掉，就可以避免不必要的浪费。另外KITLClients是这样定义的PKITL_CLIENT KITLClients[MAX_KITL_CLIENTS];所以kitl所能注册的client连同3个默认的服务一共最多可以有MAX_KITL_CLIENTS--128个。

下面继续沿着程序流往下看吧，kitlInit完成最基本的初始化动作即可启动kitl服务了。再看一下这个函数的原型。
static BOOL StartKitl (BOOL fInit)
{
    // KITL already started?
    if (!fInit && (KITLGlobalState & KITL_ST_DESKTOP_CONNECTED)) {
        return TRUE;
    }

    /*
     * When this function is called, the kernel hasn't yet been initialized,
     * so can't make any system calls.  Once the system has come up far
     * enough to handle system calls, KITLInitializeInterrupt() is called to complete
     * initialization.  This is indicated by the KITL_ST_MULTITHREADED flag in KITLGlobalState.
     */
    // Detect/initialize ethernet hardware, and return address information
    if (!OEMKitlInit (&Kitl))
        return FALSE;

    // verify that the Kitl structure is initialized.
    if (!Kitl.pfnDecode || !Kitl.pfnEncode || !Kitl.pfnEnableInt || !Kitl.pfnRecv || !Kitl.pfnSend
        || !Kitl.dwPhysBuffer || !Kitl.dwPhysBufLen || !Kitl.WindowSize || !Kitl.pfnGetDevCfg || !Kitl.pfnSetHostCfg) {
        return FALSE;
    }

    // Validate that address is not in free RAM area - the HAL should put it in a reserved
    // section of memory conditional on some environment var.
    if ((pTOC->ulRAMStart < Kitl.dwPhysBuffer + Kitl.dwPhysBufLen)
        && (pTOC->ulRAMEnd > Kitl.dwPhysBuffer)) {
        KITLOutputDebugString("\r\n!Debug Ethernet packet buffers in free RAM area - must set IMGEBOOT=1\r\n");
        return FALSE;
    }

    if (Kitl.dwPhysBufLen < (DWORD) 3 * KITL_BUFFER_POOL_SIZE) {
        KITLOutputDebugString("\r\n!Debug Ethernet buffer size too small, must be at least 0x%x bytes (3 * WindowSize * 2 * KITL_MTU)\r\n",
            3 * KITL_BUFFER_POOL_SIZE);
        return FALSE;
    }

    KITLGlobalState |= KITL_ST_KITLSTARTED; // indicate (to kdstub) that KITL has started

    // If the initialized flag is already set, we are being called from the power on routine,
    // so reinit the HW, but not any state.
    if (!(KITLGlobalState & KITL_ST_ADAPTER_INITIALIZED)) {
        // perform the initial handshake with the desktop
        if (!KITLConnectToDesktop ()) {
            KITLOutputDebugString ("\r\n!Unable to establish KITL connection with desktop!\r\n");
            return FALSE;
        }
       
        // Set up kernel function pointers
        pKITLInitializeInterrupt = KITLInitializeInterrupt;
        pKITLSend = KITLSend;
        pKITLRecv = KITLRecv;

        KITLGlobalState |= KITL_ST_ADAPTER_INITIALIZED;

        if (Kitl.dwBootFlags & KITL_FL_DBGMSG)
            SetKernelCommDev (KERNEL_SVC_DBGMSG, KERNEL_COMM_ETHER);
        if (Kitl.dwBootFlags & KITL_FL_PPSH)
            SetKernelCommDev (KERNEL_SVC_PPSH, KERNEL_COMM_ETHER);
        if (Kitl.dwBootFlags & KITL_FL_KDBG)
            SetKernelCommDev (KERNEL_SVC_KDBG, KERNEL_COMM_ETHER);

        // only perform cleanboot if it's connected at boot. Cleanboot flag is
        // ignored if it's started dynamically.
        if (fInit && (Kitl.dwBootFlags & KITL_FL_CLEANBOOT)) {
            extern ROMHDR *const volatile pTOC;     // Gets replaced by RomLoader with real address
            // just clear the magic nOEMKitlInitumber (see SC_SetCleanRebootFlag)
            // NOTE: We can NOT call SC_SetCleanRebootFlag here since logPtr isn't
            // initialized yet.
            ((fslog_t *)((pTOC->ulRAMFree + MemForPT) | 0x20000000))->magic1 = 0;
        }
        // if OEM calls KitlInit (FALSE), KITLInitializeInterrupt will
        // not be called in SystemStartupFuc. We need to initialize
        // interrupt here (when RegisterClient is called)
        if (fKITLcsInitialized && !InSysCall ()) {
            KITLInitializeInterrupt ();
        }
    }

    LOG (KITLGlobalState);
    return TRUE;
}
启动代码首先判断是否已经启动kitl服务，之后调用OEMKitlInit，该函数并不在private目录下实现，通常windowsCE需要用户定制的代码都是这种结构---MS提供的代码接口，用户自己完成相应的OEM部分，通常这些代码都是与具体的硬件平台相关的代码。kitl的OEM代码在HAL中实现，通常在platform\kernel\hal\.下，这部分的代码我们先跳过，看完startkitl的全貌再回过头逐个说明。OEMkitlInit为kitl初始化硬件传输介质，同时分配初始化一些kitl所需要的全局结构。随后startkitl继续检查OEMkitlInit所分配和初始化的KITL结构和内存区域是否有效后设置kitl的全局标示KITL_ST_KITLSTARTED；之后设置终端服务程序以及接收和发送程序的入口点后设置全局标示KITL_ST_ADAPTER_INITIALIZED。现在传输介质已经全部就绪，通过SetKernelCommDev设置kernel通过ethernet传送调试信息，调试输入，以及CESH控制台。再后调用KITLInitializeInterrupt完成中断的初始化kitl启动的过程就结束了。
   紧接着我们来看看，OEMkitlInit都须要我们干什么。下面用SMDK2440的kitl为实例来进行分析：
BOOL OEMKitlInit (PKITLTRANSPORT pKitl)
{
    KITLOutputDebugString ("+OEMKitlInit\n");
    RETAILMSG(1, (_T("+OEMKitlInit\r\n")));
    // try to find a transport available
    if (!InitEther (pKitl)
        && !InitParallelSerial (pKitl)) {
        KITLOutputDebugString ("Unable to initialize KITL Transports!\n");
        return FALSE;
    }

    gpKitl = pKitl;
    KITLOutputDebugString ("-OEMKitlInit\n");
    RETAILMSG(1, (_T("-OEMKitlInit\r\n")));
    return TRUE;
}

事实上工作很简单，调用InitEther (pKitl) 和 !InitParallelSerial (pKitl)初始化网卡直接把初始化的KITL全局结构返回就是所有的工作。这儿的InitParallelSerial是一个dummy永远返回false,也就是说这里没有对serial&parallel transport进行支持。真正的工作量集中在InitEther之后。事实上InitEther 和 InitParallelSerial只要任意的实现一个就可以达到建立传输界面的目的.下面，我们继续看后面的代码。
BOOL InitEther(PKITLTRANSPORT pKitl)
{
    EDBG_ADAPTER adp;
    DWORD dwDHCPLeaseTime;
    DWORD dwSubnetMask;

    KITLOutputDebugString ("+InitEther\n");

    memset (&adp, 0, sizeof(adp));
    memset (pKitl, 0, sizeof (KITLTRANSPORT));

    // use existing code for ether initialization
    if (!OEMEthInit (&adp))
        return FALSE;

    // we are going to completely ignore the info in bootargs and the adaptor info
    // returned from OEMEthInit, except MAC address. Just to prove that KITL will connect standalone

    // get the MAC address
    MyAddr.wMAC[0] = adp.Addr.wMAC[0];
    MyAddr.wMAC[1] = adp.Addr.wMAC[1];
    MyAddr.wMAC[2] = adp.Addr.wMAC[2];
    //MyAddr = adp.Addr;
   
    CreateDeviceName(&MyAddr, pKitl->szName);
    KITLOutputDebugString ("Using device name: %s\n", pKitl->szName);

    // If we haven't been given an IP address from our loader (or if we're not using static IP), get an IP address
    // from a DHCP server.
    if (adp.Addr.dwIP)
    {
        // Static IP or we got the IP from our bootloader...
        MyAddr.dwIP     = adp.Addr.dwIP;
        dwSubnetMask    = 0;    // Don't care about subnet mask...
        dwDHCPLeaseTime = adp.DHCPLeaseTime;
    }
    else
    {
        // Get a DHCP address...
        if (!EbootGetDHCPAddr (&MyAddr, &dwSubnetMask, &dwDHCPLeaseTime))
            return FALSE;
    }
   
    MyAddr.wPort = htons (EDBG_SVC_PORT);
    KITLOutputDebugString ("Device %s, IP %s, Port %d\n", pKitl->szName, inet_ntoa (MyAddr.dwIP), htons (MyAddr.wPort));

    // initialize KITL Ethernet transport layer
    if (!KitlEtherInit (&MyAddr, dwDHCPLeaseTime)) {
        KITLOutputDebugString ("Unable to initialize KITL Ether transport\n");
        return FALSE;
    }
   
    // fill in the blanks in KITLTRANSPORT structure.
    pKitl->FrmHdrSize = KitlEtherGetFrameHdrSize ();
    pKitl->Interrupt = (UCHAR) adp.SysIntrVal;
    pKitl->dwPhysBuffer = EDBG_PHYSICAL_MEMORY_START;
    pKitl->dwPhysBufLen = 0x20000;                      // 128K of buffer available
    pKitl->dwBootFlags = 0;
    pKitl->WindowSize = EDBG_WINDOW_SIZE;
    pKitl->pfnDecode = KitlEtherDecodeUDP;
    pKitl->pfnEncode = KitlEtherEncodeUDP;
    pKitl->pfnSend = EthSend;
    pKitl->pfnRecv = OEMEthGetFrame;
    pKitl->pfnEnableInt = KitlEthEnableInts;
    pKitl->pfnSetHostCfg = SetHostCfg;
    pKitl->pfnGetDevCfg = GetDevCfg;

    KITLOutputDebugString ("-InitEther\n");

    return TRUE;
}
这个函数完成的工作主要是调用OEMEthInit初始化网卡的服务程序及获得相应的IP和MAC，如果IP无效则用DHCP动态获得IP.通过MAC值产生一个标示，这个标示用来给PB的IDE使用。刚才的我们在kitlInit中看到除了检查OEMkitlInit的返回值之外还检查了KITL结构，该结构的这些特征值正是在这儿设置的。在这儿可以看到pKitl->pfnDecode pKitl->pfnEncode pKitl->pfnSetHostCfg pKitl->pfnGetDevCfg 以及kitl所用的中断号这些都是OEM代码，也就是用于传输的编码和解码形式以及配置函数都是可以自己定义的，这样一来也就无所谓使用什么传输介质作为KITK
的transport了，这就为使用1394或者是USB这一类的传输链路也能充当传输界面作了准备。 OEMEthInit函数是用于初始化传输介质--以太网卡。这部分代码直接是硬件控制代码，我们来简单的看一下。
BOOL
OEMEthInit(EDBG_ADAPTER *pAdapter)
{
 PBYTE pBaseIOAddress;

 // Driver globals from the bootloader.
 //
 if (pDriverGlobals->eth.EbootMagicNum == EBOOT_MAGIC_NUM)
 {
  memcpy(pAdapter, &pDriverGlobals->eth.TargetAddr, sizeof(EDBG_ADAPTER));

  switch(pDriverGlobals->misc.EbootDevice)
  {
  case(DOWNLOAD_DEVICE_PCMCIA): // NE2000 CF card.
   pBaseIOAddress  = (PBYTE)PCMCIA_Init();
   if (pBaseIOAddress)
   {
    // Initialize the built-in Ethenet controller.
    //
    if (!NE2000Init((PBYTE)pBaseIOAddress, 1, pAdapter->Addr.wMAC))
    {
     EdbgOutputDebugString("ERROR: OEMEthInit: Failed to initialize Ethernet controller.\r\n");
     return(FALSE);
    }
   }
   pfnEDbgInit            = NE2000Init;
   pfnEDbgEnableInts      = NE2000EnableInts;
   pfnEDbgDisableInts     = NE2000DisableInts;
   pfnEDbgGetPendingInts  = NE2000GetPendingInts;
   pfnEDbgGetFrame        = NE2000GetFrame;
   pfnEDbgSendFrame       = NE2000SendFrame;
   pfnEDbgReadEEPROM      = NE2000ReadEEPROM;
   pfnEDbgWriteEEPROM     = NE2000WriteEEPROM;
   pfnEDbgSetOptions      = NE2000SetOptions;
  #ifdef IMGSHAREETH
   pfnCurrentPacketFilter = Ne2000CurrentPacketFilter;
   pfnMulticastList  = NE2000MulticastList;
  #endif // IMGSHAREETH.
   break;
  case(DOWNLOAD_DEVICE_CS8900): // CS8900A.
   // Initialize the CS8900.
   //
   if (!CS8900DBG_Init((PBYTE)CS8900DBG_IOBASE, CS8900DBG_MEMBASE, pAdapter->Addr.wMAC))
   {
    EdbgOutputDebugString("ERROR: OEMEthInit: CS8900 initialization failed.\r\n");
    return(FALSE);
   }

   pfnEDbgInit  = CS8900DBG_Init;
   pfnEDbgEnableInts      = CS8900DBG_EnableInts;
   pfnEDbgDisableInts     = CS8900DBG_DisableInts;
   pfnEDbgGetFrame  = CS8900DBG_GetFrame;
   pfnEDbgSendFrame = CS8900DBG_SendFrame;
   pfnEDbgGetPendingInts  = CS8900DBG_GetPendingInts;
  #ifdef IMGSHAREETH
   pfnCurrentPacketFilter = CS8900DBG_CurrentPacketFilter;
   pfnMulticastList = CS8900DBG_MulticastList;
  #endif // IMGSHAREETH.
   break;
  default:
   EdbgOutputDebugString("ERROR: OEMInit: Unknown download NIC (0x%x).\r\n", pDriverGlobals->misc.EbootDevice);
   return(FALSE);
 
 }}
 else
 {
  // TODO - retrieve CS8900 MAC address from flash...
  // TODO - intialize the CS8900 from scratch...
 }

 EdbgOutputDebugString("::: OEMEthInit() IP Address : %s\r\n", inet_ntoa(pAdapter->Addr.dwIP));
 EdbgOutputDebugString("::: OEMEthInit() Netmask    : %s\r\n", inet_ntoa(pDriverGlobals->eth.SubnetMask));

 if (pDriverGlobals->misc.EbootDevice == DOWNLOAD_DEVICE_PCMCIA)
  pAdapter->SysIntrVal    = SYSINTR_PCMCIA_LEVEL;
 else
  pAdapter->SysIntrVal    = SYSINTR_ETHER;

 pAdapter->DHCPLeaseTime = DEFAULT_DHCP_LEASE;
 pAdapter->EdbgFlags     = pDriverGlobals->eth.EdbgFlags;
  
#ifdef IMGSHAREETH
    VBridgeInit();
    VBridgeKSetLocalMacAddress((char *)pAdapter->Addr.wMAC);
#endif // IMGSHAREETH.

 return(TRUE);
}
   
这个函数看起来很复杂其实真正的工作并不多，首先判断是不是由eboot启动的，如果已经eboot中已经完成了对以太网卡的初始化动作就直接使用网卡并装载/挂接网卡所需的函数和网卡信息，否则就需要自己设置网卡的MAC地址和初始化网卡(事实上以上函数并没有对这部分代码进行实现，这就是很多使用2410/2440的用户在不使用eboot启动的情况下总是不能使用kitl的原因--找不到eboot在DriverGlobal中留下的magic NUMBER)。这儿之所以有NE2000和Cs8900的区分是因为SMDK2440可以使用PCMICA挂接Ne2000兼容的NIC或板载CS8900，后面设置中断标示有两个分支也是这个原因。
IMGSHAREETH的部分是Vbridge的部分,为什么要使用这个叫vbridge的东西呢？我们看看下面的假设。
为了建立kitl占用了一个网卡资源，而该资源如果在windowsCE下复用(该设备同时被两个驱动使用1.kitl 2.windowsCE NIC driver)的话会不会导致问题呢？看看下面的两个函数。
    VBridgeInit();
    VBridgeKSetLocalMacAddress((char *)pAdapter->Addr.wMAC);
    该函数在内核调试传输通道和tcp/ip&windsock之间建立一个虚拟的网桥v-bridge，在外部看来vbridge就像在mac层一样，vbridge一方面和硬件通讯建立传输的物理界面，另一方面和调试所需的EDBG和vmini.dll提供相同的逻辑界面，在更高的层面vmini.dll就像一个专门的网卡一样支持NDIS以至于tcp/ip协议栈。这样我们就可以一方面使用网卡做调试另外一方面仍然能让windowsCE使用网卡通讯，对于windowCE而言所使用的网卡不在是与底层对应的网络设备，而是通过vbridge虚拟出来的网络设备，所以在直接使用SMDK24XX的bsp编译出来的系统网卡显示为vmini就是这个原因。这个时候网卡驱动怎么配置呢？答案很简单，就是不要网卡驱动，因为我们已经从vbridge中抽象(虚拟---用一个网卡)出一个网卡了，原来的网卡驱动也就不在需要了。
   
从上面的OemKitlInit到InitEther都是OEM代码，目的在于使Kitl与相应的transport的物理介质联系起来，也就是构建kitl的硬件抽象层，在一个kitl初始化代码中中只有这部分工作(OEM代码)是必要的，其余的代码直接使用MS编译好的lib就可以了。尽管如此我们还是继续看下面的代码，虽然这对我们来说不是必须的不过对一个程序要有全面的认识，框架上的重要模块都是需要了解和认识的。

看完了这一系列的OEM代码，继续看看StartKitl里面我们没有看完的部分在设置启动标示位之前做了2个检查分别是检查buffer的位置是否在编译系统的时候预留下来以及是否有足够的长度可用。这个内存区域不是动态分配的，而是在bsp的内存配置文件中指定并保留下来的(见bsp file目录下的config.bib)。再下来进行一个KITLConnectToDesktop的动作，这个看名字就知道作用了。就是和PC连接。同样看看代码：
static BOOL KITLConnectToDesktop (void)
{
    // we'll use the PpfsFmtBuf for send buffer since ppfs can't be started yet at this stage
    //
    PKITL_HDR pHdr = (PKITL_HDR) (PpfsFmtBuf + Kitl.FrmHdrSize);
    PKITL_DEV_TRANSCFG pCfg = (PKITL_DEV_TRANSCFG) KITLDATA(pHdr);
    USHORT cbData = sizeof (PpfsFmtBuf) - Kitl.FrmHdrSize - sizeof (KITL_HDR) - sizeof (KITL_DEV_TRANSCFG);

    if (!Kitl.pfnGetDevCfg ((LPBYTE) (pCfg+1), &cbData))
        return FALSE;

    memset (pHdr, 0, sizeof (KITL_HDR));
    pHdr->Id = KITL_ID;
    pHdr->Service = KITL_SVC_ADMIN;
    pHdr->Cmd = KITL_CMD_TRAN_CONFIG;
    cbData += sizeof (KITL_DEV_TRANSCFG);
    pCfg->wLen = cbData;
    pCfg->wCpuId = KITL_CPUID;
    memcpy (pCfg->szDevName, Kitl.szName, KITL_MAX_DEV_NAMELEN);
    cbData += sizeof (KITL_HDR);

    return KitlSendFrame (PpfsFmtBuf, cbData)
        && KITLPollResponse (FALSE, ChkCnxDsktp, TranCnxDsktp, (LPVOID) cbData);
}
结构PKITL_HDR就是kilt的传输头格式，而PKITL_DEV_TRANSCFG信息则是传输设备的设置。首先通过调用Kitl.pfnGetDevCfg得到传输设备的信息，Kitl.pfnGetDevCfg是函数指针，在对以太网卡初始化的时候指向OEM代码中的GetDevCfg函数。通过这个函数得到设备信息(smdk2410的bsp中这儿返回的就是IP地址)。然后再继续设置传输头的标示，类型，命令等等信息，然后就是发送数据了，具体的动作就是调用KitlSendFrame。(To be continue...)

BOOL KitlSendFrame (LPBYTE pbFrame, WORD cbData)
{
    if (!Kitl.pfnEncode (pbFrame, cbData)) {
        KITLOutputDebugString ("!KitlSendFrame: transport failed to encode the data frame\r\n");
        return FALSE;
    }

    return KitlSendRawData (pbFrame, (USHORT) (cbData + Kitl.FrmHdrSize + Kitl.FrmTlrSize));
}
这个函数首先调用KitlEtherEncodeUDP对数据帧进行编码为UDP协议需要的格式。然后调用 KitlSendRawData将数据送出至PC.
BOOL KitlSendRawData (LPBYTE pbData, WORD wLength)
{
    BOOL fRet;
    if (!(KITLGlobalState & KITL_ST_MULTITHREADED) || InSysCall())
        fRet = Kitl.pfnSend (pbData, wLength);
    else if (IsDesktopDbgrExist ())
        fRet = KCall((PKFN) Kitl.pfnSend, pbData, wLength);
    else {
        EnterCriticalSection (&KITLKCallcs);
        fRet = Kitl.pfnSend (pbData, wLength);
        LeaveCriticalSection (&KITLKCallcs);
    }
    return fRet;
}
首先判定系统没有在调度中且当前代码在不可剥夺状态状态运行，通过EthSend调用OEMEthSendFrame将数据送出就完成了工作。另外两个分支与我们分析的程序流没有关系先放一下。
BOOL
OEMEthSendFrame(
    BYTE *pData,     // IN - Data buffer
    DWORD dwLength)  // IN - Length of buffer
{
    int retries = 0;

    while (retries++ < 4) {
        if (!pfnEDbgSendFrame(pData, dwLength))
  {
#ifdef IMGSHAREETH
   ProcessVMiniSend();
#endif //IMGSHAREETH
            return TRUE;
  }
        else
            EdbgOutputDebugString("!OEMEthSendFrame failure, retry %u\n",retries);
    }
    return FALSE;
}
在发送数据帧的过程中专门有处理vMini发送的过程。由于kitl本身就不是很简单我们以后后面再用专门的文章说明vbridge的工作过程。完成了发送，我们继续下面的过程。
BOOL KITLPollResponse (BOOL fUseSysCalls, PFN_CHECK pfnCheck, PFN_TRANSMIT pfnTransmit, LPVOID pData)
{
    DWORD dwLoopCnt = 0, dwLoopMax = MIN_POLL_ITER;
    DWORD dwStartTime = CurMSec;
    int   nTimeMax = MIN_POLL_TIME;  // start with 1 sec
    BOOL  fUseIter = FALSE, fUseTick = FALSE;

    while (!pfnCheck (pData)) {
        //
        // if we've already connected with desktop, use the desktop
        // "Retransmit" package to determine if we need to retransmit
        //
        if (!(KITLGlobalState & KITL_ST_DESKTOP_CONNECTED)) {
            if (fUseTick) {
                if ((int) (CurMSec - dwStartTime) > nTimeMax) {
                    // retransmit
                    if (!pfnTransmit (pData, fUseSysCalls))
                        return FALSE;
                    dwStartTime = CurMSec;
                    if (nTimeMax < MAX_POLL_TIME)
                        nTimeMax <<= 1;
                }
            } else if (fUseIter || (dwStartTime == CurMSec)) {
                // if time isn't moving for a while, we'll
                // use iteration.
                if (dwLoopCnt ++ > dwLoopMax) {
                    if (!pfnTransmit (pData, fUseSysCalls))
                        return FALSE;
                    if (dwLoopMax < MAX_POLL_ITER)
                        dwLoopMax <<= 1;
                    dwLoopCnt = 0;
                    fUseIter = TRUE;
                }
            } else {
                // time is moving, just use tick from here
                fUseTick = TRUE;
            }
        }
        if (!KITLPollData(fUseSysCalls, pfnTransmit, pData)) {
            return FALSE;
        }
    }
    return TRUE;
}
static BOOL TranCnxDsktp (LPVOID pParam, BOOL fUseSysCalls)
{
    return KitlSendFrame (PpfsFmtBuf, (WORD) (DWORD) pParam);
}
这个函数的主体是一个循环，终止的条件是!pfnCheck (pData)，这个函数是由前面传递进来的，返回值为KITLGlobalState & KITL_ST_DESKTOP_CONNECTED，也就是说在得到桌面连接之前是不会返回的也就是说启动kitl以后不与桌面计算机连接windowsCE的是无法启动的。由于从dwStartTime定义到dwStartTime == CurMSec的判定仅仅需要很少的时间就可以完成这段时间内CurMSec是不会被改写的就可以通过循环进行超时检查
并通过TranCnxDsktp重新发送数据，直到KITLPollData设置KITLGlobalState。
static BOOL KITLPollData(BOOL fUseSysCalls, PFN_TRANSMIT pfnTransmit, LPVOID pData)
{
    LPBYTE pRecvBuf = PollRecvBuf;
   
    if (fUseSysCalls && (KITLGlobalState & KITL_ST_MULTITHREADED)
        && !(pRecvBuf = _alloca(KITL_MTU))) {
        KITLOutputDebugString("!KITLPollData: STACK OVERFLOW!\r\n");
        return FALSE;
    }
    HandleRecvInterrupt(pRecvBuf, fUseSysCalls, pfnTransmit, pData);
    return TRUE;
}
由于我们上面传来的fUseSysCalls参数为false所以前一段检查操作并不进行。直接调用 HandleRecvInterrupt。

void HandleRecvInterrupt(UCHAR *pRecvBuf, BOOL fUseSysCalls, PFN_TRANSMIT pfnTransmit, LPVOID pData)
{
    WORD wLen = KITL_MTU;
    BOOL fFrameRecvd;

    // Receive data into buffer
    do {
        if (!fUseSysCalls)
            fFrameRecvd = Kitl.pfnRecv (pRecvBuf, &wLen);
        else if (IsDesktopDbgrExist ())
            fFrameRecvd = KCall((PKFN) Kitl.pfnRecv, pRecvBuf, &wLen);
        else {
            EnterCriticalSection (&KITLKCallcs);
            fFrameRecvd = Kitl.pfnRecv (pRecvBuf, &wLen);
            LeaveCriticalSection (&KITLKCallcs);
        }
        if (fFrameRecvd) {
            ProcessRecvFrame (pRecvBuf,wLen,fUseSysCalls, pfnTransmit, pData);
            wLen = KITL_MTU;
        }
    } while (fFrameRecvd);
}
通过Kitl.pfnRecv调用pfnEDbgGetFrame指向的CS8900DBG_GetFrame读取当前的数据帧送交ProcessRecvFrame处理。注意，这儿的pfnEDbgGetFrame并不是通过DMA或者是网卡传来的中断启动的而是使用查询的方法进行的，这就是为什么这儿并没有启动中断仍然能够使用以太网卡进行数据传输数据的原因。随后，我们将计算机端送来的数据送交ProcessRecvFrame处理。

static BOOL ProcessRecvFrame(UCHAR *pFrame, WORD wMsgLen, BOOL fUseSysCalls, PFN_TRANSMIT pfnTransmit, LPVOID pData)
{
    KITL_HDR *pMsg;
    KITL_CLIENT *pClient = NULL;
    BOOL fRet = TRUE;
    UCHAR RxBufOffset;
    WORD  wDataLen;
    UCHAR ClientIdx;
    // let the transport layer decode the frame
    if (!(pMsg = (KITL_HDR *) Kitl.pfnDecode (pFrame, &wMsgLen))) {
        KITL_DEBUGMSG(ZONE_RECV, ("ProcessRecvFrame: Received Unhandled frame\n"));
        return FALSE;
    }

    // is it a valid KITL message?
    if (pMsg->Id != KITL_ID) {
        KITL_DEBUGMSG(ZONE_WARNING,("KITL: Got unrecognized Id: %X\r\n",pMsg->Id));
        return FALSE;
    }
   
    // Validate length
    if (wMsgLen < KITL_DATA_OFFSET) {
        KITL_DEBUGMSG(ZONE_WARNING,("KITL: Invalid length %u\n",wMsgLen));
        return FALSE;
    }
    if (KITLDebugZone & ZONE_FRAMEDUMP)
        KITLDecodeFrame("<<KITLRecv",pMsg, wMsgLen);
   
    // Check for administrative messages
    if (pMsg->Service == KITL_SVC_ADMIN)
        return ProcessAdminMsg(pMsg, wMsgLen, fUseSysCalls, pfnTransmit, pData);

    // Service Id is index into KITLClients array
    ClientIdx = pMsg->Service;
    if (ClientIdx >= MAX_KITL_CLIENTS) {
        KITL_DEBUGMSG(ZONE_WARNING,("!ProcessKITLMsg: Invalid ServiceId: %u\n",pMsg->Service));
        return FALSE;
    }

    pClient = KITLClients[ClientIdx];
   
    // Until we complete registering, only handle administrative messages
    if (!pClient || !(pClient->State & KITL_CLIENT_REGISTERED)) {
        KITL_DEBUGMSG(ZONE_WARNING,("!ProcessKITLMsg: Client %u not registered\n",ClientIdx));
        return FALSE;
    }
    if (pMsg->Service != pClient->ServiceId) {
        KITL_DEBUGMSG(ZONE_WARNING,("!ProcessKITLMsg: Mismatch in service Id for Client %u (Got %u, expect %u)\n",
                                    ClientIdx,pMsg->Service,pClient->ServiceId));
        return FALSE;
    }

    if (pClient->State & KITL_USE_SYSCALLS) {
        if (fUseSysCalls) 
            EnterCriticalSection(&pClient->ClientCS);
        else if (pClient->ClientCS.OwnerThread) {
            // We can't get the client CS, and it is owned - just toss frame
            KITL_DEBUGMSG(ZONE_WARNING,("!KITL(%u) tossing msg %u (Can't get CS)\n",ClientIdx, pMsg->SeqNum));
            return FALSE;
        }
    }

    // we've being in sync with the desktop
    pClient->State |= KITL_SYNCED;
   
    // Put flags and seq # to LEDs
    KITL_DEBUGLED(LED_PEM_SEQ, ((DWORD) pMsg->Flags << 24) | pMsg->SeqNum);
   
    // OK, valid message, see if it's an ACK
    if (pMsg->Flags & KITL_FL_ACK) {
        KITL_DEBUGMSG(ZONE_RECV,("KITL(%u): Received ack for msg %u, Tx window: %u,%u\n",
                                 ClientIdx,pMsg->SeqNum, pClient->AckExpected,pClient->TxSeqNum));
        // ACKs acknowledge all data up to the ACK sequence #
        while (SEQ_BETWEEN(pClient->AckExpected, pMsg->SeqNum, pClient->TxSeqNum)) {       
            if ((pClient->State & KITL_USE_SYSCALLS) &&
                ((pClient->CfgFlags & KITL_CFGFL_STOP_AND_WAIT) ||
                 (SEQ_DELTA(pClient->AckExpected, pClient->TxSeqNum) >= pClient->WindowSize-1) ||
                 !(KITLGlobalState & KITL_ST_INT_ENABLED))) {
                if (fUseSysCalls)
                    SetClientEvent(pClient,pClient->evTxFull);
                else {
                    // Can't process message at this time...
                    KITL_DEBUGMSG(ZONE_WARNING,("!KITL(%u): Tossing ACK %u (Can't set event)\n",
                                                ClientIdx, pMsg->SeqNum));
                    return FALSE;
                }
            }
            // Stop retransmission timer.
            TimerStop(pClient, (UCHAR)(pClient->AckExpected % pClient->WindowSize),fUseSysCalls);
            SEQ_INC(pClient->AckExpected);
        }
        goto ProcessKITLMsg_exit;
    }

    // Handle NACKs - retransmit requested frame if it is in our Tx window
    if (pMsg->Flags & KITL_FL_NACK) {
        KITL_DEBUGMSG(ZONE_WARNING,("KITL(%u): Received NACK for msg %u, Tx window: %u,%u\n",
                                    ClientIdx,pMsg->SeqNum, pClient->AckExpected,pClient->TxSeqNum));
        if (SEQ_BETWEEN(pClient->AckExpected, pMsg->SeqNum, pClient->TxSeqNum)) {
            UCHAR Index = pMsg->SeqNum % pClient->WindowSize;
            if (pClient->TxFrameLen[Index]) {
                // Restart retransmission timer (note we can't start timers if syscalls
                // are disabled, but this shouldn't screw us up, we'll just potentially
                // retransmit an extra frame if the timer fires before we get the ACK)
                if (fUseSysCalls)
                    TimerStop(pClient,Index,fUseSysCalls);
                RetransmitFrame(pClient, Index, fUseSysCalls);
                if (fUseSysCalls)
                    TimerStart(pClient,Index,KITL_RETRANSMIT_INTERVAL_MS,fUseSysCalls);
            }
            else
                KITL_DEBUGMSG(ZONE_WARNING,("!KITL(%u): NACK in window, but TxFrameLen empty!\n",ClientIdx));
        }
        else
            KITL_DEBUGMSG(ZONE_WARNING,("!KITL(%u): Received NACK outside of TX window: Seq: %u, Window: %u,%u\n",
                                        ClientIdx,pMsg->SeqNum,pClient->AckExpected,pClient->TxSeqNum));
        goto ProcessKITLMsg_exit;
    }
   
    // Data frame.  Place in appropriate slot in Rx buffer pool. Note that we defer acking
    // received frames until they are read from the buffer, in KITLRecv.
    RxBufOffset = pMsg->SeqNum % pClient->WindowSize;

    if (! SEQ_BETWEEN(pClient->RxSeqNum, pMsg->SeqNum, pClient->RxWinEnd)) {
        UCHAR uLastACK = (UCHAR) (pClient->RxWinEnd - pClient->WindowSize - 1);

        KITL_DEBUGMSG (ZONE_WARNING, ("KITL(%u): Received msg outside window: Seq:%u, Win:%u,%u\n",
                              ClientIdx,pMsg->SeqNum,pClient->RxSeqNum,pClient->RxWinEnd));

        // Special case to handle lost ACKs - if an ack is dropped, our Rx window will have
        // advanced beyond the seq # of the retransmitted frame.  Since ACKs ack all messages
        // up to the ack #, we only need to check the last frame.
        if (pMsg->SeqNum == uLastACK) {
            KITL_DEBUGMSG(ZONE_WARNING,("KITL(%u): Lost ACK (seq: %u, win: %u,%u)\n",ClientIdx,
                                        pMsg->SeqNum,uLastACK,pClient->RxWinEnd));
            SendAckNack (TRUE, pClient, uLastACK);
        }
    } else if (pClient->RxFrameLen[RxBufOffset] != 0) {
        // If all our buffers are full, toss frame (will be acked when data is read in KITLRecv)
        KITL_DEBUGMSG(ZONE_WARNING,("KITL(%u): Received duplicate (Seq:%u), slot %u already full. Win: %u,%u\n",
                                    ClientIdx,pMsg->SeqNum,RxBufOffset,pClient->RxSeqNum,pClient->RxWinEnd));
    } else {
        DWORD OldProcPerms;

        // If we're in non-preemptible mode, can't set the receive event, so just toss message
        // and wait for retry.
        if (!fUseSysCalls && (pClient->State & KITL_USE_SYSCALLS)) {
            KITL_DEBUGMSG(ZONE_WARNING,("KITL(%u): Tossing frame %u (Can't signal Rx event)\n",
                                        ClientIdx,pMsg->SeqNum));
            return FALSE;
        }

        KITL_DEBUGMSG(ZONE_RECV,("KITL(%u): Received frame Seq: %u, len: %u, putting in slot %u\n",
                                 ClientIdx, pMsg->SeqNum, wMsgLen, RxBufOffset));
        // If frames were dropped, send NACK (only allow one outstanding NACK)
        if (pMsg->SeqNum != pClient->RxSeqNum) {
            KITL_DEBUGMSG(ZONE_WARNING,("!KITL(%u): Dropped frame (seq: %u, win: %u,%u)\n",
                                        ClientIdx,pMsg->SeqNum,pClient->RxSeqNum, pClient->RxWinEnd));

            if (!(pClient->State & KITL_NACK_SENT)) {
                SendAckNack(FALSE, pClient, pClient->RxSeqNum);
                pClient->State |= KITL_NACK_SENT;          
            }
        }
        else
            pClient->State &= ~KITL_NACK_SENT;
       
        // Copy data to receive buffer, unblock anyone waiting, and close receive window
        wDataLen = wMsgLen - (WORD)KITL_DATA_OFFSET;
        if (wDataLen == 0)
            KITL_DEBUGMSG(ZONE_WARNING,("!KITL: Received data message with 0 length!\n"));
        if (pClient->ProcPerms) {
            // acquire permission of pClient and add it to current thread
            ACCESSKEY aKey = GETCURKEY() | pClient->ProcPerms;
            SWITCHKEY (OldProcPerms, aKey);
        }
        memcpy(pClient->pRxBufferPool + RxBufOffset*KITL_MTU,KITLDATA(pMsg), wDataLen);
        if (pClient->ProcPerms) {
            SETCURKEY (OldProcPerms);           
        }
        pClient->RxFrameLen[RxBufOffset] = wDataLen;

        if (pClient->State & KITL_USE_SYSCALLS)
            // If we get here, we know that fUseSysCalls is TRUE
            SetClientEvent(pClient,pClient->evRecv);
       
        // Close receive window
        while (pClient->RxFrameLen[pClient->RxSeqNum % pClient->WindowSize] &&
               (SEQ_DELTA(pClient->RxSeqNum, pClient->RxWinEnd) >= 1)) {
            KITL_DEBUGMSG(ZONE_RECV,("Rx win: %u,%u, usesyscalls: %u\n",pClient->RxSeqNum, pClient->RxWinEnd, fUseSysCalls));
            SEQ_INC(pClient->RxSeqNum);
        }
    }
   
ProcessKITLMsg_exit:

    if (fUseSysCalls && (pClient->State & KITL_USE_SYSCALLS))
        LeaveCriticalSection(&pClient->ClientCS);
   
    return fRet;
}
ProcessRecvFramed是一个近200行的函数，样子很吓人。它是数据帧的解析和处理模块的主体。我们从上到下看看都干了些什么。先调用KitlEtherDecodeUDP将来自主机的数据帧解码为KITL_HDR结构，然后效验魔法数KITL_ID，确认该帧的信息的有效性以及数据长度是否有效，如果ZONE_FRAMEDUMP标签是打开的则需要则解析Frame的内容并记录下来(输出到调试界面，初始化流程并不包含该信息)，然后判定该数据帧描述的信息是否属于管理命令(连接桌面，新建client等等),如果是则调用ProcessAdminMsg进行处理。
static BOOL ProcessAdminMsg(KITL_HDR *pHdr, WORD wMsgLen, BOOL fUseSysCalls, PFN_TRANSMIT pfnTransmit, LPVOID pData)
{
    KITL_CLIENT *pClient = NULL;   
   
    switch (pHdr->Cmd)
    {
        case KITL_CMD_SVC_CONFIG:
        {
            KITL_SVC_CONFIG_DATA *pCfg = (KITL_SVC_CONFIG_DATA *) KITLDATA (pHdr);
            int i, iStart;
           
            if (wMsgLen != (KITL_DATA_OFFSET + sizeof(KITL_SVC_CONFIG_DATA))) {
                KITL_DEBUGMSG(ZONE_WARNING,("!ProcessAdminMsg: Invalid legnth for CONFIG msg: %u\n",wMsgLen));
                return FALSE;
            }

            // Find client struct
            if ((i = ChkDfltSvc (pCfg->ServiceName)) < 0)
                i = HASH(pCfg->ServiceName[0]);

            iStart = i;

            while (KITLClients[i]) {
                // For multi instanced services, skip clients that are already registered
                if (!strcmp(KITLClients[i]->ServiceName,pCfg->ServiceName) &&
                    (!(KITLClients[i]->State & KITL_CLIENT_REGISTERED) || !(KITLClients[i]->CfgFlags & KITL_CFGFL_MULTIINST))) {
                    pClient = KITLClients[i];
                    break;
                }
                if (i < NUM_DFLT_KITL_SERVICES)
                    // no dups for default services
                    break;

                if (MAX_KITL_CLIENTS == ++ i)
                    i = NUM_DFLT_KITL_SERVICES;

                if (iStart == i)
                    break;  // couldn't find a client
            }

            if (!pClient || !(pClient->State & (KITL_CLIENT_REGISTERING|KITL_CLIENT_REGISTERED))) {
                KITL_DEBUGMSG(ZONE_WARNING,("!Received config for unrecognized service %s\n",
                                            pCfg->ServiceName));
                return TRUE;
            }

            if (fUseSysCalls)
                EnterCriticalSection(&pClient->ClientCS);

            // Send config to peer, unless this was a response to our cmd
            if (!(pHdr->Flags & KITL_FL_ADMIN_RESP)) {
                // ack this config message
                SendConfig(pClient,TRUE);

                // Stop any pending transfers, reset sequence #s, etc

                // WARNING - can cause lost transmit data if the other side doesn't get
                // our config, and retries the config command.
                if (pClient->State & KITL_SYNCED) {
                    ResetClientState(pClient);
                }
            }

            //
            // we got the response from desktop, connecting the client
            //
            KITL_DEBUGMSG(ZONE_INIT, ("ProcessAdminMsg: Receive Config message for service %s\n", pClient->ServiceName));
            pClient->State &= ~(KITL_WAIT_CFG|KITL_CLIENT_REGISTERING);
            pClient->State |= KITL_CLIENT_REGISTERED;
            // Set our event in case anyone is waiting for config info
            if (fUseSysCalls)
                SetClientEvent(pClient,pClient->evCfg);

           
            if (fUseSysCalls)           
                LeaveCriticalSection(&pClient->ClientCS);
            break;
        }
        case KITL_CMD_RESET:
            {
                KITL_RESET_DATA *pResetData =  (KITL_RESET_DATA *) KITLDATA (pHdr);

                KITLOutputDebugString("KITL: Got RESET command\n");

                // Set for clean boot if requested
                if (pResetData->Flags & KITL_RESET_CLEAN)
                    SC_SetCleanRebootFlag();
               
                // This function never returns
                KernelIoctl(IOCTL_HAL_REBOOT, NULL,0,NULL,0,NULL);
                KITLOutputDebugString("KITL: IOCTL_HAL_REBOOT not supported on this platform\n");
                break;
            }

        case KITL_CMD_DEBUGBREAK:
            if (fUseSysCalls && IsDesktopDbgrExist ())
                DebugBreak ();
            break;

        case KITL_CMD_TRAN_CONFIG:
            {
                int i;
               
                PKITL_HOST_TRANSCFG pCfg = (PKITL_HOST_TRANSCFG) KITLDATA(pHdr);
                wMsgLen -= KITL_DATA_OFFSET;
                if (pCfg->dwLen != wMsgLen) {
                    KITLOutputDebugString ("!Host config message size mismatch %d, %d\r\n", pCfg->dwLen, wMsgLen);
                    return FALSE;
                }
                wMsgLen -= sizeof (KITL_HOST_TRANSCFG);
                if (!Kitl.pfnSetHostCfg ((LPBYTE) (pCfg+1), wMsgLen))
                    return FALSE;
                Kitl.dwBootFlags = pCfg->dwFlags;

                if (pCfg->dwKeySig == HOST_TRANSCFG_KEYSIG) {
                    for (i = 0; i < HOST_TRANSCFG_NUM_REGKEYS; i++) {
                        g_dwKeys[i] = pCfg->dwKeys[i];
                        KITL_DEBUGMSG (ZONE_INIT, (" KeyIndex %d = %d \n", i, g_dwKeys[i]));
                    }
                }   
                KITLGlobalState |= KITL_ST_DESKTOP_CONNECTED;
            }
            break;

        // in case we're polling (pfnTransmit && pData only set to non-null if we're polling)
        // we'll use desktop as our timer (desktop sends a retransmit packet to us every 2 seconds).
        case KITL_CMD_RETRASMIT:
            if (pfnTransmit && pData) {
                // KITLOutputDebugString ("Retrasmitting packets....\n");
                pfnTransmit (pData, fUseSysCalls);
            }
            break;
        default:
            KITL_DEBUGMSG(ZONE_WARNING,("!ProcessAdminMsg: Unhandled command 0x%X\n",pHdr->Cmd));
            return FALSE;
    }
    return TRUE;
}
我们直接看KITL_CMD_TRAN_CONFIG分支，目前我们的主要工作仍然是配置连接。首先得到PKITL_HOST_TRANSCFG结构指针，并送SetHostCfg设置主机信息之后，读入从主机送出的8个key值后设置以及kitl启动选项和KITL_ST_DESKTOP_CONNECTED标示位。绕了这么大一圈也就干了个初始化连接的工作，现在我们继续回到startKitl。首先先是设置三个函数指针供后面程序调用，并设置标示位KITL_ST_ADAPTER_INITIALIZED;然后通过SetKernelCommDev从定位KERNEL_SVC_DBGMSG,KERNEL_SVC_PPSH，KERNEL_SVC_KDBG的transport，注意：这个函数并不是kitl的函数，而是windowsCE kernel的系统函数在WINCE420\PRIVATE\WINCEOS\COREOS\NK\KERNELkwin32.c下,作用是从定位系统调试信息的发布通道，有兴趣可以自己看看。之后StartKitl的过程就结束了，这个时候你肯定想问那kitl的中断初始化函数是什么时候才运行呢？没有中断的支持kitl是如何通讯和工作的呢，事实上KITLInitializeInterrupt就负责这部分的工作，但是由于系统内核还没有完成初始化的动作，所以这个时候起动kitl的中断是会影响kernel的工作。因此在后面由SystemStartupFunc()调用KITLInitializeInterrupt来完成初始化的动作。
BOOL
KITLInitializeInterrupt()
{

    int i;
    if (!(KITLGlobalState & KITL_ST_ADAPTER_INITIALIZED))
        return FALSE;
   
    // Check if we are coming up for the first time, or resuming interrupts (e.g. when coming
    // back from OEMPowerOff)
    if (KITLGlobalState & KITL_ST_MULTITHREADED) {
        // Just enable interrupt and return
        EnableInts();
        return TRUE;
    }
   
    KITLOutputDebugString("KITL: Leaving polling mode...\n");

    InitializeCriticalSection(&KITLODScs);
    InitializeCriticalSection(&KITLKCallcs);

    KITLGlobalState |= KITL_ST_MULTITHREADED;
   
    KITL_DEBUGMSG(ZONE_INIT,("KITL Checking client registrations\n"));
    // Some clients may have registered already, finish initialization now that
    // the system is up. KDBG continues to run in polling mode.
    for (i=0; i< MAX_KITL_CLIENTS; i++) {
        if (KITLClients[i] && (i != KITL_SVC_KDBG)
            && (KITLClients[i]->State & (KITL_CLIENT_REGISTERED|KITL_CLIENT_REGISTERING))) {
            if (!RegisterClientPart2((UCHAR)i))
                return FALSE;
        }
    }

    // Start interrupt thread. If we have clients registered, also turn on receive interrupts
    // from the ethernet controller, otherwise leave them disabled.
    if ((UCHAR) KITL_SYSINTR_NOINTR != Kitl.Interrupt) {
        KITL_DEBUGMSG(ZONE_INIT,("KITL Creating IST\n"));
        if ((hIntrThread = CreateKernelThread((LPTHREAD_START_ROUTINE)KITLInterruptThread,
                                              NULL, (WORD)g_dwKITLThreadPriority, 0)) == NULL) {
            KITLOutputDebugString("Error creating interrupt thread\n");
            return FALSE;
        }
    }

    return TRUE;
}
由于将会有IST为kitl专门服务，所以也就需要临界区来完成线程的操作，这儿创建了KITLODScs\KITLKCallcs两个临界区。之后标记 KITL_ST_MULTITHREADED。检查注册了的服务，完成后就创建IST.

kitl的初始化，启动的大致过程就是如此，start-->注册服务-〉初始化transport->创建IST

最后我们来看看IST里面我们都干些什么
static DWORD KITLInterruptThread (DWORD Dummy)
{
    HANDLE hIntEvent;
    DWORD dwRet;

    KITL_DEBUGMSG(ZONE_INIT,("KITL Interrupt thread started (hTh: 0x%X, pTh: 0x%X), using SYSINTR %u\n",
                             hCurThread,pCurThread, Kitl.Interrupt));

    pCurThread->bDbgCnt = 1;   // no entry messages
   
    if ((hIntEvent = CreateEvent(0,FALSE,FALSE,EDBG_INTERRUPT_EVENT)) == NULL) {
        KITLOutputDebugString("KITL CreateEvent failed!\n");
        return 0;
    }
    if (!SC_InterruptInitialize(Kitl.Interrupt, hIntEvent, NULL,0)) {
        CloseHandle(hIntEvent);
        KITLOutputDebugString("KITL InterruptInitialize failed\n");
        return 0;
    }

    // always enable interrupt as long as OEM told us so
    EnableInts();
   
    KITLGlobalState |= KITL_ST_IST_STARTED;
   
    while ((dwRet = SC_WaitForMultiple (1,&hIntEvent,0,INFINITE)) == WAIT_OBJECT_0) {

        KITL_DEBUGLED(LED_IST_ENTRY,0);
        KITL_DEBUGMSG(ZONE_INTR,("KITL Interrupt event\n"));

        // no need to check pending, just call HandleRecvInterrupts because it'll
        // just return if there is no interrupt pending
        HandleRecvInterrupt(ISTRecvBuf,TRUE, NULL, NULL);

        SC_InterruptDone(Kitl.Interrupt);
       
        KITL_DEBUGMSG(ZONE_INTR,("Processed Interrupt event\n"));
    }
    KITLOutputDebugString("!KITL Interrupt thread got error in WaitForMultipleObjects: dwRet:%u, GLE:%u\n",
                          dwRet,GetLastError());
    return 0;
}
首先是创建该IST所属的事件，并将该事件与所属的中断联系起来，再后自然是启动中断了。设定KITL_ST_IST_STARTED标记后的代码就是IST的实际内容，当中断发生，交付HandleRecvInterrupt处理，返回中断。和多数IST一样该调用永远不会返回，除非结束该线程，所以后面的调试信息输出的是错误。

void HandleRecvInterrupt(UCHAR *pRecvBuf, BOOL fUseSysCalls, PFN_TRANSMIT pfnTransmit, LPVOID pData)
{
    WORD wLen = KITL_MTU;
    BOOL fFrameRecvd;

    // Receive data into buffer
    do {
        if (!fUseSysCalls)
            fFrameRecvd = Kitl.pfnRecv (pRecvBuf, &wLen);
        else if (IsDesktopDbgrExist ())
            fFrameRecvd = KCall((PKFN) Kitl.pfnRecv, pRecvBuf, &wLen);
        else {
            EnterCriticalSection (&KITLKCallcs);
            fFrameRecvd = Kitl.pfnRecv (pRecvBuf, &wLen);
            LeaveCriticalSection (&KITLKCallcs);
        }
        if (fFrameRecvd) {
            ProcessRecvFrame (pRecvBuf,wLen,fUseSysCalls, pfnTransmit, pData);
            wLen = KITL_MTU;
        }
    } while (fFrameRecvd);
}
HandleRecvInterrupt是中断处理程序的实体，将transport送来的数据填入缓冲区待处理。上面所提到的中断在OEM代码中指定，在SMDK2440bsp中该中断对应以太网卡中断。

作者：Walzer
日期：2005.3.19

摘要：KITL是PLATFORM BUILDER中的一个亮点，提供了和本地调试类似的断点、变量跟踪、内存查看等手段，如果没有KITL，嵌入式调试应该只能用串口打印消息来看了，工作效率大大下降。本文以实现最简单的SERIAL KITL为目的，就其实现代码进行跟踪调试，这些代码跨越了WINCE的PLATFORM、PUBLIC、PRIVATE三大主要目录，有些烦琐，不过只要能调通，一切工作和弯路都是值得的。我把调试经验和个人理解写下来，希望能帮助别人少走弯路。如果文章中有理解失当的地方，请不吝赐教。

正文：

一.void OEMInit()  [platform\project\src\kernel\oal\init.c]
    首先从OEMInit()函数看起。。在依次初始化Branch-Target Buffer、KERNEL函数、初始化中断、TIMER之后，就轮到KITL了。调用了这个函数OALKitlStart()。此时有个编译的分支，如果是RELEASE版本，那么在kernel\kern\stubs.c里面的OALKitlStart()函数是个STUB，只是return TRUE； 如果是DEBUG版本，那就进到kernel\oal\kitl.c里面的OALKitlStart().

二.BOOL OALKitlStart()  [platform\myproject\src\kernel\oal]
    在OALKitlStart()里面，首先试图从0xA00FF00处读取bootloader里面留下的kitl参量，如果读不到东西则使用该函数里的默认配置。由于原来用了ethernet同时作为download和kitl途径，所以在InitSpecifiedEthDevice函数里给pKitlArgs结构体赋值了。现在想把两者划分清楚，首先就把读取bootloader里面的kitl参量一句干掉，强迫使用我们在下面的默认配置。主要就是填充三个参量

1.首先是这个结构体
OAL_KITL_ARGS pKITLArgs
{
 UINT32 flags;  //设好ENABLED标志，按需要设POLL标志，但注意一定不要设PASSIVE标志
 DEVICE_LOCATION  devLoc;
 {
  DWORD  IfcType;  //不论ether还是serial，都是internal type =0;
  DWORD  BusNumber; // =0
  DWORD  LogicalLoc; //物理地址
  PVOID     PhysicalLoc; //留做后面=OALPAtoVA(LogicalLoc, FALSE). 真见鬼, 感觉应该和上面的LogicalLoc作用调过来看着比较顺吧?
  DWORD  Pin;  //Ethernet才用的东东
 }
 union
 {
  struct
  {
   UINT32  baudRate; //不用解释了
   UINT32  dataBits;
   UINT32  stopBits;
   UINT32  parity;
  }
  struct
  {
   UINT16  mac[3]; //这个也不用解释了
   UINT32  ipAddress;
   UINT32  ipMask;
   UINT32  ipRoute
  }
 }
}
2. pszDeviceID.  感觉这名字就是起了好玩, 赋成Walzer应该比较拽,不过还是保留原来赋的AMOISOFT好了, 免得被打.
3. 全局变量OAL_KITL_DEVICE g_kitlDevices. 这个东东在kitl.c开头包含的kitl_cfg.h中被赋值,  最主要就是修改g_kitlDevices.pDriver.  这个pDrvier指向一个函数指针列表的结构体，该列表定义了用做kitl模块的初始化、读写、中断、流控制等函数。 g_kitlDevices本身是个二维数组, 可以定义许多设备用做kitl时提供的参数设置, 后面会用一个for来循环判断pKITLArgs的参数和g_kilDevices里面哪个一维数组成员相匹配.

这三个参量填充好以后，就可以进到OALKitlInit(pszDeviceID, pKITLArgs, g_kitlDevices)里面了.

三.BOOL OALKitlInit( deviceId, pArgs, pDevice)    [platform\common\src\common\kitl\kitl.c]
    这个函数先把输入的参量全部用OALMSG打印出来，这个不管。
    重要的是引入了g_kitlState全局变量，开头一句
    g_kitlState.pDevice = OALKitlFindDevice(&pArgs->devLoc, pDevice) 这个就是上面所说的从g_kitlDevices里可用设备列表里循环判断，找到选用的设备的匹配函数指针。
    接着把输入参量devicdId和前面填充好的OAL_KITL_ARGS结构COPY到g_kitlState里面
    然后就可以调用KItlInit(TRUE)了，如果前面在FLAG里面设了PASSSIVE标志，现在就是KitlInit(FALSE)了，嘿嘿爽到了吧。

四.BOOL KitlInit(BOOL fStartKitl)    [private\winceos\coreos\nk\kitl\ethdbg.c]
    太猥琐了，我要用串口，它居然叫ethdbg.c，不给面子。不过是private里面的东东，可远观而不可亵玩焉~~
    这个函数干了三件事：
1. 装载了三个全局的函数指针
2. 用NewClient注册了三个KITL客户端：
    KITL_SVCNAME_DBGMSG   //debug message, Debug信息发布通道
    KITL_SVCNAME_PPSH  //PPshell, 文本控制台界面
    KITL_SVCNAME_KDBG //kernel debug, 内核调试界面

3.由fStartKitl来决定是否启动StartKitl()函数. (这里顺便提一下，按照匈牙利命名法, BOOL变量前面加个b, 但MS的做法我觉得很合理, BOOL变量就是个FLAG嘛, 前面加个f, 把小b留着给BYTE类型用.)

五.static BOOL StartKitl(BOOL fInit)    [private\winceos\coreos\nk\kitl\ethdbg.c]
    这又是prviate里面的东东。最痛苦的地方开始了。这函数及其子函数将第一次调用OEM自己写的KITL模块初始化、读写程序。是骡子是马，拉出来溜溜就知道啦~
    按顺序看下来，首先判断输入参量是否要启动KITL，并且如果KITLGlobalState里面被打上KITL_ST_DESKTOP_CONNECTED标记的话，那下面的步骤就全免了。当然我们是第一次运行到这里，若这么就跳出的话，俺就马加爵了。

    第一步:
    干的第一件正事就是调用OEMKitlInit(&Kitl). 这个后面详述. 继续把这个函数看完.
    OEMKitlInit初始化KITL的硬件抽象层后并把相关指针数据填充给全局变量KITLTRANSPORT Kitl (有没有搞错，为什么不叫g_kitl), 这些工作做完就返回了
     StartKitl收货后把Kitl结构整个检查一遍,保证没错后, 马上买单, 把全局变量KITLGlobalState打上个KITL_ST_KITLSTARTED标记. 这才算KITL启动的第一步OK了.

    第二步:
    接下来就是KITLConnectToDesktop(), 进这个函数后就是第一次使用了前面KITL传输介质硬件抽象层里的读写函数了, 这时候就需要调试了. 这个ConnectToDesktop大致就是先Send了一个kITL.....的frame过去,然后polling等待PC端的response, 那边再发个kITL.....的frame过来, 搞得跟地下党打暗号似的, 其实也没什么玄乎的，就是普通的数据包前面加个KTIL专用的HEADER而已. 这个CONNECT成功后,KITLGlobalState里面就加个KITL_ST_DESKTOP_CONNECTED标记了.

    第三步:
    set up kernel function pointers, 也没什么,就三个函数指针, 赋完后就KITL_ST_ADAPTER_INITIALIZED了. 其实这个KITLGolbalSate的总共有7个标志,分别是
KITL_STARTED,  (OK)
DESKTOP_CONNECTED,   (OK)
TIMER_INIT, (?)
INT_ENABLED,  (POLLING)
IST_STARTED,  (POLLING)
MULTITHREADED,   (?)
ADAPTER_INITIALIZED. (OK)
后面括号里打上OK是到这里已经完成的， 打问号的我还不太清楚什么作用, INT和IST两项,我们用的POLLING所以肯定是不需要了.

    第四步:
    调用SetKernelCommDev设置kernel通过何种介质传送DBGMSG, PPSH和KDBG.
    OHYEAH, 我的SERIAL KITL就夭折在这里. 进到SerKernelCommDev(service, CommDevice)函数里看, 它只认CommDevice=KERNEL_COMM_ETHER的情况，而屏蔽了与ETHER并列的SERIAL和PARALLER,直接return FALSE, 下面的事情都不用干了. 而在MS提供的WinCE Documantation里面，这个SetKernelCommDev函数的说明上写着"This function is obsolete and should not be used". 若想改嘛,这个是在private里面的还动它不得. NND, 感觉被MS raped了.
     如果使用ETHER在这里成功的话, 下面还有两个函数NKForceCleanBoot()和KITLInitializeInterrupt()走过去, 这KITL初始化就全部结束了. 我估计KITLGolbalSate里面的INIT_ENABLED和IST_STARTED就是在这个函数过程中被标记上的.
    
   
六.BOOL OEMKitlInit(PKITLTRANSPORT pKitl)    [platform\common\src\common\kitl\kitl.c]
    前面提到StartKItl起来后，首要的就是调用OEMKitlInit. 这个函数在WinCE4.2和5.0里差别很大, 4.2里的做法是    if (!InitEther (pKitl) && !InitParallelSerial (pKitl)), 把ETHER, SERIAL, PARALLEL都初始化了一遍,碰运气看哪个用得上，而5.0里是进来后就一个很明显的分支剧情,由g_kitlState.pDevice->type来决定是调用OALKitlEthInit还是OALKitlSerialInit. 典型的种族歧视, 居然没有OALKitlParallelinit. 还好我们用的是SERIAL.
    这里有个选择编译的地方,就是#ifdef KITL_ETHER和#ifdef KITL_SERIAL, 具体定义的地方是该目录下的sources文件里面一行 CDEFINES=$(CDEFINES) -DKITL_SERIAL -DKITL_ETHER, 猥琐啊找了半天. 其实我觉得既然有if结构来选了，那么选择编译也是可有可无的了.
    好，下面就进到OALKItlSerialInit()里面.

七.BOOL OALKitlSerialInit(LPSTR deviceId, OAL_KITL_DEVICE *pDevice, OAL_KITL_ARGS *pArgs, KITLTRANSPORT *pKitl)
    [platform\common\src\common\kitl\kitlserial.c]
    我自己往这个kitlserial.c文件里写了六个函数.
    BOOL KitlSerialInit(KITL_SERIAL_INTFO *pSerInfo)
    UINT16 KitlSerialWriteData(UINT8 *pch, UINT16 length)
    UINT16 KitlSerialReadData(UINT8 *pch, UINT16 length)
    void KitlSerialFlowControl  //stub, 我所用的FFUART只有TXD和RXD两根线, RTS等都没有, 所以FlowControl自然也应该是STUB了
    void KitlSerialEnableInt(void)   //stub, use polling
    void KitlSerialDisableInt(void)  //stub, use polling
    否则前面的g_kitlDevices里面没有相应的硬件抽象层来填充.
    上面的SerialRecv, Encode, Decode等就意思都很明显了,不用多说. OK现在已经走到最底层了, 文章也可以结束了.

八、记录一下调试经验
    虽然这是我第三次调串口了，由于没总结前面的经验，还是耗了两天才到private里面夭折的地方。实际上应该一天就能走到了。问题出在
1. 第一天调试器根本用不上手。调试器软件、PB不断死翘，经常重启软件甚至重启电脑，第一天有3/4以上的时间耗在这些问题上, 不断重启。
2. 在UART初始化函数的最后，居然忘记了在interrupt controller register里面enable uart unit, 这么乌龙的事。
3. KitlSerialFlowControl的问题. 写的时候照搬了X86下的函数, 没想明白到底要Control什么. 调试时死在这里后,  一开始把指向这个函数的指针设置成NULL, 但这样PRIVATE里面有些要IF判断的函数就进不去了. 后来换成STUB就OK了.
4. receive函数里面, 在收每个BYTE之前先去判断了Line Status Register里面的Data Ready bit, 如果该为零, 则返回失败. 但这里是有问题的，具体也没太想明白, 反正在调试debug serial的时候就把这个判断从MS提供的源码里头删去了，现在做KITL serial时又手痒加进去, 果然还是不行. 这可能是MS或INTEL的一处BUG, 但按照INTEL CPU MANUL UPDATE里面给的读流程, 一开始只判断LSR里面的ERROR, 没有判断DR位就开始读第一个BYTE了. 读过后再判断如果DR位为1,则继续读下一BYTE.
5. 在receive函数里加通过debugger加break point, 结果receive buffer register里面的数据被debugger扫描去以后，就变零了，CPU上却什么都收不到, 这事情耗了大半个下午，最后还是Jeffery发现的这个问题.

参考文章：
KITL解析 by Nasiry  (http://nasiry.cnblogs.com/archive/2004/09/22/45473.html)

首先解释下这两个东东

The RAM on a Windows CE–based device is divided into two areas: the object store and the program memory.

The object store resembles a permanent, virtual RAM disk. Data in the object store is retained when you suspend or perform a soft reset operation on the system. Devices typically have a backup power supply for the RAM to preserve data if the main power supply is interrupted temporarily. When operation resumes, the system looks for a previously created object store in RAM and uses it, if one is found. Devices that do not have battery-backed RAM can use the hive-based registry to preserve data during multiple boot processes.

The program memory consists of the remaining RAM. Program memory works like the RAM in personal computers — it stores the heaps and stacks for the applications that are running.

我承认我很懒，上面一段话的URL是ms-help://MS.WindowsCE.500/wcecoreos5/html/wce50conMemoryArchitecture.htm

具体的设置可以在系统启动后，Control Panel -> System -> Memory 里面看到。默认的是把内存五五开，一半给Storage Memory， 一半给Program Memory用。这样显然是不合算的。以64M的RAM为例, 启动后Storage Memory 32M, 而因为没有留出界面让用户往里面拷东西, 任何时候in use都不会超过10M; Program Memory也是32M, 但启动后就用掉27M, 实际上应用程序可用的内存只有5M, 一旦达到了上限, 那么每前进一步都要很艰难地去释放几十K内存，然后用掉，再去释放几十K内存，如此循环，此时应用程序的运行速度狂慢无比.

划分的方法也很简单, 只不过可能没人注意到而已.

说明在ms-help://MS.WindowsCE.500/wceosdev5/html/wce50lrfFSRAMPERCENT.htm  懒得看英文的人就继续往下看

其实说白了就一句话, 在BSP的config.bib里 CONFIG 区添加这个变量 FSRAMPERCENT = 0xXXXXXX, 但注意两点，

(1) 必须写在config.bib的CONFIG区里, 不是plagform.bib不是config.reg等其他文件而是config.bib，也不是config.bib文件的任意地方而一定要在CONFIG REGION里.
(2) FSRAMPERCENT这个变量一定得写为FSRAMPERCENT, 不能写成FSROMPERCENT不能写成ILOVEU, 或者阿猫阿狗什么的.

写下这两句的时候本人已经打开无敌光环, 免疫一切鸡蛋和西红柿.

FSRAMPERCENT是一个4byte长度的十六进制数, 我们用代数假设 FSRAMPERCENT = 0xQXYZ, 其中Q,X,Y,Z都是十六进制数

那么最终划分给Storage Memory的大小 =  ( Q + X + Y +  Z ) / 0x400 * TOTAL_RAM_SIZE

以文中的例子来算, FSRAMPERCENT=0x10203040, 假设TOTAL_RAM_SIZE=64M, 那么StorageMemory= (0x10 + 0x20 + 0x30 + 0x40) / 0x400 * 64M = 10M.

作者：Walzer
日期：2005.12.12

RAPI全写为Remote Application Interface, 就是PC端调用这组API, 通过ActiveSync来操作TARGET端WindowsCE作业. 这个功能估计以后在WINCE或WIN MOBILE的应用上会用到许多

我今天修改了同事留下的Updateboot.exe的代码, 改进蓝牙读写的模块. 这个地方我们用到了RAPI, 看一下他们在程序中初始化RAPI的做法

 HRESULT hRapiResult;
 hRapiResult = CeRapiInit();
 if(hRapiResult != S_OK)
 {
     m_ValueEdit.SetWindowText((LPCTSTR)"初始化RAPI失败");
     return;
 }

看起来是平淡无奇, 实际上单步一下就可以发现运行到CeRapiInit()时, 程序就BLOCK在这里了，死活走不下去, 并没有达到 if(hRapiResult != S_OK)的预期目的. 我查了一下CeRapiInit()的说明:

A call to CeRapiInit does not return until the connection is made, an error occurs, or another thread calls CeRapiUninit.

也就是说像我现在并没有把板子和PC相连并启动ACTIVE SYNC时, 这个CeRapiInit()是肯定赖着不走了, 程序会死在这里. (鄙视一下谁写的代码，这个坑好大啊)  因此想到了重新创立个等待进程调用CeRapiUninit来干掉它. 不过这样做显然不厚道, 创立进程需要占用更多的内存. 所以用了上句说明的下半段:

The CeRapiInitEx function does not block the calling thread. Instead, it uses an event to signal when initialization is complete.

建立个事件, 用WaitForSingleObject来等他, 超时就BYEBYE了. 贡献自己写的如下代码, 以后RAPI INIT可以参考

multi-xip实际上很有用，但是现在有一个为难的事情：就是OS起来之后无法写flash，这个很让人苦恼。所以这也导致升级程序无法设置标志位。只能用GPIO口。

Multi-xip的实现：
1) Bib文件的修改：
   MEMORY

    RSVD     80000000  000FF000  RESERVED
    ARGS     800FF000  00001000  RESERVED
    NK       9C600000  01000000   RAMIMAGE
    APP      9D600000  00500000   RAMIMAGE
    CHAIN    9DB00000  00002000   RESERVED
    RAM      80100000  01F00000  RAM
    pdwXIPLoc 00000000 9DB00000  FIXUPVAR

CONFIG

    AUTOSIZE=ON
    ROM_AUTOSIZE=OFF
    RAM_AUTOSIZE=OFF
    DLLADDR_AUTOSIZE=ON
    XIPSCHAIN=9DB00000
    ROMSTART=9C600000
    ROMWIDTH=32
    ROMSIZE=01600000

    KERNELFIXUPS=ON

2) 在OEMInit加一个连接各个bin的函数：
void InitRomChain()
{
 // Added for MultiXIP stuff
 static  ROMChain_t s_pNextRom[MAX_ROM] = {0};
 DWORD  dwRomCount = 0;
    DWORD       dwChainCount = 0;
    DWORD *     pdwCurXIP;
    DWORD       dwNumXIPs;
    PXIPCHAIN_ENTRY pChainEntry = NULL;
    if(pdwXIPLoc == NOT_FIXEDUP){
        return;  // no chain or not fixed up properly
    }
    // set the top bit to mark it as a virtual address
    pdwCurXIP = (DWORD*)(((DWORD)pdwXIPLoc) | 0x80000000);
    // first DWORD is number of XIPs
    dwNumXIPs = (*pdwCurXIP);
   if(dwNumXIPs > MAX_ROM){
      OALMSG(TRUE, (L"ERROR: Number of XIPs exceeds MAX\r\n"));
      //lpWriteDebugStringFunc(TEXT("ERROR: Number of XIPs exceeds MAX\n"));
      return;
    }
    pChainEntry = (PXIPCHAIN_ENTRY)(pdwCurXIP + 1);
    while(dwChainCount < dwNumXIPs)
    {
        if ((pChainEntry->usFlags & ROMXIP_OK_TO_LOAD) &&  // flags indicates valid XIP
            *(LPDWORD)(((DWORD)(pChainEntry->pvAddr)) + ROM_SIGNATURE_OFFSET) == ROM_SIGNATURE)
        {
            s_pNextRom[dwRomCount].pTOC = *(ROMHDR **)(((DWORD)(pChainEntry->pvAddr)) + ROM_SIGNATURE_OFFSET + 4);
            s_pNextRom[dwRomCount].pNext = NULL;
            if (dwRomCount != 0)
            {
                s_pNextRom[dwRomCount-1].pNext = &s_pNextRom[dwRomCount];
            }
            else
            {
                OEMRomChain = s_pNextRom;
            }
            dwRomCount++;
        }
        else
        {
            OALMSG(TRUE, (L"Invalid XIP found\r\n"));
            //lpWriteDebugStringFunc( _T("Invalid XIP found\n") );
        }
        ++pChainEntry;
  dwChainCount++;
 }
}
  这是从CEPC中拷贝过来的。

通过上面的设置，romimage会生成3个bin，nk.bin，app.bin，chain.bin，还有一个xip.bin，是上面三个bin的集合体。我们download是要download xip.bin，这样就可以实现multibin。通过调试发现，InitRomChain就是利用chain.bin来连接各个bin的。
这样我们也理解了bib文件中这个语句的含义：
pdwXIPLoc 00000000 9DB00000  FIXUPVAR
也就是FIXUPVAR的含义。我们看到在代码中我们同样定义了pdwXIPLoc，这样romimage时，就将9DB00000赋给pdwXIPLoc。这就是FIXUPVAR的作用。正如pTOC也是由romimage赋值一样。

    在什么情况下应该用 Visual Studio .NET 而不是 eMbedded Visual C++ 来为 Win CE 系统开发应用程序？

The type of application that you want to create will dictate the choice between native and managed code (.NET). When performance and control are the highest priorities, developers should turn to eMbedded Visual C++ or native code. When a consistent programming model and time-to-market are the primary considerations, the advantages offered by Visual Studio .NET are unparalleled.

.NET Compact Framework 应用程序的运行性能是否和 eMbedded Visual C++ 应用程序一样？

In most cases, applications that you write with eMbedded Visual C++ will run faster than those that you write by using Microsoft Visual Basic .NET or Microsoft Visual C# .NET. However, for computationally-intensive portions of an application, you will see a substantial improvement of your Visual Basic .NET applications over their eMbedded Visual Basic .NET equivalents.

Running an application natively refers to running an application without recompiling it for a different environment. Windows CE .NET 4.2 and Windows CE 5.0 devices can run Pocket PC applications if both of the following are true:

•      The application is designed for the same CPU architecture

•      The application calls the same API set as the Pocket PC 2003 SDK. Windows CE .NET 4.2 and Windows CE 5.0 support the same SDK APIs from CESHELL and AYGSHELL.

For more information, visit the Windows CE Application Development page.

第一种，就是image已经在CEPC或者终端上跑起来了，那么这个时候要想添加文件可以通过PB或者EVC提供的remote file viewer，这个比较简单，看着界面操作就行了。

第二种，就是对定制的image已经build过了，现在想往里面添加文件的话，可以在你对应平台的release文件夹里面直接添加文件，然后修改平台配置文件project.bib，然后再make image，也可以将文件添加到image中去，将image启动后，会出现在windows文件夹下面

比如你想将test.txt添加到image中，则首先需要将此文件拷贝到平台release目录下面

（平台release目录也就是环境变量_FLATRELEASEDIR的值，_FLATRELEASEDIR的 = %_WINCEROOT%\PBWorkspaces\%_TGTPROJ%\RelDir\%_TGTPLAT%\%_TGTCPUFAMILY%_Release，也就是realease目录，（_TGTPLAT为平台名，_TGTCPUFAMILY为CPU名）。我新建的平台为shellTest，其值为E:\WINCE500\PBWorkspaces\ShellTest\RelDir\MyCEPC_x86_Release ）

然后按照以下修改project.bib：

在其中添加类似这样一行

test.txt$(_FLATRELEASEDIR)\test.txt NK S

这句话的意思是说将平台release文件夹下面的test.txt文件添加到image中，文件属性为系统文件，关于bib文件的格式，请查阅WinCE的帮助

修改好project.bib后，保存，然后在pb的bulid菜单下选择make image，成功后下载到终端或CEPC，就可以看到添加的文件了。

第三种，就是平台定制都没做好，或者做好了需要修改，那么如果你直接按照第二种来做，然后选择build菜单的sysgen and build的话，你会发现根本不会讲test.txt拷贝到image中，这个也是我的惨痛教训，花了好些时间才知道原因。

为什么呢？从build image时的output窗口，我每次都可以看到clean up项目release目录的输出，看来我直接把文件复制到release目录是不行的，因为在sysgen and build的过程中此文件夹会被清空，自然我的test.txt也被清掉了。那该怎么办呢？
这里缺少一个步骤，那就是要在平台设置中，作一些配置，从而让Release目录在被清空以后能将目标文件从本地硬盘动态复制到release目录

修改配置以便拷贝文件到Release目录的主要步骤如下：
1 pb中从platform菜单选setting
2 在弹出对话框中Configuration一项确保正确，一般默认就是正确的。
3 Custom Build Actions选项卡中的Build step下拉框，选择Pre-Make Image (有四个选项，分别为Pre-Sysgen，Post-Sysgen，Pre-Make Image，Post-Make Image，意思如其名) ，然后New，在弹出的Custom Build Action对话框中输入类似以下的语句：
copy <Path>\<File name> %_FLATRELEASEDIR%\<File name>

比如test.txt放在我电脑上的e盘根目录下，那么语句是这样的：

copy E:\test.txt %_FLATRELEASEDIR%\test.txt

加上这个步骤后，再按第二种方法就可以达到目的了。