EVB：其实我也不知道这三个字母是哪些单词的缩写，不过这个不重要，其实就是手机里面的硬件设备放到一块板子上，在写入正确的software load之后能够运行代码。该板子比最后我们要生产出来的手机要大不少，因为这样可以简化硬件布局设计和生产时间，使用起来也比较方便。它包含了一个手机需要包含的大多数硬件设备，但是某些能能模块可能没有完成，在该板子上，我们主要测试正常开机和一些比较简单的APP。有特殊要求的一些APP，比如call,bt,往往会因为硬件环境没准备好而无法执行。

EVT：EVT其实和EVB一样，只是这块板在大小上和布局上，更像手机了。我曾戏称“EVT就是更像手机的EVB”来解释EVT。因为EVT更小，但是同样没有手机外壳的支撑保护，所以使用的时候要特别小心，不然它的哪根“神经”(线路)断了都不一定知道。

EVB/EVT Porting：刚才介绍的EVB/EVT是从硬件层面上的，有些计算机里的“裸机”的概念。其实我要完成的EVB/EVT Porting任务，就是将特定的project source编译出来的image（主要是那些mbn文件）load到EVB/EVT中，然后开机，让它正确地跑到Idle（可以理解成计算机里的桌面），进而进入各个App。所以这里有两个关键的任务：1.能够正确build出来；2.开机流程正确，可以正确跑进Idle。

第一步：build通过

其实只是让它编译链接通过，没有什么特别的，只是很费时间而已。build主要的两个阶段编译和链接，编译阶段的错误多数只是语法上的，将发现的错误一个个改正再编译就没有问题了，只是需要时间而已；链接阶段的错误多数是要么找不到某个符号，要么有多个符号，导致不知道用哪个来链接（这里的符号指一些函数和全局的变量）。这里倒有几个经验技巧和大家分享。

1. 如果在编译阶段中途手动停掉编译，需要注意将正在编译的源文件生成的对应对象文件（.o文件）删除，否则下一次编译成功后很可能会链接不过。这是编译原理决定的：在编译阶段，每个源文件(c/cpp)会对应生成一个.o文件，在链接阶段，会将这些.o文件链接在一起。而默认情况下，为了缩短编译时间，并不会直接去将每个源文件都编译生成.o文件，而是先去找同名的.o文件，如果没有找到或者.o文件的最后修改时间比源文件的最后修改时间早，则会去编译该源文件，生成.o文件，否则就认为原来的.o文件是可用的，不需要编译，则跳过。所以在手动停止编译的时候，真给编译的源文件的.o文件可能已经生成，但是并没有编译完成，也就是说该.o文件是不完整的；如果以后并没有修改该源文件，因为对应的.o文件已经生成且比该源文件新，就不会去重新编译，生成正确的.o文件。所以最后链接的时候就会出错了。出错的时候还很诡异，当你发现对应的链接错误，你会定位到该文件，结果你会发现这个文件中的代码并没有问题，然后你就丈二和尚摸不着头脑了。

2. 文件内的全局变量或函数使用static关键字，使起只在文件内其作用：因为工程中文件个数上万，而开发者也有几百，很难保证你使用的全局变量别人在其他文件不会声明使用，尤其是名字比较common的，大家都容易想到的，这样一来就会有重定义的错误。所以：要尽量缩小变量或函数的作用域，文件内的全局函数或变量使用static使其限定在文件内。

3. 如果在链接是发现有找不到的符号，去搜索源文件有没有对应的函数会变量，如果有，则需要去检查所在文件对应的.o文件有没有生成。因为代码中加了，不一定就是编译了的。如果.o也生成了，可以看看是不是被宏包起来了；如果.o文件没有生成，看看该源文件有没有放入正确的.min文件，并确定该min文件是不是起作用。归纳起来就是两件事：一是源文件有没有被正确编译，二是代码有没有被宏包起来导致没有编译到。

第二步：调试开机

调试开机之前，你根本不会想到会有哪些问题，甚至会认为会比较顺利，一开机，就不小心进了Idle。事实往往比想象得复杂，基本上花在调试开机上的时间会占总时间的60%以上。

调试的工具是大家都比较熟悉的trace32，不过刚开始的时候，我只会使用trace32 download，并不会使用它来调试，连设置最简单的断点都不会。所以如果不大熟悉，需要先学会简单的使用。（哈哈，还好，platform那边的兄弟个个是高手，教我不少，感谢他们！）

大体上，我们是按照“公交线路式”的方法进行调试的。刚开机是起始点（公交始发站），进入Idle是终止点（公交终点站），在之间设置了多个中点（中间站点）。调试的过程就是让一辆公交车（程序指令）从始发站出发，经过各个中间站点，最后到达终点站的过程。因为司机是第一次在该路线上驾车，所以在中间的时候总会迷路，我们需要帮助他一个站点一个站点的往下走。

下面来分享一些经验技巧，不过也是比较初级的，高手们请不要见笑：

1. 使用trace32打断点：因为这个是使用trace32调试时最经常使用到的，所以在这里简单说一下。使用trace32打断点有很多途径，可以通过菜单项先找到函数，也可以先找到文件再找函数。不过为了节约时间，可以使用命令来快速完成：
        break.set functionName /onchip
如果functionName指示错误，会有提示的，functionName不管是在debug版本还是非debug版本都可以使用的（只是在非debug版本里看不到原始的code而已）。onchip类型的断点只能同时enable两个，而且onchip的断点比较可靠，所以基本上我们只使用onchip类型的断点，所以同时只能使用两个断点。另外点击高级按钮，可以打开高级的断点设置，包括设置一定的条件，设置计数器等。

2. 在EVB Porting的时候，我们碰到了一个比较麻烦的问题，第一次开机能够显示画面，但是之后开机就只能看到白屏（屏幕发白光），尽管已经确认Form已经创建成功，并顺利push到了rootform，而且display也确实有调用update的函数。我们知道在BREW中，刷屏实际上是使用IDisplay_Update来完成的，尽管我们使用的是BUIW，其实也不例外。所以我们希望能够找到display update的函数处打个断点，确定有没有跑到--这就是我要说的在这些地方打断点，需要对Brew中接口的实现要有一定的了解，不然很可能找不到函数名而不知道在哪里打断点。类似的还有IShell_CreateInstance, IShell_StartApplet等。这些是需要我们去猜测的，尽管我们可以看到这些函数名在对象结构体中的成员名，但是并不是函数名，我们可以使用部分搜索的方法来找到。BREW提供给我们使用的“函数”叫接口，用I左右前缀，而在内部实现它叫类，用“C”做为前缀。比如IShell_StartApplet函数，真正的实现函数名为CShell_StartApplet。也有的代码并没有“C”来做前缀，只是把"I"前缀去掉而已。回到屏幕不能显示画面的问题，最后幸亏platform的人发现LCD的电压为0（尽管开着背光灯，两者两码事）。

3. 在BREW3上，我们知道applet的handle event函数收到的第一个事件是EVT_APP_START，不过这次在调试时，发现在BREW4上，handle event函数收到的第一个事件是EVT_APP_START_WINDOW(后来得知这个事件是专门给运行在background的applet用的)。
 

Tip #1: Code for the phone, not the emulator.
Handsets are small form factor, constrained devices — so relative to what you're used to on the desktop, phones have limited speed, limited resources, small screens, and a limited ARM processor. You have to remember that the emulator has amazing speed (your 2GHz desktop machine at full speed, for example), emulated resources, incorrect use of screen size for many of the skins, and an x86 processor. The emulator is just that; it's not a phone.

Here's a closer look at each of the four main development issues when using an emulator to code for a BREW phone:

• Speed. Phones have fairly slow processors. Don't expect to be able to do complex math calculations in real-time for a simulation.

   

• Limited resources. Phones have a small amount of storage, and policy of specific phones (such as the Z-800) can make that even more limiting than it seems at first. Also, an application's code is loaded into RAM from storage (just like a traditional PC, but unlike many PDAs). This means even less RAM is available than you may have originally expected. A good case in point is the Kyocera 3035; it has 60 kilobytes of RAM available. If your application is 35 kilobytes, then only 25 kilobytes remain for processing.

    

• Screen size. These are small screens, even by PDA standards. Design the UI the way you see them on other phones: That is — keep it simple. Don't try to do too much on one screen. Instead, break a screen up and have a menu to access the various portions of it so everything is clean and uncluttered.

    

• Don't forget that the target for the application is an ARM processor. The application must compile for the ARM processor. Start with this example: make files. Although they aren't the best design, they have the settings that are required for this particular ARM processor. Don't try to change them to compile your application; that won't work. Instead, fix the code. Common mistakes include doing division, using global or static variables, and, when compiling in Visual Studio, ignoring Level 4 warnings, which often become errors using the ARM compiler.

Make sure to build often with the ARM compiler and test often on the phone. QUALCOMM has recently made this much easier by providing the BREW Logger for download. This allows you to see the DBGPRINTF messages on your PC while you're debugging on the phone. This beats grabbing debug files on the phone!

Most IO calls in BREW are non-blocking. What this means is that the action doesn't actually take place right when the call is made. That would have made it synchronous. For instance, if you make a call to ISOCKET_Connect(), you have to provide a callback routine. What happens here, at least as far as we are concerned, is the action to do the ISOCKET_Connect() is placed on a system stack, and the call returns immediately, returning control to the application. If we want the action to actually occur, we must return to the system before it can happen.

All of this means that the best BREW applications will need to be designed from the ground up to work well within an asynchronous system. Sure, there are ways of somewhat mechanically converting a synchronous application to work in an asynchronous system, but for anything but the simplest of applications, this can get very complex very quickly.

Another effect of this is that when an application is busy, nothing else is occurring on the phone. Since this is a phone, that's a bad thing. A phone is still primarily for voice calls. If your application is busy doing something, a voice call can't occur (at least the part of notifying the user that a voice call is incoming) until your application returns to the system. Because of this, there is a watchdog timer. If an application spends too much time without returning to the system, the phone will reset. This means that if an application is going to do some processing, some of the flow of control should be passed via sending events to itself. This is easily accomplished by using EVT_USER events with ISHELL_PostEvent(). (I don't recommend ISHELL_SendEvent() as that causes the event to happen synchronously, which is not what we want.)

There are a number of BREW system calls that require the application to be waiting for a callback before flow will continue. What if this never occurs? Well, the obvious effect is that control will never return to your application, and the user will think it has hung. This is actually quite a common occurrence (for example, a phone indoors may not have very good network coverage). This is easily solved by using ISHELL_SetTimer() with your own callback. Don't worry: If the event occurs before the timer, you can easily cancel the timer by using ISHELL_CancelTimer().

Tip #3: Know How to Handle Your Events.
As mentioned in the previous tip, BREW is very event-driven. As such, an application will get many events that it may not be expecting. Controls talk to themselves using events. The system sends events to the application to tell it a variety of things about the state of the phone. All of these need some action taken by the application. Because of this, a well-designed event handler is required for a stable application.

It is the application's responsibility to make sure all controls being used get the messages they require to function properly. It is not defined what all of the events are, so the best way to handle this is to take special action on those events you know about and may want to intercept occasionally (such as the arrow keys or CLR key) and have a default handler that passes everything else to any active controls to see if they can handle the event.

Handling the CLR key (event code of EVT_KEY with a wParam of AVK_CLR) is a special case in BREW. A well-designed application will have the CLR key behaving as a backspace when in text entry controls, as a back key to go back a screen, and exiting the application when on the main screen. This means an application needs to watch for it and perhaps do something special. If FALSE is ever returned from handling the CLR key, the application will exit. Except at the main screen, this is likely not the action you want the application to take.

One of the most important events to handle properly in any application is the suspend event (EVT_APP_SUSPEND). If an application receives this, it means that the phone wants to do something, such as notifying the user of a voice call or maybe an SMS message. QUALCOMM defines a bunch of things that an application must do before returning from a suspend event. These things including closing down all used sockets, stopping all timers, and deactivating all controls, among many other things. An application will not pass testing if these aren't done.

Originally published in the BREW Wireless Resource Center

　　PalmOS是Palm公司的是一种32位的嵌入式操作系统，它的操作界面采用触控式，差不多所有的控制选项都排列在屏幕上，使用触控笔便可进行所有操作。作为一套极具开放性的系统，开发商向用户免费提供Palm操作系统的开发工具，允许用户利用该工具在Palm操作系统的基础上编写、修改相关软件，使支持Palm的应用程序丰富多彩、应有尽有。

　　 PalmOS是Palm公司开发的专用于PDA上的一种操作系统，这是PDA上的霸主，一度普占据了90%的PDA市场的份额。虽然其并不专门针对于手机设计，但是PalmOS的优秀性和对移动设备的支持同样使其能够成为一个优秀的手机操作系统。其最新的版本为PalmOS5.2。目前具有手机功能的PalmPDA如Palm公司的TungstenW。而Handspring公司（目前已被Palm公司收购）的Treo系列则是专门使用Palm OS的手机，如Treo 270以及最新的倍受瞩目的Treo 650。

　　Palm OS操作系统特性

　　Palm操作系统最明显的优势还在于其本身是一套专门为掌上电脑编写的操作系统，在编写时充分考虑到了掌上电脑内存相对较小的情况，所以Palm操作系统本身所占的内存极小，基于Palm操作系统编写的应用程序所占的空间也很小，通常只有几十KB，所以基于Palm操作系统的掌上电脑虽然只有几兆内存却可以运行众多的应用程序。

　　Palm在其它方面还存在一些不足，Palm操作系统本身不具有录音、MP3播放功能等，如果你需要使用这些功能，就需要另外加入第三方软件或硬件设备方可实现。对于中国用户而言，另一个不足之处在于Palm操作系统起初在中国销售的产品仍然要使用中文外挂平台，有相当部分依然是以英文界面为主，在一定程度上影响了基于Palm操作系统的产品在中国市场的大面积进入。其代表性的产品有Palmm505、Palmm500、PalmIII等。

　　绍特表示，对他而言，2GB内存是Windows XP的最佳配置，而Vista则需要4GB内存。Vista之所以需要如此大的内存，主要原因是Windows SuperFetch。SuperFetch的主要作用是从硬盘读取数据，并保存在可用内存中，以便于处理器访问。如果操作系统认为用户将在特定时间访问特定软件，就会预先将该软件加载到可用内存之中。这一设定的好处在于，如果用户拥有足够大的内存，就可以加快处理器访问速度，缩短软件响应时间。不利之处在于，它需要大量的内存。

　　根据微软提供的资料，主频800MHz的处理器和512MB内存是运行Vista的最低配置。但显而易见，这样的配置无法流畅地运行Vista。绍特表示，很多硬件厂商推出的PC虽然号称支持Vista，但配置较低，消费者应当注意到这一点。事实上，微软此前推出的Vista PC样机已经配备了4GB内存。(奥托)

硬件类型字段：指明了发送方想知道的硬件接口类型，以太网的值为1；

协议类型字段：指明了发送方提供的高层协议类型，IP为0800（16进制）；

硬件地址长度和协议长度：指明了硬件地址和高层协议地址的长度，这样ARP报文就可以在任意硬件和任意协议的网络中使用；
       
操作字段：用来表示这个报文的类型，ARP请求为1，ARP响应为2，RARP请求为3，RARP响应为4；
       
发送方的硬件地址（0-3字节）：源主机硬件地址的前3个字节；
       
发送方的硬件地址（4-5字节）：源主机硬件地址的后3个字节；
       
发送方IP（0-1字节）：源主机硬件地址的前2个字节；
       
发送方IP（2-3字节）：源主机硬件地址的后2个字节；
       
目的硬件地址（0-1字节）：目的主机硬件地址的前2个字节；
       
目的硬件地址（2-5字节）：目的主机硬件地址的后4个字节；
       
目的IP（0-3字节）：目的主机的IP地址。

2.  ARP和RARP的工作原理

ARP的工作原理如下：

1.  首先，每台主机都会在自己的ARP缓冲区 (ARP Cache)中建立一个 ARP列表，以表示IP地址和MAC地址的对应关系。

2.  当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP列表中是否存在该 IP地址对应的MAC地址，如果有﹐就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。

3.  网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个 ARP响应数据包，告诉对方自己是它需要查找的MAC地址；
4.        源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。

RARP的工作原理：

1.  发送主机发送一个本地的RARP广播，在此广播包中，声明自己的MAC地址并且请求任何收到此请求的RARP服务器分配一个IP地址；

2. 本地网段上的RARP服务器收到此请求后，检查其RARP列表，查找该MAC地址对应的IP地址；

3. 如果存在，RARP服务器就给源主机发送一个响应数据包并将此IP地址提供给对方主机使用；

4. 如果不存在，RARP服务器对此不做任何的响应；

5. 源主机收到从RARP服务器的响应信息，就利用得到的IP地址进行通讯；如果一直没有收到RARP服务器的响应信息，表示初始化失败。
 

准备好了吗？

请听题：一副扑克抽取掉大小司令（大小鬼）后还剩52张，从中随机取出2张，请问取到的两张刚好是一红一黑的概率是多少？

三！二！一！

时间到！！！

请问你回答出来了吗？如果已经有答案了，请赶快留言报名（还有你的答案）哦！

HDMI不仅可以满足目前最高画质1080P的分辨率，还能支持DVD Audio等最先进的数字音频格式，支持八声道96kHz或立体声192kHz数码音频传送，而且只用一条HDMI线连接，免除数字音频接线。同时HDMI标准所具备的额外空间可以应用在日后升级的音视频格式中。足以应付一个1080p的视频和一个8声道的音频信号。而因为一个1080p的视频和一个8声道的音频信号需求少于4GB/s，因此HDMI还有很大余量。这允许它可以用一个电缆分别连接DVD播放器，接收器和PRR。此外HDMI支持EDID、DDC2B，因此具有HDMI的设备具有“即插即用”的特点，信号源和显示设备之间会自动进行“协商”，自动选择最合适的视频/音频格式。

与DVI相比HDMI接口的体积更小，而且可同时传输音频及视频信号。DVI的线缆长度不能超过8米，否则将影响画面质量，而HDMI最远可传输15米。只要一条HDMI缆线，就可以取代最多13条模拟传输线，能有效解决家庭娱乐系统背后连线杂乱纠结的问题。

优点：
HDMI规格的接口在保持高品质的情况下能够以数码的形式传输未经压缩的高分辨率视频和多声道音频的数据。 其卓越性能超越了以往所有的产品。
HDMI规格的连接器采用单线连接，取代了产品背后的复杂的线缆。
采用HDMI规格接口的线缆没有长度的限制。比如：DVI的线缆长度不能超过8米，否则将影响画面质量，而符合HDMI规格的产品则没有这个问题。
HDMI规格可搭配宽带数字内容保护（HDCP），以防止具有著作权的影音内容遭到未经授权的复制。

boolean bSetItem, 表明本次是在GetItem还是SetItem时调用的

uint32 itemID, 当前GetItem或SetItem的Item的ID值

char *pType, 当前Item的类型（分为好几种类型的，比如Flash Item/EFS Item/NV Item等）

void *pData, 当前设置到Item或从Item得到的数据，可以是各种类型（包括复杂的结构体类型，也包括简单的字符串、布尔值、整型等）

int length, pData的字节数