VB.NET与WINCE串口连续通讯问题

看不太懂vb

但凭浅显之经验，我觉得假死主要是sleep导致的假死，进而导致下一次接收不到

vb下是否有多线程？用另一个线程启动一个定时器，替代原来的主线程sleep（2000）

出现提示，不是有效的WINDOWS CE应用程序解决方法：

1、先用杀毒软件全力清扫下电脑。

2、返回电脑桌面，双击打开“我的电脑”。

3、进入我的电脑窗口后，点击上方的“工具”。

4、然后，从工具d出的选项中点击文件夹选项。

5、进入文件夹选项后，点击“文件类型”。

6、接着，在文件类型选项下点击“新建“按钮，d出对话框后，在框中输入 .exe，输入完后再点击后面的”高级“，然后再从其选项下方选择”“应用程序”即可。

Windows CE6.0启动过程分析

在Windows CE 6.0中，内核（Kenerl）和OEM代码被分成oal.exe、kernel.dll和kitl.dll三个部分，其中启动代码（startup）和 OAL层的实现部分不再与内核链接生成NK.exe，取而代之的是启动代码（startup）和硬件相关且独立于内核的OAL层的实现部分编译成 oal.exe，而与内核相关且独立于硬件的OAL层代码包含在kernel.dll中；内核无关传输层（KITL）的支持代码从OAL层分离出来编译成 kitl.dll。

从表面上看，好像只是代码重新组合了一下，从帮助 文档中BSP的移植过程看好像也是这么一回事，实际上，整个Windows CE 6.0内核布局发生了很大的改变。Windows CE 6.0的启动过程也是如此，如果你想按照Windows CE 5.0的启动顺序去分析Windows CE 6.0的启动顺序，可能会走到一个死胡同。主要是因为Windows CE 6.0在启动过程中调用了kernel.dll和kitl.dll两个动态链接库的原因，而且Windows CE6.0不再编译生成KernKitlProf.exe内核文件。

从Windows CE 6.0的帮助文档可以看出，WinCE6.0的启动只与oal.exe和kernel.dll有关，至于kitl.dll，只有将 *** 作系统编译成具有 KITL功能时才用到。分析Windows CE 6.0的启动过程实际上找到编译oal.exe和kernel.dll的源码位置。

首先看一下将WinCE6.0编译成诸如 WinCE5.0所说的基本内核情况，即kern.exe。对于oal.exe源码位置比较容易找到，因为oal.exe是启动代码与硬件相关的OAL层 实现文件编译而成，所以只需在BSP的OAL目录中便能找到。而对于kernel.dll，在BSP目录结构中，基本上无法找到kernel.dll的编 译文件，所以必须从其他方面着手。

下面为WinCE 6.0的编译日志输出文件：makeimg.out在文件复制过程的一部分：

Copying E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\oal.exe to E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\nk.exe for debugger Copying E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kern.dll to E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kernel.dll for debugger

从日志输出文件可以看出，在文件复制过程 中，WinCE6.0编译器将oal.exe更名为nk.exe，而将kern.dll文件更名为kernel.dll，也就是说，kern.dll文件 的实现部分就是kernel.dll的实现体。根据前面的分析，oal.exe是与硬件相关独立于内核的OAL层的实现部分，而kernel.dll为内 核相关独立于硬件的OAL层的实现部分。同样可以从最后整合后的二进制配置文件ce.bib文件中看出端倪。

@CESYSGEN IF CE_MODULES_NK

nk.exe E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\oal.exe NK SHZ

kitl.dll E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kitl.dll NK SHZ

kernel.dll E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kern.dll NK SHZ

@CESYSGEN ENDIF

而kern.dll动态库在整个Windows CE6.0中没有显式编译过程，即没有一个sources文件有kern.dll的编译过程，所以只能从 *** 作系统的编译文件Makefile中寻找其编译 过程。下面看一下$(_PUBLICROOT)\common\CESYSGEN\makefile中的部分内容：

nk::$(NK_COMPONENTS) $(NK_REPLACE_COMPONENTS)

@copy $(SG_INPUT_LIB)\oemstub.pdb $(SG_OUTPUT_OAKLIB)

@copy $(SG_INPUT_LIB)\oemstub.lib $(SG_OUTPUT_OAKLIB)

set TARGETTYPE=DYNLINK

set TARGETNAME=kern

set RELEASETYPE=OAK

set DLLENTRY=NKStartup

set DEFFILE=NO_DEF_FILE

set TARGETLIBS=

set SOURCELIBS=%%NKLIBS%% $(SG_INPUT_LIB)\nkmain.lib $(SG_INPUT_LIB)\fulllibc.lib

$(MAKECMD) /NOLOGO NOLIBC=1 kern.dll

从上述代码中可以发现，原来kern.dll动态库是从oemstub.lib编译而来，而且与nkmain.lib有关。

在理顺了上述文件的相互之间的关系之后，再来分析Windows CE 6.0的启动过程可能就比较容易啦。

在理清了上述文件的关系之后，便可以分析任意一款基于ARM微处理器的Windows CE 6.0的启动过程，现在以深圳亿道电子技术有限公司开发的基于PXA270 ARM开发平台为例，分析Windows CE 6.0 *** 作系统启动过程。

1、Startup函数：

从Windows CE 6.0的帮助文档可以看出，WinCE6.0的启动只与oal.exe和kernel.dll有关，至于kitl.dll，只有将 *** 作系统编译成具有 KITL功能时才用到。分析Windows CE 6.0的启动过程实际上找到编译oal.exe和kernel.dll的源码位置。

oal.exe的通过Startup函数完成硬件 的初始化。Startup.s代码与该硬件平台的Bootloader启动代码共用，其中PreInit函数主要完成将ARM处理器工作模式切换到管理员 模式、同时关闭MMU，并检测系统启动原因,如果是热启动、即在该函数调用之前已经启动了Bootloader程序，相当基本硬件初始化已经完成，则直接 跳转到OALStartUp函数中；否则需要进行硬件中断屏蔽、内存、系统时钟频率、电源管理等硬件的基本初始化过程。（具体过程见代码的分析）

---