博客园_we-hjb的BLOG

WinCE下NTFS文件系统的注意点

2012-01-15T06:36:00Z

借助于第三方提供的驱动程序，WinCE6.0也能支持NTFS文件系统，可以访问超大容量的移动硬盘，并播放存储于其中的1080P的视频文件。

需要注意的是WinCE下NTFS中文件及目录名区分大小写，即在同一目录下，能同时创建多个文件名大小写不同的同名文件，如下图所示。

关于NTFS中文件名区分大小写的说明，请参考http://support.microsoft.com/kb/100625/en-us

实际上，对于WinCE系统来说，如果要支持超大容量外部存储设备，尤其是SD卡、U盘等Flash存储器，推荐使用exFAT文件系统。exFAT文件系统的介绍，请参考http://zh.wikipedia.org/zh-cn/ExFAT

本文链接

WinCE6.0的批量编译

2011-12-18T15:15:00Z

《WinCE下多份BSP的维护技巧》中曾介绍了维护不同项目BSP的方法，可以很方便的使用同一解决方案，在多个BSP中任意切换，编译出不同项目对应的IMAGE。即便对于同一项目来说，有时也需要编译不同IMAGE，即同一份BSP、同一个解决方案，编译出不同版本IMAGE。而这一般通过修改环境变量、宏定义和条件编译的方式实现。

随着项目的推进，现在发布版本时，须编译出4个不同IMAGE，对应于不同的分辨率、不同主板及MCU。之前都是手动修改BAT文件中的定义，然后Rebuild Current BSP and Subprojects。最近一段时间，改动较多，出版本也很频繁，越来越觉得手动修改编译太麻烦，于是基于命令行编译的方式实现了自动批量编译的功能。

首先创建一个批处理文件BuildAll.bat，内容如下。这里编译出4个版本的内核，A00、B01、H01和A01，也可以很方便的加入更多类型。

@echo off
echo Build All
echo (A00)%date% %time%
start /wait .\A00.bat

echo (B01)%date% %time%
start /wait .\B01.bat

echo (H01)%date% %time%
start /wait .\H01.bat

echo (A01)%date% %time%
start /wait .\A01.bat

echo (END)%date% %time%
pause

A00.bat的内容如下。首先设置KernelCode为A00，然后调用setenv.bat，最后执行“blddemo -c -qbsp”。

set KernelCode=A00
call .\setenv.bat
call blddemo -c -qbsp
exit

B01.bat的内容如下。基本与A00.bat一致，仅仅修改了KernelCode的定义，修改为B01。

set KernelCode=B01
call .\setenv.bat
call blddemo -c -qbsp
exit

setenv.bat的内容如下。这里前三个定义与平台有关，分辨是BSP、解决方案的名称。

set __PLATFORMNAME__=Magellan
set __PROJECTNAME__=TCC89XX
set PBCONFIG=MAGELLAN Baseboards Release
set _WINCEROOT=C:\WINCE600
set WINCEDEBUG=retail
set CPU=ARMV4I
set PBWORKSPACEROOT=%_WINCEROOT%\OSDesigns\%__PROJECTNAME__%\%__PROJECTNAME__%
set _FLATRELEASEDIR=%_WINCEROOT%\OSDesigns\%__PROJECTNAME__%\%__PROJECTNAME__%\RelDir\%__PLATFORMNAME__%_%CPU%_Release\
set PATH=%PATH%;C:\Windows\system32;C:\Windows;C:\Program Files\Microsoft Platform Builder\6.00\cepb\IdeVS
set _PROJECTROOT=%PBWORKSPACEROOT%\WINCE600\%__PLATFORMNAME__%_%CPU%
set PBWORKSPACE=%_WINCEROOT%\OSDesigns\%__PROJECTNAME__%\%__PROJECTNAME__%\%__PROJECTNAME__%.pbxml
set WINCE_BAT=%_WINCEROOT%\Public\Common\Oak\misc\wince.bat
set PBXMLUTILS="C:\Program Files\Microsoft Platform Builder\6.00\cepb\IdeVS\pbxmlutils.exe"
call %WINCE_BAT% %CPU% %__PROJECTNAME__% %__PLATFORMNAME__%
%PBXMLUTILS% /getbuildenv > %_TARGETPLATROOT%\AutoBuild%__PROJECTNAME__%.bat
call %_TARGETPLATROOT%\AutoBuild%__PROJECTNAME__%.bat

如果修改了BSP或者子项目的代码，只需要执行BuildAll.bat即可很方便的得到4个IMAGE。

如果修改了Catalog中的组件选择，需要Clean Sysgen时，如何处理呢？创建一个RebuildAll.bat，内容如下。第一个执行的是A00C.bat。

@echo off
echo Rebuild All
echo (A00)%date% %time%
start /wait .\A00C.bat

echo (B01)%date% %time%
start /wait .\B01.bat

echo (H01)%date% %time%
start /wait .\H01.bat

echo (A01)%date% %time%
start /wait .\A01.bat

echo (END)%date% %time%
pause

A00C.bat的内容如下。与A00.bat的区别是，它调用blddemo clean -q，以执行Clean Sysgen。后续几个只需Rebuild Current BSP and Subprojects

set KernelCode=A00
call .\setenv.bat
call blddemo clean -q
exit

BSP中Magellan.bat的部分内容如下。这里根据KernelCode，分别定义LCD及其他一些相关类型。

if not DEFINED KernelCode set KernelCode=A01

if "%KernelCode%"=="A00" set LCD_TYPE_HSD070=1

if "%KernelCode%"=="A01" set LCD_TYPE_HSD070=1
if "%KernelCode%"=="A01" set BSP_MALI_3D=

if "%KernelCode%"=="H00" set LCD_TYPE_BYD700=1

if "%KernelCode%"=="H01" set LCD_TYPE_BYD700=1
if "%KernelCode%"=="H01" set BSP_MALI_3D=
if "%KernelCode%"=="H01" set CMMB_PAUSE_ENABLE=1

if "%KernelCode%"=="B00" set LCD_TYPE_HSD070=1
if "%KernelCode%"=="B00" set CONNECT_SMD_DIRECTLY=1
if "%KernelCode%"=="B00" set VOLUME_LOUD=1

if "%KernelCode%"=="B01" set LCD_TYPE_HSD070=1
if "%KernelCode%"=="B01" set CONNECT_SMD_DIRECTLY=1
if "%KernelCode%"=="B01" set BSP_MALI_3D=
if "%KernelCode%"=="B01" set VOLUME_LOUD=1

Platform.reg中相关代码如下，在注册表中定义了内核类型。

[HKEY_LOCAL_MACHINE\SOFTWARE\VERSION]
"KernelCode"="$(KernelCode)" ;内核尾缀 A00 编译设置

最后，很重要的一点就是编译得到的BOOT和NK，需要自动拷贝到特定目录下，否则就是长江后浪推前浪了。而这个工作在postromimage.bat中指定，如下。

copy tcboot.rom G:\车机89OS\"%KernelCode%"\tcboot.rom
copy nk.rom G:\车机89OS\"%KernelCode%"\nk.rom

批量编译的截图如下，编译一个IMAGE大概4分钟左右，四个项目共16分钟。

批量重新编译的截图如下，第一个Clean Sysgen大概20分钟，后续一个4分钟，共半个小时多一点。

实现了自动批量编译，再出版本时确实方便多了。

本文链接

VS2005过度优化的陷阱(二)

2011-10-17T14:23:00Z

目前还没有新的发现，先把所有现象再次整理如下，望牛人帮忙指正。

完整代码：

1 int _tmain(int argc, _TCHAR* argv[])
2 {
3     volatile PS3C6410_GPIO_REG pGPIO1;   // 注意:与volatile S3C6410_GPIO_REG* pGPIO1;效果是不同的
4
5     pGPIO1 = (PS3C6410_GPIO_REG)GetVirtual(S3C6410_BASE_REG_PA_GPIO, sizeof(S3C6410_GPIO_REG));
6
7     pGPIO1->GPBCON = 0x22222222;
8     printf("\r\n(%08x)", pGPIO1->GPBCON);
9     pGPIO1->GPBCON &= 0xFFFF;   // 替换该行代码,查看其对应的汇编代码
10     printf("-->(%08x)", pGPIO1->GPBCON);
11     return 0;
12 }

下面逐一替换第9行代码，并查看其对应的汇编代码。

代码1：pGPIO1->GPBCON &= 0xFFFF;被优化掉了

    pGPIO1->GPBCON &= 0xFFFF;
00011078  ldr         r3, pGPIO1
    printf("\r\n(%08x)", pGPIO1->GPBCON);
0001107C  ldr         r2, pGPIO1
00011080  ldr         r0, [pc, #0x14]
00011084  strh        r5, [r3, #0x22]
00011088  ldr         r1, [r2, #0x20]
0001108C  bl          00011498

代码2：pGPIO1->GPBCON &= 0xFFFF<<16;也被优化掉了

    pGPIO1->GPBCON &= 0xFFFF<<16;
00011078  ldr         r3, pGPIO1
    printf("\r\n(%08x)", pGPIO1->GPBCON);
0001107C  ldr         r2, pGPIO1
00011080  ldr         r0, [pc, #0x14]
00011084  strh        r5, [r3, #0x20]
00011088  ldr         r1, [r2, #0x20]
0001108C  bl          00011498

代码3:pGPIO1->GPBCON &= ~0xFFFF;还是被优化掉了，与代码2的汇编代码完全一样

    pGPIO1->GPBCON &= ~0xFFFF;
00011078  ldr         r3, pGPIO1
    printf("\r\n(%08x)", pGPIO1->GPBCON);
0001107C  ldr         r2, pGPIO1
00011080  ldr         r0, [pc, #0x14]
00011084  strh        r5, [r3, #0x20]
00011088  ldr         r1, [r2, #0x20]
0001108C  bl          00011498

代码4：pGPIO1->GPBCON &= ~(0xFFFF<<16);也未能幸免，与代码1的汇编代码完全一样

    pGPIO1->GPBCON &= ~(0xFFFF<<16);
00011078  ldr         r3, pGPIO1
    printf("\r\n(%08x)", pGPIO1->GPBCON);
0001107C  ldr         r2, pGPIO1
00011080  ldr         r0, [pc, #0x14]
00011084  strh        r5, [r3, #0x22]
00011088  ldr         r1, [r2, #0x20]
0001108C  bl          00011498

代码5：pGPIO1->GPBCON &= 0xFF;这么写没问题！

    pGPIO1->GPBCON &= 0xFF;
00011078  ldr         r2, pGPIO1
    printf("\r\n(%08x)", pGPIO1->GPBCON);
0001107C  ldr         r1, pGPIO1
00011080  ldr         r0, [pc, #0x1C]
00011084  ldr         r3, [r2, #0x20]!
00011088  and         r3, r3, #0xFF
0001108C  str         r3, [r2]
00011090  ldr         r1, [r1, #0x20]
00011094  bl          000114A0

代码6：pGPIO1->GPBCON &= 0xFF<<16;这么写也没问题！难道0xFF就没问题了？

    pGPIO1->GPBCON &= 0xFF<<16;
00011078  ldr         r2, pGPIO1
    printf("\r\n(%08x)", pGPIO1->GPBCON);
0001107C  ldr         r1, pGPIO1
00011080  ldr         r0, [pc, #0x1C]
00011084  ldr         r3, [r2, #0x20]!
00011088  and         r3, r3, #0xFF, 16
0001108C  str         r3, [r2]
00011090  ldr         r1, [r1, #0x20]
00011094  bl          000114A0

代码7：pGPIO1->GPBCON &= ~0xFF;又不对了！

    pGPIO1->GPBCON &= ~0xFF;
00011078  ldr         r3, pGPIO1
    printf("\r\n(%08x)", pGPIO1->GPBCON);
0001107C  ldr         r2, pGPIO1
00011080  ldr         r0, [pc, #0x14]
00011084  strb        r5, [r3, #0x20]
00011088  ldr         r1, [r2, #0x20]
0001108C  bl          00011498

代码8：pGPIO1->GPBCON &= ~(0xFF<<16);也被优化掉了。

    pGPIO1->GPBCON &= ~(0xFF<<16);
00011078  ldr         r3, pGPIO1
    printf("\r\n(%08x)", pGPIO1->GPBCON);
0001107C  ldr         r2, pGPIO1
00011080  ldr         r0, [pc, #0x14]
00011084  strb        r5, [r3, #0x22]
00011088  ldr         r1, [r2, #0x20]
0001108C  bl          00011498

以上8段代码，仅2段代码正常运行，其余都有问题。已经不是运气的事了，肯定某个地方出了问题，在哪呢？

项目的C/C++属性配置如下:

/O2 /D "NDEBUG" /D "_WIN32_WCE=0x600" /D "UNDER_CE" /D "WINCE" /D "_CONSOLE" /D "ARM" /D "_ARM_" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MT /fp:fast /GR- /Yu"stdafx.h" /Fp"CHSINT SDK For WinCE 6.0 (ARMV4I)\Release/GPIOApp.pch" /Fo"CHSINT SDK For WinCE 6.0 (ARMV4I)\Release/" /Fd"CHSINT SDK For WinCE 6.0 (ARMV4I)\Release/vc80.pdb" /W3 /nologo /c /Zi /TP

以上代码，均已“最大化速度”优化。如以“最小化大小”优化，代码如下，也有问题。

    pGPIO1->GPBCON &= 0xFFFF;
000110B0  ldr         r3, [sp]
    printf("-->(%08x)", pGPIO1->GPBCON);
000110B4  ldr         r2, [sp]
000110B8  mov         r1, #0
000110BC  ldr         r0, [pc, #0x14]
000110C0  strh        r1, [r3, #0x22]
000110C4  ldr         r1, [r2, #0x20]
000110C8  bl          000114D4

若“禁用优化”，对应的代码如下，运行结果也正确。

    pGPIO1->GPBCON &= 0xFFFF;
000110F8  ldr         r3, [sp]
000110FC  add         r3, r3, #0x20
00011100  str         r3, [sp, #0xC]
00011104  ldr         r3, [sp, #0xC]
00011108  ldr         r2, [r3]
0001110C  mov         r3, #0xFF, 24
00011110  orr         r3, r3, #0xFF
00011114  and         r2, r2, r3
00011118  ldr         r3, [sp, #0xC]
0001111C  str         r2, [r3]
    printf("-->(%08x)", pGPIO1->GPBCON);
00011120  ldr         r3, [sp]
00011124  add         r3, r3, #0x20
00011128  ldr         r1, [r3]
0001112C  ldr         r0, [pc, #0x14]
00011130  bl          00011544

如果全部禁用优化，有点因噎废食的味道，还是希望能找出点原因，以免将来再次触雷。

本文链接

VS2005过度优化的陷阱

2011-09-30T15:17:00Z

最近在调试一块S3C6410的核心板。为了验证核心板扩展槽上的所有接口，LD特地设计了一个扩展底板，上面遍布红红绿绿的LED。软件上用总线读写和GPIO来控制这些灯。观察LED的亮灭，该亮的亮，该灭的灭，说明接口没有问题，否则就需要拿给硬件检查了。

考虑到既有总线读写，又有大量的GPIO控制，写驱动程序会相当麻烦，所以使用了《WinCE6.0中应用程序如何直接访问物理空间》中介绍的方法，直接在测试程序中实现总线访问和GPIO控制。测试程序写的还算顺利，一会儿就搞定了。不过，有些IO的控制有点奇怪，总是莫名其妙的被修改。《ARM-WinCE5.0-寄存器读写工具》中曾提到过GPIO被修改的原因和解决办法。不过，在这里似乎都解释不通。因为现在只有测试应用程序能够修改GPIO，不存在被别的程序修改的可能。难道是代码写的有问题？代码已经简单到不能再简单了，如下。

#include "stdafx.h"
#include <windows.h>
#include "s3c6410.h"

typedef struct {
    LPVOID    pvDestMem;
    DWORD    dwPhysAddr;
    DWORD    dwSize;
} VIRTUAL_COPY_EX_DATA,*PVIRTUAL_COPY_EX_DATA;

#define IOCTL_VIRTUAL_COPY_EX CTL_CODE (FILE_DEVICE_UNKNOWN,3333,METHOD_BUFFERED,FILE_ANY_ACCESS)

LPVOID GetVirtual(DWORD dwPhyBaseAddress, DWORD dwSize)
{
    LPVOID pVirtual;
    VIRTUAL_COPY_EX_DATA vced;

    if(dwPhyBaseAddress & 0xFFF)
    {
        return NULL;
    }

    vced.dwPhysAddr = dwPhyBaseAddress>>8;
    pVirtual = VirtualAlloc(0, dwSize, MEM_RESERVE, PAGE_NOACCESS);
    vced.pvDestMem = pVirtual;
    vced.dwSize = dwSize;
    KernelIoControl(IOCTL_VIRTUAL_COPY_EX, &vced, sizeof(vced), NULL, NULL, NULL);

    return pVirtual;
}

int _tmain(int argc, _TCHAR* argv[])
{
    volatile PS3C6410_GPIO_REG pGPIO1;

    pGPIO1 = (PS3C6410_GPIO_REG)GetVirtual(S3C6410_BASE_REG_PA_GPIO, sizeof(S3C6410_GPIO_REG));

    pGPIO1->GPBCON = 0x22222222;
    printf("\r\npGPIO1->GPBCON(%08x)", pGPIO1->GPBCON);
    pGPIO1->GPBCON &= (~(0xFFFF << 16));
    printf("-->(%08x)", pGPIO1->GPBCON);

    return 0;
}

预想的执行结果应该是pGPIO1->GPBCON(02222222)-->(00002222)而实际结果却是pGPIO1->GPBCON(02222222)-->(00000000)，不仅仅是高16位被清零了，所有位都被清零！

跟LD一起调试时，愣是没找到原因。回来的路上，忽然想到可能是编译器优化的问题。不过，马上又把它给否了——已经加了volatile啊。难道volatile不起效？不太可能吧？

到家以后，用IDA工具看了下测试程序的汇编代码，果不其然，跟预想的不一样，代码如下。

.text:00011000 wmain                                   ; CODE XREF: mainCRTStartupHelper+8Cp
.text:00011000                                         ; DATA XREF: .pdata:00014000o
.text:00011000
.text:00011000 var_24          = -0x24
.text:00011000 var_20          = -0x20
.text:00011000 var_1C          = -0x1C
.text:00011000 var_18          = -0x18
.text:00011000 var_14          = -0x14
.text:00011000 var_10          = -0x10
.text:00011000
.text:00011000                 STMFD   SP!, {R4,R5,LR}
.text:00011004                 SUB     SP, SP, #0x18
.text:00011008                 MOVL    R3, 0x7F0080
.text:00011010                 STR     R3, [SP,#0x24+var_14]
.text:00011014                 MOV     R3, #1
.text:00011018                 MOV     R2, #0x2000
.text:0001101C                 MOV     R1, #0x940
.text:00011020                 MOV     R0, #0
.text:00011024                 BL      VirtualAlloc
.text:00011028                 MOV     R4, R0
.text:0001102C                 LDR     R0, =0x223414
.text:00011030                 MOV     LR, #0x940
.text:00011034                 MOV     R5, #0
.text:00011038                 MOV     R3, #0
.text:0001103C                 MOV     R2, #0xC
.text:00011040                 ADD     R1, SP, #0x24+var_18
.text:00011044                 STR     R4, [SP,#0x24+var_18]
.text:00011048                 STR     LR, [SP,#0x24+var_10]
.text:0001104C                 STR     R5, [SP,#0x24+var_20]
.text:00011050                 STR     R5, [SP,#0x24+var_24]
.text:00011054                 BL      KernelIoControl
.text:00011058                 STR     R4, [SP,#0x24+var_1C]
.text:0001105C                 LDR     R1, =0x22222222
.text:00011060                 LDR     R3, [SP,#0x24+var_1C]
.text:00011064                 LDR     R2, [SP,#0x24+var_1C]
.text:00011068                 LDR     R0, =aPgpio1Gpbcon08
.text:0001106C                 STR     R1, [R3,#0x20]
.text:00011070                 LDR     R1, [R2,#0x20]
.text:00011074                 BL      printf
.text:00011078                 LDR     R3, [SP,#0x24+var_1C]
.text:0001107C                 LDR     R2, [SP,#0x24+var_1C]
.text:00011080                 LDR     R0, =a08x
.text:00011084                 STRH    R5, [R3,#0x22]
.text:00011088                 LDR     R1, [R2,#0x20]
.text:0001108C                 BL      printf
.text:00011090                 MOV     R0, #0
.text:00011094                 ADD     SP, SP, #0x18
.text:00011098                 LDMFD   SP!, {R4,R5,PC}
.text:00011098 ; End of function wmain

pGPIO1->GPBCON &= (~(0xFFFF << 16));被优化得无影无踪，仅剩STRH R5, [R3,#0x22]，而R5此时此刻为0x00000000。原因似乎是找到了，确实是编译优化的问题，但却更让人不解，这里的volatile为什么不起作用？在TCC8901上，一直都这么用，从没出现过这问题。差别在哪里呢？

后来对比了TCC8901的BSP，有了进一步的发现，它定义GPIO结构体的代码如下。

typedef struct _GPIO{
    volatile unsigned int    GPADAT;                 //   0x000  R/W  0x00000000  GPA Data Register
    volatile unsigned int    GPAEN;                  //   0x004  R/W  0x00000000  GPA Output Enable Register
    volatile unsigned int    GPASET;                 //   0x008  W  -  OR function on GPA Output Data
    volatile unsigned int    GPACLR;                 //   0x00C  W  -  BIC function on GPA Output Data
    volatile unsigned int    GPAXOR;                 //   0x010  W  -  XOR function on GPA Output Data
    volatile unsigned int    GPACD0;                 //   0x014  W  0x55555555  Driver strength Control 0 on GPA Output Data
    volatile unsigned int    GPACD1;                 //   0x018  W  0x00000000  Driver strength Control 1 on GPA Output Data
    volatile unsigned int    GPAPD0;                 //   0x01C  W  0x55555555  Pull-Up/Down function on GPA Output Data
    volatile unsigned int    GPAPD1;                 //   0x020  W  0x00000000  Pull-Up/Down function on GPA Output Data
    volatile unsigned int    GPAFN0;                 //   0x024  W  0x00000000  Port Configuration on GPA Output Data
    volatile unsigned int    GPAFN1;                 //   0x028  W  0x00000000  Port Configuration on GPA Output Data
    volatile unsigned int    GPAFN2;                 //   0x02C  W  0x00000000  Port Configuration on GPA Output Data
    volatile unsigned int    GPAFN3;                 //   0x030  W  0x00000000  Port Configuration on GPA Output Data
    volatile unsigned int    NOTDEFINE0[3];          //     0x034-0x03C     Reserved
    volatile unsigned int    GPBDAT;                 //   0x040  R/W  0x00000000  GPB Data Register
    volatile unsigned int    GPBEN;                  //   0x044  R/W  0x00000000  GPB Output Enable Register
    volatile unsigned int    GPBSET;                 //   0x048  W  -  OR function on GPB Output Data
    volatile unsigned int    GPBCLR;                 //   0x04C  W  -  BIC function on GPB Output Data
    volatile unsigned int    GPBXOR;                 //   0x050  W  -  XOR function on GPB Output Data
    volatile unsigned int    GPBCD0;                 //   0x054  W  0x55555555  Driver strength Control 0 on GPB Output Data
    volatile unsigned int    GPBCD1;                 //   0x058  W  0x00000000  Driver strength Control 1 on GPB Output Data
    volatile unsigned int    GPBPD0;                 //   0x05C  W  0x55555555  Pull-Up/Down function on GPB Output Data
    volatile unsigned int    GPBPD1;                 //   0x060  W  0x00000000  Pull-Up/Down function on GPB Output Data
    volatile unsigned int    GPBFN0;                 //   0x064  W  0x00000000  Port Configuration on GPB Output Data
    volatile unsigned int    GPBFN1;                 //   0x068  W  0x00000000  Port Configuration on GPB Output Data
    volatile unsigned int    GPBFN2;                 //   0x06C  W  0x00000000  Port Configuration on GPB Output Data
    volatile unsigned int    GPBFN3;                 //   0x070  W  0x00000000  Port Configuration on GPB Output Data
    volatile unsigned int    NOTDEFINE1[3];          //      0x074-0x07C     Reserved

而S3C6410定义GPIO的结构体的代码如下。

typedef struct
{
    UINT32 GPACON;        // 000
    UINT32 GPADAT;        // 004
    UINT32 GPAPUD;        // 008
    UINT32 GPACONSLP;    // 00c

    UINT32 GPAPUDSLP;    // 010
    UINT32 PAD1[3];        // 014~01f

    UINT32 GPBCON;        // 020
    UINT32 GPBDAT;        // 024
    UINT32 GPBPUD;        // 028
    UINT32 GPBCONSLP;    // 02c

    UINT32 GPBPUDSLP;    // 030
    UINT32 PAD2[3];        // 034~03f

可以看到，在TCC8901的结构体定义中都有volatile，而S3C6410中是没有的。也许这就是原因，结构体内部必须有volatile才行？定义结构体指针变量时的volatile作用域有限，并没有起到预想的作用——阻止编译器的优化。后来测试发现，如果结构体内部有volatile，定义结构体指针变量时省去volatile都行。示例代码如下，执行结果也是正确的（前提:在结构体定义中UINT32 GPBCON前增加了volatile!!!）。

int _tmain(int argc, _TCHAR* argv[])
{
    PS3C6410_GPIO_REG pGPIO1;

    pGPIO1 = (PS3C6410_GPIO_REG)GetVirtual(S3C6410_BASE_REG_PA_GPIO, sizeof(S3C6410_GPIO_REG));

    pGPIO1->GPBCON = 0x22222222;
    printf("\r\npGPIO1->GPBCON(%08x)", pGPIO1->GPBCON);
    pGPIO1->GPBCON &= (~(0xFFFF << 16));
    printf("-->(%08x)", pGPIO1->GPBCON);

    return 0;
}

问题的原因似乎更明朗了。但好似还是有点问题。因为在结构体中添加volatile前，下面这段代码的执行也是正确的。

int _tmain(int argc, _TCHAR* argv[])
{
    volatile S3C6410_GPIO_REG* pGPIO1;

    pGPIO1 = (PS3C6410_GPIO_REG)GetVirtual(S3C6410_BASE_REG_PA_GPIO, sizeof(S3C6410_GPIO_REG));

    pGPIO1->GPBCON = 0x22222222;
    printf("\r\npGPIO1->GPBCON(%08x)", pGPIO1->GPBCON);
    pGPIO1->GPBCON &= (~(0xFFFF << 16));
    printf("-->(%08x)", pGPIO1->GPBCON);

    return 0;
}

可以看到，与问题代码唯一的不同就是"volatile PS3C6410_GPIO_REG pGPIO1;”变成"volatile S3C6410_GPIO_REG* pGPIO1; ” ，"PS3C6410_GPIO_REG”和"S3C6410_GPIO_REG*”不是等价的吗？通常更习惯用“PS3C6410_GPIO_REG”，这也有问题么。

问题还没有结束，在结构体中添加volatile前，下面这段代码也能正确运行。

int _tmain(int argc, _TCHAR* argv[])
{
    volatile PS3C6410_GPIO_REG pGPIO1;

    pGPIO1 = (PS3C6410_GPIO_REG)GetVirtual(S3C6410_BASE_REG_PA_GPIO, sizeof(S3C6410_GPIO_REG));

    pGPIO1->GPBCON = 0x22222222;
    printf("\r\npGPIO1->GPBCON(%08x)", pGPIO1->GPBCON);
    pGPIO1->GPBCON = pGPIO1->GPBCON & (~(0xFFFF << 16));
    printf("-->(%08x)", pGPIO1->GPBCON);

    return 0;
}

这段代码与问题代码的唯一区别pGPIO1->GPBCON &= (~(0xFFFF << 16));变成pGPIO1->GPBCON = pGPIO1->GPBCON & (~(0xFFFF << 16));

难道这也有区别？那为什么会有这个区别呢？

纳闷…纠结…晕…

看来现在还不能给这个问题做一个全面的总结，只有以下几点教训：

用volatile时得多留些心眼，有时用了volatile也不一定管用；

对于MCU专用寄存器结构体的定义，最好内部加上volatile；

在定义寄存器结体指针变量时，尽量使用形如S3C6410_GPIO_REG*的方式，慎用PS3C6410_GPIO_REG；

在对MCU寄存器进行位运算时，尽量使用 a = a & b;的方式，慎用a &=b；

WinCE6.0中应用程序直接访问物理空间有隐患，谨慎使用；

VS2005的编译器优化很强大，必须小心优化过度，但不也能因噎废食;

只有弄清楚优化规则的来龙去脉，才能避免写出被编译器优化得面目全非的代码;

PS:疑惑还没有彻底解决，有知道的TX请明示，感兴趣的TX也请留言讨论，看晕了的TX请多包涵。祝各位节日快乐！

本文链接

Rebuild Current BSP and Subprojects的陷阱

2011-08-24T15:59:00Z

Rebuild Current BSP and Subprojects并不像通常所理解的，会强制重新编译整个BSP以及所有子工程，实际上，它仅仅强制重新编译了BSP，而子工程是没有强制重新编译的，这里说的强制重新编译是指以"build -c"的方式重新编译所有代码。

一般情况下，如果仅仅修改了BSP的代码，只需要编译BSP目录即可，如果修改了子工程的代码，也只需要编译该工程。这都是提高编译速度的一些小技巧，尽量少用很费时间的Sysgen和Clean Sysgen。

如果改变了项目的环境变量，且该环境变量影响了BSP和子工程。譬如多个型号的产品共用一个解决方案、一份BSP和子工程，在发布版本时，通过修改产品类型的环境变量，然后Rebuild Current BSP and Subprojects。本以为理所当然的事，却可能碰到奇怪的问题。修改产品类型后，Rebuild Current BSP and Subprojects，有一个子工程编译不过，而再单独编译一次该工程，又正常。

跟踪了一下Rebuild Current BSP and Subprojects的过程，发现子工程的代码并没有重新编译（因为没有修改代码，仅仅是根据环境变量在sources文件中设置了不同的宏定义和链接所用的库），而在链接时根据产品类型的定义使用了不同的lib库，库和代码不匹配导致链接错误。

找到问题的原因，解决起来就简单了。修改产品类型后，首先Rebuild All Subprojects，然后再Rebuild BSP。或者写一个批处理，在编译之前先手动Clean一下BSP和Subprojects，然后再Rebuild Current BSP and Subprojects。或者还可以自定义一个菜单，执行Rebuild All Subprojects和Rebuild BSP的操作，实现一键快速编译。

最后简单说明下Rebuild Current BSP and Subprojects的流程，首先执行"Starting Build: blddemo -c -qbsp"强制重新编译BSP，然后执行"BLDDEMO: Building PostSysgen User Projects call %_PROJECTOAKROOT%\PBPostSysgenProjects.bat"。打开PBPostSysgenProjects.bat文件，内容如下：

setlocal
pushd
cd /d C:\WINCE600\platform\tws89x\filters\tcccamfilter
build
if exist build.log type build.log >> %_WINCEROOT%\build.log
if exist build.wrn type build.wrn >> %_WINCEROOT%\build.wrn
if exist build.err type build.err >> %_WINCEROOT%\build.err
cd /d C:\WINCE600\platform\tws89x\filters\tccjpgencfilter
build
if exist build.log type build.log >> %_WINCEROOT%\build.log
if exist build.wrn type build.wrn >> %_WINCEROOT%\build.wrn
if exist build.err type build.err >> %_WINCEROOT%\build.err

Build All Subprojects和Rebuild All Subprojects则执行"Starting Build: call C:\Users\HJB\AppData\Local\Temp\PB\PBPostSysgenProjects.bat"，Rebuild All Subprojects对应的PBPostSysgenProjects.bat内容如下：

setlocal
pushd
set WINCEREL=1
cd /d C:\WINCE600\platform\tws89x\filters\tcccamfilter
build -c
cd /d C:\WINCE600\platform\tws89x\filters\tccjpgencfilter
build -c

本文链接

Windows Mobile中使用WinCE驱动调试助手的小技巧

2011-07-17T13:13:00Z

驱动调试助手是针对Windows CE做的，在Windows Mobile中使用会有一些问题，最主要的就是其菜单栏被Windows Mobile系统的任务栏给遮住了，导致相应的功能无法正常使用，如下图所示。

按理来说只要将系统任务栏隐藏就可以，今天在模拟器上实验了一下，看起来是可行的。只是任务栏隐藏后，相应的区域出现画屏，如下图所示。

不知道画屏是不是模拟器的缘故，暂且不管先。驱动调试助手的菜单隐约可见，简单测试了下其中的注册表搜索的功能，也正常工作，如下图所示。

实现方法如下，借助于一个WMDM.exe的程序，通过它隐藏系统任务栏并将同一目录下的DM.exe启动起来，在DM.exe退出后，恢复显示系统任务栏，代码如下。

1     HWND hWnd;
2     DWORD dwLen;
3     PROCESS_INFORMATION pi;
4     TCHAR szPath[MAX_PATH];
5
6     dwLen = GetModuleFileName(NULL, szPath, MAX_PATH);
7     if (!dwLen)
8     {
9         return 0;
10     }
11
12     while (szPath[--dwLen] != _T('\\'))
13     {
14         szPath[dwLen] = _T('\0');
15     }
16     wcscat(szPath, _T("DM.exe"));
17
18     hWnd = FindWindow(_T("HHTaskBar"), NULL);
19     if (hWnd)
20     {
21         EnableWindow(hWnd, FALSE);
22         ShowWindow(hWnd, SW_HIDE);
23     }
24
25     if(CreateProcess(szPath, NULL, NULL, 0, FALSE, 0, NULL, NULL, NULL, &pi))
26     {
27         WaitForSingleObject(pi.hProcess, INFINITE);
28         CloseHandle(pi.hThread);
29         CloseHandle(pi.hProcess);
30     }
31
32     EnableWindow(hWnd, TRUE);
33     ShowWindow(hWnd, SW_SHOW);

WMDM的下载地址:http://files.cnblogs.com/we-hjb/WMDM.rar,其中包括了ARMV4I版本的DM.exe。

本文链接

WinCE下监视设备插拔的参考代码

2011-06-28T14:36:00Z

在一些项目中，系统需要实时监测U盘或SD卡的插入拔出。当文件系统加载成功后通知特定应用程序，启动自动播放功能。在U盘或其他外部存储设备移除时，也需要立即通知相应的程序，停止访问这些设备，如播放其中的音视频文件，以免程序出错。

我们可以使用WinCE设备管理器提供的Device Interface Notification来实现这个功能，参考代码如下。

DWORD WINAPI ThreadFun(LPVOID lpParameter)
{
    HANDLE ph[MAXIMUM_WAIT_OBJECTS];
    HANDLE phMsgQueue[MAXIMUM_WAIT_OBJECTS-1];
    HANDLE phDevNotif[MAXIMUM_WAIT_OBJECTS-1];
    MSGQUEUEOPTIONS msgopts;
    GUID guid[] = {BLOCK_DRIVER_GUID, FSD_MOUNT_GUID};
    DWORD dwCount;
    BYTE pDevBuf[sizeof(DEVDETAIL) + MAX_DEVCLASS_NAMELEN * sizeof(TCHAR)] = {0};
    DEVDETAIL *pd = (DEVDETAIL*)pDevBuf;

    ghExitThread = CreateEvent(NULL, FALSE, FALSE, NULL);

    ph[0] = ghExitThread;
    dwCount = sizeof(guid)/sizeof(GUID);
    for (DWORD i = 0; i < dwCount; i++)
    {
        memset(&msgopts, 0, sizeof(msgopts));
        msgopts.dwFlags = 0;
        msgopts.dwSize = sizeof(msgopts);
        msgopts.dwMaxMessages = 0;
        msgopts.cbMaxMessage = sizeof(pDevBuf);
        msgopts.bReadAccess = TRUE;

        phMsgQueue[i] = CreateMsgQueue(NULL, &msgopts);
        phDevNotif[i] = RequestDeviceNotifications(guid+i, phMsgQueue[i], TRUE);

        ph[i+1] = phMsgQueue[i];
    }

    while (1)
    {
        DWORD dwSize;
        DWORD dwFlags;
        DWORD dwWait;
        DWORD dwQueue;

        dwWait = WaitForMultipleObjects(dwCount + 1, ph, FALSE, INFINITE);
        if ((dwWait <= WAIT_OBJECT_0) || (dwWait >= (WAIT_OBJECT_0 + dwCount + 1)))
        {
            break;
        }

        dwQueue = (dwWait - WAIT_OBJECT_0) - 1;

        while(ReadMsgQueue(phMsgQueue[dwQueue], pd, sizeof(pDevBuf), &dwSize, 1, &dwFlags))
        {
            if (GUID_ISEQUAL(pd->guidDevClass, BLOCK_DRIVER_GUID))
            {
                printf("\r\nDEV:%S %s", pd->szName, pd->fAttached ? "Add!" : "Removed!");
                if (pd->fAttached)
                {
                    Sleep(10);
                    printf("\r\nOpenStore!");
                    HANDLE h = OpenStore(pd->szName);
                    STOREINFO si;
                    memset(&si, 0 , sizeof(si));
                    si.cbSize = sizeof(si);
                    printf("\r\nGetStoreInfo!");
                    GetStoreInfo(h, &si);
                    printf("\r\n%S %x", si.szStoreName, si.dwDeviceType);
                    CloseHandle(h);
                }
            }
            else if(GUID_ISEQUAL(pd->guidDevClass, FSD_MOUNT_GUID))
            {
                printf("\r\nFSD:%S %s", pd->szName, pd->fAttached ? "Add!" : "Removed!");
            }
            Sleep(1);
        }
    }

    for (DWORD i = 0; i < dwCount; i++)
    {
        StopDeviceNotifications(phDevNotif[i]);
        CloseMsgQueue(phMsgQueue[i]);
    }
    CloseHandle(ghExitThread);

    return 0;
}

本文链接

Windows Embedded Compact 7移植成功

2011-05-12T15:41:00Z

世乒赛如火如荼的进行着，WinCE7的移植工作也紧张有序的开展起来。一边看着王浩打柳承敏，一边移植WinCE7。王浩有惊无险的赢了，WinCE7也基本移植成功了，高兴！

WinCE7的移植方法，在《Windows Embedded Compact 7初体验》中已经简单介绍过，具体细节有待进一步整理，先上两幅WinCE7的截图，这还是第一次亲见WinCE7的界面真身。啥也不说了，全在图里面。

本文链接

试用版Windows Embedded Compact 7的下载地址

2011-05-06T14:32:00Z

Windows Embedded Compact 7试用版已经发布一段时间了，微软官网提供的是在线安装包，不太方便下载和安装。微软嵌入式中文社区提供了离线安装包的下载，地址如下：

http://download.winitpro.com.cn/MS/MSEmbed/WinCompact7evaluation_1.rar
http://download.winitpro.com.cn/MS/MSEmbed/WinCompact7evaluation_2.rar

感谢David.Zang提供了方便，让广大WinCE的开发人员能在第一时间接触到WinCE7.0。

本文链接

WinCE流驱动加载的控制

2011-04-28T14:25:00Z

前段时间整理了《WinCE下调试串口的动态复用》，基本实现了调试串口与普通功能串口之间的动态切换。其中实现的方法有点欠缺，在重新烧录或者升级系统后，导致系统无法正常启动。这算是个BUG。该功能加上才几天，就陆续有好几个同事碰到。本来想着使用方便的，没想到反而增添了一些麻烦。

这个问题在实现时曾考虑到，发布版本的日志里也加了说明，如果启用了调试串口，那么在烧录或者升级系统前，须禁用调试串口。说实在的，确实有点麻烦，不小心就忘了做这个工作。而问题的根源是实现机制不太合理。调试串口的配置被分散在两处，一处是存储在NAND Flash的特定区域，另一处是注册表中。系统启动时，OAL根据Flash中保存的状态，确定是否启用调试串口，而驱动加载时又根据注册表的状态，确定是否加载调试串口的驱动。两处保存的状态不同步时，问题就出现了。问题分析清楚了，解决方法自然就有了，保证两处的状态一致即可。

调试串口的配置由存储在NAND Flash中的参数决定，系统启动时根据该值，动态修改调试串口对应的注册表配置，确保在启用调试串口时，不再加载它所对应的驱动，也就不会产生冲突，导致系统无法正常启动了。

在驱动注册表中，Flags是用于控制流驱动的加载行为的。其中DEVFLAGS_NOLOAD即表示不要加载该驱动。所以，在合适的地方添加如下代码，即可控制调试串口驱动的加载。

1 void DisableDebugSerial(BOOL bDisable)
2 {
3     HKEY Key;
4     DWORD Status;
5     DWORD Disposition;
6     DWORD Value;
7     DWORD Flags;
8
9     Status = RegCreateKeyEx(HKEY_LOCAL_MACHINE, L"Drivers\\BuiltIn\\Serial3", 0, NULL, 0, 0, NULL, &Key, &Disposition);
10
11     if (Status == ERROR_SUCCESS)
12     {
13         Value = bDisable ? DEVFLAGS_NONE : DEVFLAGS_NOLOAD;
14         RegSetValueEx(Key, DEVLOAD_FLAGS_VALNAME, 0, DEVLOAD_FLAGS_VALTYPE, (PBYTE)&Value, sizeof(Value));
15         RegCloseKey(Key);
16     }
17 }

如果禁用了调试串口，则将Flag是设置为DEVFLAGS_NONE，设备管理器将正常加载驱动。如果没有禁用调试串口，则将Flags设置为DEVFLAGS_NOLOAD，设备管理器就不会加载该驱动。

通过以上方法的改进，调试串口的动态复用就更方便了。

本文链接