屏幕操作
现在要解决的问题是，嵌入式系统中经常要使用的并非是完整的汉字库，往往只是需要提供数量有限的汉字供必要的显示功能。例如，一个微波炉的LCD上没有必要提供显示"电子邮件"的功能；一个提供汉字显示功能的空调的LCD上不需要显示一条"短消息"，诸如此类。但是一部手机、小灵通则通常需要包括较完整的汉字库。
如果包括的汉字库较完整，那么，由内码计算出汉字字模在库中的偏移是十分简单的：汉字库是按照区位的顺序排列的，前一个字节为该汉字的区号，后一个字节为该字的位号。每一个区记录94个汉字，位号则为该字在该区中的位置。因此，汉字在汉字库中的具体位置计算公式为：94*(区号-1)+位号-1。减1是因为数组是以0为开始而区号位号是以1为开始的。只需乘上一个汉字字模占用的字节数即可，即：(94*(区号-1)+位号-1)*一个汉字字模占用字节数，以16*16点阵字库为例，计算公式则为：(94*(区号-1)+(位号-1))*32。汉字库中从该位置起的32字节信息记录了该字的字模信息。
对于包含较完整汉字库的系统而言，我们可以以上述规则计算字模的位置。但是如果仅仅是提供少量汉字呢？譬如几十至几百个？最好的做法是：
定义宏：
| # define EX_FONT_CHAR(value) # define EX_FONT_UNICODE_VAL(value) (value), # define EX_FONT_ANSI_VAL(value) (value), |
定义结构体：
| typedef struct _wide_unicode_font16x16 { WORD value; /* 内码 */ BYTE data[32]; /* 字模点阵 */ }Unicode; #define CHINESE_CHAR_NUM … /* 汉字数量 */ |
字模的存储用数组：
| Unicode chinese[CHINESE_CHAR_NUM] = { { EX_FONT_CHAR("业") EX_FONT_UNICODE_VAL(0x4e1a) {0x04, 0x40, 0x04, 0x40, 0x04, 0x40, 0x04, 0x44, 0x44, 0x46, 0x24, 0x4c, 0x24, 0x48, 0x14, 0x50, 0x1c, 0x50, 0x14, 0x60, 0x04, 0x40, 0x04, 0x40, 0x04, 0x44, 0xff, 0xfe, 0x00, 0x00, 0x00, 0x00} }, { EX_FONT_CHAR("中") EX_FONT_UNICODE_VAL(0x4e2d) {0x01, 0x00, 0x01, 0x00, 0x21, 0x08, 0x3f, 0xfc, 0x21, 0x08, 0x21, 0x08, 0x21, 0x08, 0x21, 0x08, 0x21, 0x08, 0x3f, 0xf8, 0x21, 0x08, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00} }, { EX_FONT_CHAR("云") EX_FONT_UNICODE_VAL(0x4e91) {0x00, 0x00, 0x00, 0x30, 0x3f, 0xf8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0c, 0xff, 0xfe, 0x03, 0x00, 0x07, 0x00, 0x06, 0x40, 0x0c, 0x20, 0x18, 0x10, 0x31, 0xf8, 0x7f, 0x0c, 0x20, 0x08, 0x00, 0x00} }, { EX_FONT_CHAR("件") EX_FONT_UNICODE_VAL(0x4ef6) {0x10, 0x40, 0x1a, 0x40, 0x13, 0x40, 0x32, 0x40, 0x23, 0xfc, 0x64, 0x40, 0xa4, 0x40, 0x28, 0x40, 0x2f, 0xfe, 0x20, 0x40, 0x20, 0x40, 0x20, 0x40, 0x20, 0x40, 0x20, 0x40, 0x20, 0x40, 0x20, 0x40} } } |
要显示特定汉字的时候，只需要从数组中查找内码与要求汉字内码相同的即可获得字模。如果前面的汉字在数组中以内码大小顺序排列，那么可以以二分查找法更高效的查找到汉字的字模。
这是一种很有效的组织小汉字库的方法，它可以保证程序有很好的结构。
系统时间显示
从NVRAM中可以读取系统的时间，系统一般借助NVRAM产生的秒中断每秒读取一次当前时间并在LCD上显示。关于时间的显示，有一个效率问题。因为时间有其特殊性，那就是60秒才有一次分钟的变化，60分钟才有一次小时变化，如果我们每次都将读取的时间在屏幕上完全重新刷新一次，则浪费了大量的系统时间。
一个较好的办法是我们在时间显示函数中以静态变量分别存储小时、分钟、秒，只有在其内容发生变化的时候才更新其显示。
| extern void DisplayTime(…) { static BYTE byHour,byMinute,bySecond; BYTE byNewHour, byNewMinute, byNewSecond; byNewHour = GetSysHour(); byNewMinute = GetSysMinute(); byNewSecond = GetSysSecond(); if(byNewHour!= byHour) { … /* 显示小时 */ byHour = byNewHour; } if(byNewMinute!= byMinute) { … /* 显示分钟 */ byMinute = byNewMinute; } if(byNewSecond!= bySecond) { … /* 显示秒钟 */ bySecond = byNewSecond; } } |
这个例子也可以顺便作为C语言中static关键字强大威力的证明。当然，在C++语言里，static具有了更加强大的威力，它使得某些数据和函数脱离"对象"而成为"类"的一部分，正是它的这一特点，成就了软件的无数优秀设计。
动画显示
动画是无所谓有，无所谓无的，静止的画面走的路多了，也就成了动画。随着时间的变更，在屏幕上显示不同的静止画面，即是动画之本质。所以，在一个嵌入式系统的LCD上欲显示动画，必须借助定时器。没有硬件或软件定时器的世界是无法想像的：
（1） 没有定时器，一个操作系统将无法进行时间片的轮转，于是无法进行多任务的调度，于是便不再成其为一个多任务操作系统；
（2） 没有定时器，一个多媒体播放软件将无法运作，因为它不知道何时应该切换到下一帧画面；
（3） 没有定时器，一个网络协议将无法运转，因为其无法获知何时包传输超时并重传之，无法在特定的时间完成特定的任务。
因此，没有定时器将意味着没有操作系统、没有网络、没有多媒体，这将是怎样的黑暗？所以，合理并灵活地使用各种定时器，是对一个软件人的最基本需求！
在80186为主芯片的嵌入式系统中，我们需要借助硬件定时器的中断来作为软件定时器，在中断发生后变更画面的显示内容。在时间显示"xx:xx"中让冒号交替有无，每次秒中断发生后，需调用ShowDot：
| void ShowDot() { static BOOL bShowDot = TRUE; /* 再一次领略static关键字的威力 */ if(bShowDot) { showChar(’:’,xPos,yPos); } else { showChar(’ ’,xPos,yPos); } bShowDot = ! bShowDot; } |
菜单操作
无数人为之绞尽脑汁的问题终于出现了，在这一节里，我们将看到，在C语言中哪怕用到一丁点的面向对象思想，软件结构将会有何等的改观！
笔者曾经是个笨蛋，被菜单搞晕了，给出这样的一个系统：
 图1 菜单范例 |
要求以键盘上的"← →"键切换菜单焦点，当用户在焦点处于某菜单时，若敲击键盘上的OK、CANCEL键则调用该焦点菜单对应之处理函数。我曾经傻傻地这样做着：
| /* 按下OK键 */ void onOkKey() { /* 判断在什么焦点菜单上按下Ok键，调用相应处理函数 */ Switch(currentFocus) { case MENU1: menu1OnOk(); break; case MENU2: menu2OnOk(); break; … } } /* 按下Cancel键 */ void onCancelKey() { /* 判断在什么焦点菜单上按下Cancel键，调用相应处理函数 */ Switch(currentFocus) { case MENU1: menu1OnCancel(); break; case MENU2: menu2OnCancel(); break; … } } |
终于有一天，我这样做了：
| /* 将菜单的属性和操作"封装"在一起 */ typedef struct tagSysMenu { char *text; /* 菜单的文本 */ BYTE xPos; /* 菜单在LCD上的x坐标 */ BYTE yPos; /* 菜单在LCD上的y坐标 */ void (*onOkFun)(); /* 在该菜单上按下ok键的处理函数指针 */ void (*onCancelFun)(); /* 在该菜单上按下cancel键的处理函数指针 */ }SysMenu, *LPSysMenu; |
当我定义菜单时，只需要这样：
| static SysMenu menu[MENU_NUM] = { { "menu1", 0, 48, menu1OnOk, menu1OnCancel } , { " menu2", 7, 48, menu2OnOk, menu2OnCancel } , { " menu3", 7, 48, menu3OnOk, menu3OnCancel } , { " menu4", 7, 48, menu4OnOk, menu4OnCancel } … }; |
OK键和CANCEL键的处理变成：
| /* 按下OK键 */ void onOkKey() { menu[currentFocusMenu].onOkFun(); } /* 按下Cancel键 */ void onCancelKey() { menu[currentFocusMenu].onCancelFun(); } |
程序被大大简化了，也开始具有很好的可扩展性！我们仅仅利用了面向对象中的封装思想，就让程序结构清晰，其结果是几乎可以在无需修改程序的情况下在系统中添加更多的菜单，而系统的按键处理函数保持不变。
面向对象，真神了！
模拟MessageBox函数
MessageBox函数，这个Windows编程中的超级猛料，不知道是多少入门者第一次用到的函数。还记得我们第一次在Windows中利用MessageBox输出 "Hello,World!"对话框时新奇的感觉吗？无法统计，这个世界上究竟有多少程序员学习Windows编程是从MessageBox ("Hello,World!",…)开始的。在我本科的学校，广泛流传着一个词汇，叫做"’Hello,World’级程序员"，意指入门级程序员，但似乎"’Hello,World’级"这个说法更搞笑而形象。
  图2 经典的Hello,World! |
图2给出了两种永恒经典的Hello,World对话框，一种只具有"确定"，一种则包含"确定"、"取消"。是的，MessageBox的确有，而且也应该有两类！这完全是由特定的应用需求决定的。
嵌入式系统中没有给我们提供MessageBox，但是鉴于其功能强大，我们需要模拟之，一个模拟的MessageBox函数为：
| /****************************************** /* 函数名称: MessageBox /* 功能说明: 弹出式对话框,显示提醒用户的信息 /* 参数说明: lpStr --- 提醒用户的字符串输出信息 /* TYPE --- 输出格式(ID_OK = 0, ID_OKCANCEL = 1) /* 返回值: 返回对话框接收的键值,只有两种 KEY_OK, KEY_CANCEL /****************************************** typedef enum TYPE { ID_OK,ID_OKCANCEL }MSG_TYPE; extern BYTE MessageBox(LPBYTE lpStr, BYTE TYPE) { BYTE keyValue = -1; ClearScreen(); /* 清除屏幕 */ DisplayString(xPos,yPos,lpStr,TRUE); /* 显示字符串 */ /* 根据对话框类型决定是否显示确定、取消 */ switch (TYPE) { case ID_OK: DisplayString(13,yPos+High+1, " 确定 ", 0); break; case ID_OKCANCEL: DisplayString(8, yPos+High+1, " 确定 ", 0); DisplayString(17,yPos+High+1, " 取消 ", 0); break; default: break; } DrawRect(0, 0, 239, yPos+High+16+4); /* 绘制外框 */ /* MessageBox是模式对话框，阻塞运行，等待按键 */ while( (keyValue != KEY_OK) || (keyValue != KEY_CANCEL) ) { keyValue = getSysKey(); } /* 返回按键类型 */ if(keyValue== KEY_OK) { return ID_OK; } else { return ID_CANCEL; } } |
上述函数与我们平素在VC++等中使用的MessageBox是何等的神似啊？实现这个函数，你会看到它在嵌入式系统中的妙用是无穷的。
总结
本篇是本系列文章中技巧性最深的一篇，它提供了嵌入式系统屏幕显示方面一些很巧妙的处理方法，灵活使用它们，我们将不再被LCD上凌乱不堪的显示内容所困扰。
屏幕乃嵌入式系统生存之重要辅助，面目可憎之显示将另用户逃之夭夭。屏幕编程若处理不好，将是软件中最不系统、最混乱的部分，笔者曾深受其害。
键盘操作
功能键的问题在于，用户界面并非固定的，用户功能键的选择将使屏幕画面处于不同的显示状态下。例如，主画面如图1：
 图1 主画面 |
当用户在设置XX上按下Enter键之后，画面就切换到了设置XX的界面，如图2：
 图2 切换到设置XX画面 |
程序如何判断用户处于哪一画面，并在该画面的程序状态下调用对应的功能键处理函数，而且保证良好的结构，是一个值得思考的问题。
让我们来看看WIN32编程中用到的"窗口"概念，当消息（message）被发送给不同窗口的时候，该窗口的消息处理函数（是一个callback函数）最终被调用，而在该窗口的消息处理函数中，又根据消息的类型调用了该窗口中的对应处理函数。通过这种方式，WIN32有效的组织了不同的窗口，并处理不同窗口情况下的消息。
我们从中学习到的就是：
（1）将不同的画面类比为WIN32中不同的窗口，将窗口中的各种元素（菜单、按钮等）包含在窗口之中；
（2）给各个画面提供一个功能键"消息"处理函数，该函数接收按键信息为参数；
（3）在各画面的功能键"消息"处理函数中，判断按键类型和当前焦点元素，并调用对应元素的按键处理函数。
| /* 将窗口元素、消息处理函数封装在窗口中 */ struct windows { BYTE currentFocus; ELEMENT element[ELEMENT_NUM]; void (*messageFun) (BYTE keyValue); … }; /* 消息处理函数 */ void messageFunction(BYTE keyValue) { BYTE i = 0; /* 获得焦点元素 */ while ( (element .ID!= currentFocus)&& (i < ELEMENT_NUM) ) { i++; } /* "消息映射" */ if(i < ELEMENT_NUM) { switch(keyValue) { case OK: element.OnOk(); break; … } } } |
在窗口的消息处理函数中调用相应元素按键函数的过程类似于"消息映射"，这是我们从WIN32编程中学习到的。编程到了一个境界，很多东西都是相通的了。其它地方的思想可以拿过来为我所用，是为编程中的"拿来主义"。
在这个例子中，如果我们还想玩得更大一点，我们可以借鉴MFC中处理MESSAGE_MAP的方法，我们也可以学习MFC定义几个精妙的宏来实现"消息映射"。
处理数字键
用户输入数字时是一位一位输入的，每一位的输入都对应着屏幕上的一个显示位置（x坐标，y坐标）。此外，程序还需要记录该位置输入的值，所以有效组织用户数字输入的最佳方式是定义一个结构体，将坐标和数值捆绑在一起：
| /* 用户数字输入结构体 */ typedef struct tagInputNum { BYTE byNum; /* 接收用户输入赋值 */ BYTE xPos; /* 数字输入在屏幕上的显示位置x坐标 */ BYTE yPos; /* 数字输入在屏幕上的显示位置y坐标 */ }InputNum, *LPInputNum; |
那么接收用户输入就可以定义一个结构体数组，用数组中的各位组成一个完整的数字：
| InputNum inputElement[NUM_LENGTH]; /* 接收用户数字输入的数组 */ /* 数字按键处理函数 */ extern void onNumKey(BYTE num) { if(num==0|| num==1) /* 只接收二进制输入 */ { /* 在屏幕上显示用户输入 */ DrawText(inputElement[currentElementInputPlace].xPos, inputElement[currentElementInputPlace].yPos, "%1d", num); /* 将输入赋值给数组元素 */ inputElement[currentElementInputPlace].byNum = num; /* 焦点及光标右移 */ moveToRight(); } } |
将数字每一位输入的坐标和输入值捆绑后，在数字键处理函数中就可以较有结构的组织程序，使程序显得很紧凑。
整理用户输入
继续第2节的例子，在第2节的onNumKey函数中，只是获取了数字的每一位，因而我们需要将其转化为有效数据，譬如要转化为有效的XXX数据，其方法是：
| /* 从2进制数据位转化为有效数据：XXX */ void convertToXXX() { BYTE i; XXX = 0; for (i = 0; i < NUM_LENGTH; i++) { XXX += inputElement.byNum*power(2, NUM_LENGTH - i - 1); } } |
反之，我们也可能需要在屏幕上显示那些有效的数据位，因为我们也需要能够反向转化：
| /* 从有效数据转化为2进制数据位：XXX */ void convertFromXXX() { BYTE i; XXX = 0; for (i = 0; i < NUM_LENGTH; i++) { inputElement.byNum = XXX / power(2, NUM_LENGTH - i - 1) % 2; } } |
当然在上面的例子中，因为数据是2进制的，用power函数不是很好的选择，直接用"<< >>"移位操作效率更高，我们仅是为了说明问题的方便。试想，如果用户输入是十进制的，power函数或许是唯一的选择了。
总结
本篇给出了键盘操作所涉及的各个方面：功能键处理、数字键处理及用户输入整理，基本上提供了一个全套的按键处理方案。对于功能键处理方法，将LCD屏幕与Windows窗口进行类比，提出了较新颖地解决屏幕、键盘繁杂交互问题的方案。
计算机学的许多知识都具有相通性，因而，不断追赶时髦技术而忽略基本功的做法是徒劳无意的。我们最多需要"精通"三种语言（精通，一个在如今的求职简历里泛滥成灾的词语），最佳拍档是汇编、C、C++（或JAVA），很显然，如果你"精通"了这三种语言，其它语言你应该是可以很快"熟悉"的，否则你就没有"精通"它们.
性能优化
在C语言中，宏是产生内嵌代码的唯一方法。对于嵌入式系统而言，为了能达到性能要求，宏是一种很好的代替函数的方法。
写一个"标准"宏MIN ，这个宏输入两个参数并返回较小的一个：
错误做法：
| #define MIN(A,B) ( A <= B ? A : B ) |
正确做法：
| #define MIN(A,B) （（A）<= (B) ? (A) : (B) ) |
对于宏，我们需要知道三点：
(1)宏定义"像"函数；
(2)宏定义不是函数，因而需要括上所有"参数"；
(3)宏定义可能产生副作用。
下面的代码：
| least = MIN(*p++, b); |
将被替换为：
| ( (*p++) <= (b) ?(*p++):(b) ) |
发生的事情无法预料。
因而不要给宏定义传入有副作用的"参数"。
使用寄存器变量
当对一个变量频繁被读写时，需要反复访问内存，从而花费大量的存取时间。为此，C语言提供了一种变量，即寄存器变量。这种变量存放在CPU的寄存器中，使用时，不需要访问内存，而直接从寄存器中读写，从而提高效率。寄存器变量的说明符是register。对于循环次数较多的循环控制变量及循环体内反复使用的变量均可定义为寄存器变量，而循环计数是应用寄存器变量的最好候选者。
(1) 只有局部自动变量和形参才可以定义为寄存器变量。因为寄存器变量属于动态存储方式，凡需要采用静态存储方式的量都不能定义为寄存器变量，包括：模块间全局变量、模块内全局变量、局部static变量；
(2) register是一个"建议"型关键字，意指程序建议该变量放在寄存器中，但最终该变量可能因为条件不满足并未成为寄存器变量，而是被放在了存储器中，但编译器中并不报错（在C++语言中有另一个"建议"型关键字：inline）。
下面是一个采用寄存器变量的例子：
| /* 求1+2+3+….+n的值 */ WORD Addition(BYTE n) { register i,s=0; for(i=1;i<=n;i++) { s=s+i; } return s; } |
本程序循环n次，i和s都被频繁使用，因此可定义为寄存器变量。
内嵌汇编
程序中对时间要求苛刻的部分可以用内嵌汇编来重写，以带来速度上的显著提高。但是，开发和测试汇编代码是一件辛苦的工作，它将花费更长的时间，因而要慎重选择要用汇编的部分。
在程序中，存在一个80-20原则，即20%的程序消耗了80%的运行时间，因而我们要改进效率，最主要是考虑改进那20%的代码。
嵌入式C程序中主要使用在线汇编，即在C程序中直接插入_asm{ }内嵌汇编语句：
| /* 把两个输入参数的值相加，结果存放到另外一个全局变量中 */ int result; void Add(long a, long *b) { _asm { MOV AX, a MOV BX, b ADD AX, [BX] MOV result, AX } } |
利用硬件特性
首先要明白CPU对各种存储器的访问速度，基本上是：
CPU内部RAM > 外部同步RAM > 外部异步RAM > FLASH/ROM
对于程序代码，已经被烧录在FLASH或ROM中，我们可以让CPU直接从其中读取代码执行，但通常这不是一个好办法，我们最好在系统启动后将FLASH或ROM中的目标代码拷贝入RAM中后再执行以提高取指令速度；
对于UART等设备，其内部有一定容量的接收BUFFER，我们应尽量在BUFFER被占满后再向CPU提出中断。例如计算机终端在向目标机通过RS-232传递数据时，不宜设置UART只接收到一个BYTE就向CPU提中断，从而无谓浪费中断处理时间；
如果对某设备能采取DMA方式读取，就采用DMA读取，DMA读取方式在读取目标中包含的存储信息较大时效率较高，其数据传输的基本单位是块，而所传输的数据是从设备直接送入内存的（或者相反）。DMA方式较之中断驱动方式，减少了CPU 对外设的干预，进一步提高了CPU与外设的并行操作程度。
活用位操作
使用C语言的位操作可以减少除法和取模的运算。在计算机程序中数据的位是可以操作的最小数据单位，理论上可以用"位运算"来完成所有的运算和操作，因而，灵活的位操作可以有效地提高程序运行的效率。举例如下：
| /* 方法1 */ int i,j; i = 879 / 16; j = 562 % 32; /* 方法2 */ int i,j; i = 879 >> 4; j = 562 - (562 >> 5 << 5); |
对于以2的指数次方为"*"、"/"或"%"因子的数学运算，转化为移位运算"<< >>"通常可以提高算法效率。因为乘除运算指令周期通常比移位运算大。
C语言位运算除了可以提高运算效率外，在嵌入式系统的编程中，它的另一个最典型的应用，而且十分广泛地正在被使用着的是位间的与（&）、或（|）、非（~）操作，这跟嵌入式系统的编程特点有很大关系。我们通常要对硬件寄存器进行位设置，譬如，我们通过将AM186ER型80186处理器的中断屏蔽控制寄存器的第低6位设置为0（开中断2），最通用的做法是：
| #define INT_I2_MASK 0x0040 wTemp = inword(INT_MASK); outword(INT_MASK, wTemp &~INT_I2_MASK); |
而将该位设置为1的做法是：
| #define INT_I2_MASK 0x0040 wTemp = inword(INT_MASK); outword(INT_MASK, wTemp | INT_I2_MASK); |
判断该位是否为1的做法是：
| #define INT_I2_MASK 0x0040 wTemp = inword(INT_MASK); if(wTemp & INT_I2_MASK) { … /* 该位为1 */ } |
上述方法在嵌入式系统的编程中是非常常见的，我们需要牢固掌握。
总结
在性能优化方面永远注意80-20准备，不要优化程序中开销不大的那80%，这是劳而无功的。
宏定义是C语言中实现类似函数功能而又不具函数调用和返回开销的较好方法，但宏在本质上不是函数，因而要防止宏展开后出现不可预料的结果，对宏的定义和使用要慎而处之。很遗憾，标准C至今没有包括C++中inline函数的功能，inline函数兼具无调用开销和安全的优点。
使用寄存器变量、内嵌汇编和活用位操作也是提高程序效率的有效方法。
除了编程上的技巧外，为提高系统的运行效率，我们通常也需要最大可能地利用各种硬件设备自身的特点来减小其运转开销，例如减小中断次数、利用DMA传输方式等。
在嵌入式领域目标系统的应用系统日趋复杂，而由于竞争要求产品快速上市，开发技术日新月异，同时硬件发展的日益稳定，而软件故障却日益突出，软件的重要性逐渐引起人们的重视，越来越多的人认识到嵌入式系统的测试势在必行。提到嵌入式软件测试，首先要简单介绍一些软件工程的一些观点，现在，被普遍接受的软件的定义是：软件(software)是计算机系统中与硬件(hardware)相互依存的另一部分，它包括程序(program)、相关数据(data)及其说明文档(document)。其中程序是按照事先设计的功能和性能要求执行的指令序列；数据是是程序能正常操纵信息的数据结构；文档是与程序开发维护和使用有关的各种图文资料。
对于一般商用软件的测试，嵌入式软件测试有其自身的特点和测试困难。
由于嵌入式系统的自身特点，如实时性(Real-timing)，内存不丰富，I / O通道少，开发工具昂贵，并且与硬件紧密相关CPU种类繁多，等等。嵌入式软件的开发和测试也就与一般商用软件的开发和测试策略有了很大的不同，可以说嵌入式软件是最难测试的一种软件。
嵌入式软件测试使用有效的测试策略是唯一的出路，它可以使开发的效率最大化，避免目标系统的瓶颈，使用在线仿真器节省昂贵的目标资源。自从出现高级语言，开发环境与最终运行环境通常都是存在差异的，嵌入式系统更是如此。开发环境被认为是主机平台，软件运行环境为目标平台。相应的测试为host-target测试或cross-testing。
讨论嵌入式软件测试首先就会遇到一个问题：为什么不把所有测试都放在目标上进行呢？因为若所有测试都放在目标平台上有很多不利的因素：
1）测试软件，可能会造成与开发者争夺时间的瓶颈，避免它只有提供更多的目标环境。
2）目标环境可能还不可行。
3）比起主机平台环境，目标环境通常是不精密的和不方便的。
4）提供给开发者的目标环境和联合开发环境通常是很昂贵的。
5）开发和测试工作可能会妨碍目标环境已存在持续的应用
从经济上和开发效率上考虑，软件开发周期中尽可能大的比例在主机系统环境中进行， 其中包括测试。
确定host-target测试环境后，开发测试人员又会遇到以下的问题：
1）多少开发人员会卷入测试工作（单元测试，软件集成，系统测试）?
2）多少软件应该测试，测试会花费多长时间？
3）在主机环境和目标环境有哪些软件工具，价格怎样，适合怎样?
4）多少目标环境可以提供给开发者，什么时候?
5）主机和目标机之间的连接怎样？
6）被测软件下载到目标机有多快?
7）使用主机与目标环境之间有什么限制（如软件安全标准）?
任何人或组织进行嵌入式软件的测试都应深入考虑以上问题，结合自身实际情况，选定合理测试策略和方案。
对于嵌入式软件测试或叫交叉测试（cross-test），在测试的各个阶段有着通用的策略：
1．单元测试：
所有单元级测试都可以在主机环境上进行，除非少数情况，特别具体指定了单元测试直接在目标环境进行。最大化在主机环境进行软件测试的比例，通过尽可能小的目标单元访问所有目标指定的界面。
在主机平台上运行测试速度比在目标平台上快的多，当在主机平台完成测试，可以在目标环境上重复作一简单的确认测试，确认测试结果在主机和目标机上没有被他们的不同影响。在目标环境上进行确认测试将确定一些未知的，未预料到的，未说明的主机与目标机的不同。例如，目标编译器可能有bug，但在主机编译器上没有。
2．集成测试：
软件集成也可在主机环境上完成，在主机平台上模拟目标环境运行，当然在目标环境上重复测试也是必须的，在此级别上的确认测试将确定一些环境上的问题，比如内存定位和分配上的一些错误。
在主机环境上的集成测试的使用，依赖于目标系统的具体功能有多少。有些嵌入式系统与目标环境耦合的非常紧密，若在主机环境做集成是不切实际的。一个大型软件的开发可以分几个级别的集成。低级别的软件集成在主机平台上完成有很大优势，越往后的集成越依赖于目标环境。
3．系统测试和确认测试
所有的系统测试和确认测试必须在目标环境下执行。当然在主机上开发和执行系统测试，然后移植到目标环境重复执行是很方便的。对目标系统的依赖性会妨碍将主机环境上的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，所以有时放弃在主机环境上执行系统测试可能更方便。
确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真实系统之下测试，而不能在主机环境下模拟。这关系到嵌入式软件的最终使用。
包括恢复测试、安全测试、强度测试、性能测试，已超出了软件测试的范畴，本文暂不讨论。
使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率，当然正确的测试工具使用也是必不可少的：
总结一下，应用以上测试工具进行.Cross-test时的策略：
A) 使用测试工具的插装功能（主机环境）执行静态测试分析，并且为动态覆盖测试准备好一插装好的软件代码。
B) 使用源码在主机环境执行功能测试，修正软件的错误和测试脚本中的错误。
C) 使用插装后的软件代码执行覆盖率测试，添加测试用例或修正软件的错误，保证达到所要求的覆盖率目标。
D) 在目标环境下重复（B），确认软件在目标环境中执行测试的正确性。
E) 若测试需要达到极端的完整性，最好在目标系统上重复（C），确定软件的覆盖率没有改变。
通常在主机环境执行多数的测试，只是在最终确定测试结果和最后的系统测试才移植到目标环境，这样可以避免发生访问目标系统资源上的瓶颈，也可以减少在昂贵资源如在线仿真器上的费用。另外，若目标系统的硬件由于某种原因而不能使用时，最后的确认测试可以推迟直到目标硬件可用，这为嵌入式软件的开发测试提供了弹性。设计软件的可移植性是成功进行cross-test的先决条件，它通常可以提高软件的质量，并且度软件的维护大有益处。以上所提到的测试工具，都可以通过各自的方式提供测试在主机与目标之间的移植，从而使嵌入式软件的测试得以方便的执行。
使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率，提高嵌入式软件的质量。
附录：
1)HOST-TARGET的连接方法简介： 
直接连接 
通过仿真器连接 
使用介质进行间接连接 
使用PROM等传递被测软件 
测试的交互界面 
无交互界面的连接