世界上最先进的嵌入式GUI开发工具EmbeddedWizard, 现在新出了一个4.4版本,我download回来试了一下,发现已经支持touch screen & mouse了. 已经是 perfect 的EmbeddedWizard, 以后会不会还有激动人心的新特性呢

  preview some simple GUI examples designed by EW :

    

转自：http://winceblog.blogspot.com/2006/11/arm.html

平时大家接触最多的可能是X86平台，在这种系统上写程序几乎不需要考虑太多问题，但ARM上就不一样了，最常见也最容易被忽略的问题可能就是字节的对齐，即使像我这样有六七年程序开发经验的才手也时常难于提防，最近就有一个BUG，花了一天时间最终发现是对齐引发的，在此与大家分享，但愿大家能够注意到。

　　我在EBOOT中读取存在HARD　DISK上的nk.bin文件，从而从HARD　DISK上LOAD　WINCE系统，在这个过程中总是有check sum错误，但从ethernet下载时不会有错，所以问题应该还是在我加的这部分代码上，而且同样的代码在PC上能正常运行。经过检查代码的逻辑关系是正确的。接着我在出错时将那些数据全部用调试信息打出来，发现从文件开始算起第4096个字节被丢掉了，而其它的字节都是对的。初步判断是对齐引发的问题，所以去查每一个BUFFER，最终发现是在读取硬盘数据时BUFFERR并没有按双字节对齐，而硬盘以16BIT读取数据，而引发了错误。

实际上，这类问题在ARM系统上很常见，让人防不胜防，以下是我的一些例子。

1，解析数据流时应该时刻注意。如果需要把一个数据流（BUFFER）转化成结构进行取值，就应该把这个结构定义为按字节存取.考虑如下结构：

struct a{

char a;
short b;
long c;
};
如果某个数据流中包含这样的结构，而且我们要直接将数据流的指针转化成该结构的指针，然后直接取结构成员的值，我们就应该将这个结构定义成按字节访问，即将其夹在语句
#pragma pack(push,1)
...

#pragma pack(pop)
之中。如果我们不这样做，编译器会将成员b的地址对齐到short指针的地址，即在a之后加上一个char即8位的成员，将C对齐到LONG，即在B之后再加一个char成员。如此一来，成员B和成员C就得不到正确的值了。

如果我们定义一个普通的结构用来存放一些数据，则不用定义成按字节存取，编译器会加上一些占位成员，但并不会影响程序的运行。从这个意义上讲，在ARM中，将结构成员定义成CHAR和SHORT来节约内存是没有意义的。

一个典型的例子就文件系统的驱动程序，文件是以一些已经定义好的结构存放在存储介质上的，它们被读取到一个BUFFER中，而具体取某个文件、目录结构时，我们会将地址转化成结构而读取其中的值。


2，访问外设时。
例如，磁盘驱动通常以16BIT的方式存取数据，即每次存取两个字节，这样就要求传给它的BUFFER是双字节对齐的，驱动程序应该至上层传来的指针做出正确的处理以保证数据的正确性。


3.有时，我们没有将数据流指针转化为结构指针取值，但如果我们读取的是双字节或者是四字节的数据，同样需要注意对齐的问题，例如，如果从一个BUFFER的偏移10处读取一个四字节值，则实际得到的值是偏移8处的
地址上的DWORD值。

关于此主题的全部 3 个帖子 - 树式浏览

I have a well-tested, ruggedized windows ce 4.2 device.  A new application has been written for this device which is failing with a fatal application error dialog (Exception: 0xC0000005).  I believe this is a data access exception, usually caused by a null pointer dereference.  The real catch here is, this exception ONLY occurs at cold temperature, -15 deg C and below. I do not have access to the application source code at this time.  I only have the BSP. Has anyone come across this type of application exception during cold temperature use? 回复 »

First thing to do is isolate exactly where the exception is occurring and what the actual cause is. (It might NOT be a null dereference). The temp factor suggests there is a code path in the BSP or the application that is not exercised until the temperature changes. This could be due to timing and timeouts as well as silicon status information etc... (Forgetting to read a data ready bit on a chip that works fine at normal temps but gets sluggish at lower temps etc.. are also possibilities). Using the "Windows Error Reporting (e.g DrWatson Dumps), and capture COMPLETE system dumps would help identify the exact source of the problem as well. -- Steve Maillet EmbeddedFusion www.EmbeddedFusion.com smaillet at EmbeddedFusion dot com 回复 »

Thanks for replying to this Steve. Turned out to be a RAM issue which was only present at cold temps.  RAM tests in boot loader failed at cold temps. Slowing the sdclk memory clock seems to help.

- Compile the kernel with debug symbols.
- Start code composer and let the ARM and DSP run free so that uBoot executes.
- Load the ELF kernel image to SDRAM
- Happy debugging

 

Don't use CCS to compile Linux, it will not work.
Use the Linux toolchain and build the kernel the normal way.
At the end of the Linux build there will be an ELF image in the images directory.
Use CCS to load that ELF.
CCS can load ELF files including symbols.