1、嵌入式发展趋势
1、嵌入式开发是一项系统工程，要求嵌入式系统厂商不仅要提供嵌入式软硬件系统本身，同时还需要提供强大的硬件开发工具和软件包支持。很多厂商充分考虑到这一点，在主推系统的同时，将开发环境也作为重点推广。比如三星、ARM在推广Arm7，Arm9芯片的同时还提供开发板和板级支持包（BSP）。
2、 网络化、信息化的要求随着因特网技术的成熟、带宽的提高日益提高，使得以往单一功能的设备如电话、手机、冰箱、微波炉等功能不再单一，结构更加复杂。这就要求芯片设计厂商在芯片上集成更多的功能，为了满足应用功能的升级，设计师们一方面采用更强大的嵌入式处理器如32位、64位RISC芯片或信号处理器DSP增强处理能力，同时增加功能接口。
3、网络互联成为必然趋势。未来的嵌入式设备为了适应网络发展的要求，必然要求硬件上提供各种网络通信接口。传统的单片机对于网络支持不足，而新一代的嵌入式处理器已经开始内嵌网络接口，除了支持TCP/IP协议，还有的支持IEEE1394、USB、CAN、Bluetooth或IrDA通信接口中的一种或者几种，同时也需要提供相应的通信组网协议软件和物理层驱动软件。软件方面系统系统内核支持网络模块，甚至可以在设备上嵌入Web浏览器，真正实现随时随地用各种设备上网。
4．精简系统内核、算法，降低功耗和软硬件成本。未来的嵌入式产品是软硬件紧密结合的设备，为了减低功耗和成本，需要设计者尽量精简系统内核，只保留和系统功能紧密相关的软硬件，利用最低的资源实现最适当的功能，这就要求设计者选用最佳的编程模型和不断改进算法，优化编译器性能。因此，既要软件人员有丰富的硬件知识，又需要发展先进嵌入式软件技术，如Java、Web和WAP等。
5．提供友好的多媒体人机界面嵌入式设备能与用户亲密接触，最重要的因素就是它能提供非常友好的用户界面。图像界面，灵活的控制方式，使得人们感觉嵌入式设备就象是一个熟悉的老朋友。这方面的要求使得嵌入式软件设计者要在图形界面，多媒体技术上痛下苦功。手写文字输入、语音拨号上网、收发电子邮件以及彩色图形、图像都会使使用者获得自由的感受。一些先进的PDA在显示屏幕上已实现汉字写入、短消息语音发布，但一般的嵌入式设备距离这个要求还有很长的路要走。
6、对于企业专用解决方案，如物流管理、条码扫描、移动信息采集等，这种小型手持嵌入式系统将发挥巨大的作用。自动控制领域，不仅可以用于ATM机，自动售货机，工业控制等专用设备，和移动通讯设备结合、GPS、娱乐相结合，嵌入式系统同样可以发挥巨大的作用。
7、在广播电视领域，美国已开始由模拟电视向数字电视转变，欧洲的DVB（数字电视广播）技术已在全球大多数国家推广。数字音频广播（DAB）也已进入商品化试播阶段。而软件、集成电路和新型元器件在产业发展中的作用日益重要。所有上述产品中，都离不开嵌入式系统技术。象前途无可计量的维纳斯计划生产机顶盒，核心技术就是采用32位以上芯片级的嵌入式技术。
2功能与作用
嵌入式开发板（Embedded development board），从概念上来讲，与软件外包非常类似（软件外包是指软件外包提供商为了集中精力从事核心竞争力业务,降低项目成本,同时提高项目实施的质量,将自己的软件项目中的全部或部分工作发包给合适的软件企业去完成）。像嵌入式产品的硬件、引导代码、驱动程序、文件系统、协议层、基本应用软件这些方面，都是电子产品的公共和通用部分，并不是产品能够形成差异化的关键技术，在这个讲求分工合作的时代，如果是这部分的工作量比较大，或者是厂商没有相关的开发人员的时候，就能够选择由第三方完成这些软件开发的工作，加快产品研发的进程，实现产品的迅速上市，抢占市场先机。
那么，作为“发包方”的开发板用户，选择开发板的时候，实际上选择的不仅是一个硬件板子、开发板提供的源代码等资源，而是选择一个合作伙伴，一个为用户提供软硬件服务的合作伙伴。与软件外包这种合作方式类似，用户和供应商之间的合作更多是软件方面的合作，需要用户和供应商之间根据产品的具体需求进行充分沟通，供应商要根据用户的需求不断地调用人员进行配合。像我们在支持客户进行产品开发的过程中，遇到的比如更改文件系统、串口测试、64M Flash换成128M Flash等问题，大多情况都是要通过软件方式来解决的，这就形成了嵌入式行业供应商的售后支持和客户研发的高度互动性。
也就是说，嵌入式开发板是用户软件外包的载体，相对于传统的软件外包业务，开发板实际上能够为用户提供硬件实物和软件服务两方面的价值。
在嵌入式行业中，除了嵌入式开发板，外包的形式也趋向多样化，用户能够根据自己的产品需要，向供应商提出定制要求，由供应商提供硬件设计和驱动移植等方面的服务；有可能电子厂商会自己设计硬件，由嵌入式系统厂商帮助其完成系统的移植、驱动的完善工作。从行业链上的作用来看，嵌入式系统厂商能够采用灵活的服务方式，利用自己的技术优势帮助电子产品厂商缩短产品开发周期、节省设计资源方面的投资，促进电子产品厂商的快速发展。
3选购建议
以嵌入式开发板的功能和作用作为出发点，嵌入式开发板选型应该从以下三个方面来综合考虑：
（一）开发板的硬件设计是基本照搬半导体厂商的参考设计，还是充分为国内厂家生产制造、产品上市等方面考虑。
半导体厂商专注于芯片的设计，对参考设计的投入一定不会像开发板的厂商一样，能够做到专注专业。国外芯片厂商的工程师，在做参考设计的时候，习惯上会采用在本国使用比较多的外围芯片。这样，半导体厂商的参考设计对国内厂商提供的参考价值有限。
所以，在选择开发板的时候，无论是出于最终产品的性能和功能考虑，还是为后期能够更加方便地制造生产，用户一定要擦亮眼睛，仔细对比一下供应商提供的开发板是不是更加适合自己的产品研制和生产。
（二）开发板的软件是否支持完善，是否能够支持所有开发板上所有的硬件接口。
开发板的价值就在于，能够让用户节省在系统、驱动等方面的投入，专注于使产品形成差异化的上层软件的开发。如果供应商提供的开发板，板级硬件接口没有对应的软件驱动的支持，用户的开发进度就会受到影响 。在购买开发板的时候 ，一定要确认清楚 ，是不是所有的硬件接口都有相应的驱动，开发板是不是拿到手就能够马上用来做开发。
（三）供应商的技术支持力度如何。
嵌入式行业是客户研发和售后支持具有高度互动性的行业，供应商的技术支持有时就会成为用户产品上市的关键因素，在供应商的技术支持能力方面，一定要慎重考察。
考察一个供应商能不能提供充分的支持，一个有效的方法就是到这个公司的技术支持论坛上看看。在论坛上，用户发贴询问的问题，是不是能够及时得到回复。没有专业的支持团队的公司，没有办法为用户提供及时的支持。用户在论坛上发贴询问，有的厂商一个月才给用户一个答复，有的甚至不予回答。
是否能够提供完备的技术支持，是一个开发板公司是不是专业的开发板公司，是不是能够发挥在产业链上承上启下的作用，是不是能够为用户创造价值的重要标准。这个道理实际上应该很浅显，开发板厂商的入门门槛并不高，只要有硬件设计能力，参考半导体厂商的参考设计，就能够推出开发板产品。如果不能够为用户或者不给用户提供技术支持，这样的厂商能够为用户提供的就只是一个硬件板子，即使是市面上两千多的板子，如果是非专业厂商提供的话，供应商所获得的利润也是很高的，因为这些厂家的成本只是开发板的硬件成本和销售成本；专业的开发板公司，需要承担的研发成本、售后支持成本、运营成本和销售成本均摊下来，不一定有非专业公司的盈利高，市面上开发板的价格为什么会有那么大的价格差别，原因也可见一斑。
总之，用户在购买开发板的时候，选择的不是开发板，而是为自己提供服务的合作伙伴。开发板的价格是公司服务价值的体现，所以目前很多追求最低价开发板的消费理念是偏颇的。选择开发板，选择一个为自己服务的公司，一定要慎重。在半导体行业里面，开发板厂商就是衔接上下游厂商的链条。质量上乘的链条，能够快速地将用户送上新品促进市场良性循环的金光大道；劣质的链条，关键时刻，掉链子了，用户需要修修补补，就会被竞争对手赶超，再好的产品创意也会逐渐失去价值。
4行业情况
嵌入式开发板的原型，可以说是各大芯片厂商在推出芯片的时候，提供给用户的参考设计。很正常，半导体厂商在推广自己芯片的时候，单单拿芯片给用户看是没有任何吸引力的，一定要给用户看到具体的电路板，具体的接口，能够给客户一个具体的印象，才能够保证推广的效果；半导体厂商给出这些参考设计，也是让用户在设计的时候有一个参考，加快他们产品设计和上市的进度。
无论是8位、16位单片机，还是32位能够运行 *** 作系统的嵌入式处理器，半导体厂商都有这样的参考设计。对应的，市面上有很多向用户提供开发板的厂商。
嵌入式处理器不断推陈出新，早期摩托罗拉半导体（现飞思卡尔半导体）68K/Coldfire和PowerPC处理器的一枝独秀已经一去不返，ARM、Coldfire、PowerPC和ADSP还有基于MIPS、X86体系结构的嵌入式处理器百花齐放、处理器厂商以及处理器架构厂商各显神通，半导体行业的上游企业给开发板厂商的出现和成长提供很好的契机。
特别是2002年底2003年，ARM体系结构在国内的风行，给很多想要基于自己的嵌入式技术进行创业的人送来了东风。大江南北几乎每个省级城市都会有开发板厂商。这段时间以及之后入行的公司有一个共同的特点，就是产品基本都是基于ARM处理器进行开发，或者是仿真器类的 ARM 工具进行开发。这些厂商能够为用户提供具有不同接口功能的开发板，从整体上看是能够为电子产品的制造商提供服务，加速半导体产业链下游厂商产品的上市。[1]
5嵌入式开发板硬件驱动
大部分嵌入式硬件都需要某种类型的软件进行初始化和管理。直接与一个硬件互相作用并控制这一硬件的软件称为设备驱动程序（device driver）。所有需要软件的嵌入式系统，在它们的系统软件层都需要设备驱动程序软件。设备驱动程序是初始化硬件的软件库，它们管理着高层软件对硬件的访问，它是硬件与 *** 作系统、中间件和应用层之间联络的纽带。具体来说，这类驱动程序包括主处理器体系结构专用的功能性驱动程序、存储器和存储器管理驱动程序、总线初始化和事务驱动程序、还有电路板层和主CPU层次的I/O初始化和控制驱动程序（如用于网络、图形、输入设备、存储设备、调试I/O等）。设备驱动程序通常划分为体系结构专用（architecture-specific）设备驱动程序和通用（generic）设备驱动程序。体系结构专用设备驱动程序管理嵌入到主处理器（体系结构）中的硬件。体系结构专用驱动程序负责初始化主处理器内部的组件，这类驱动程序的具体事例包括片上存储器、集成的存储器管理器（MMU）和浮点硬件的驱动程序。通用设备驱动程序管理电路板上的硬件以及没有集成到主处理器中的硬件。在一个通用设备驱动程序中，通常包含一部分体系结构专用的源代码，因为主处理器是中央控制单元，要访问电路板上的任何组件通常都要经过主处理器。然而，通用驱动程序也可以管理不被特定的处理器所专用的板级硬件，这就意味着一个通用驱动程序可以配置应用到许多体系结构中去，只要该结构中包含该驱动程序对应的硬件。通用驱动程序包含初始化和管理对电路板上剩余主要组件进行访问的代码，这些主要组件包括板级总线（I2C、PCI、PCMCIA等）、片外存储器（控制器、2级以上高速缓存、闪存等）和片外I/O（以太网、RS-232、显示器、鼠标等）。
1、首先我想知道你的C/S架构的程序编程语言是什么？是C、Java还是啥？
2、是java的话，我你使用开源测试工具abbot，它包括录制功能，它的测试用例是用XML写的，但是我建议你可以根据自己的需求进行aboot的修改，可以修改为直接调用其底层的对象识别API，然后上层自己拓建。至于。你想实现填表单工作
1）靠录制，然后加一个for循环，不过这要是用abbot的XML实现较麻烦，因为XML的逻辑实现不好，那你可以自己写一个XML解析函数，用一个程序自动化更新XML用例
3、是MC的程序的话，商用的很多都可以。个人觉得：你用C自动化测试的话，最好能够自己去做一些自动化测试工具，是应用一些方法 *** 作C控件吗，这样的话，你可以找一些 *** 作接口拓展自己的控件 *** 作库，灵活而且复用性好，方法有：
1）应用MSAA提供的接口，MSAA的全称是MicrosoftActiveAessibility。这是类似DCOM技术。技术模型是这样的，UI程序可以暴露出一个Interface，方便另一个程序对其进行控制。MSAA技术的初衷是为了方便残疾人使用Windows程序。比如盲人看不到窗口，但是盲人可以通过一个USB读屏器连接到电脑上，读屏器通过UI程序暴露出来的这个Interface，就可以获取程序信息，通过盲文或者其它形式传递给盲人。MSAA提供了如此方便的功能，UI自动化测试自然可以借用这项技术。MSAA暴露出来的Interface叫做IAessible。
2）每个windows窗口都有句柄，找到了窗口句柄我们就能够对其进行一系列 *** 作。在找寻句柄的属性下，你可以用SPYC进行识别。
4、net程序的话，我记得VS2010自带的CUIT工程就可以，其包含录制和回放API，蛮好的
嵌入式系统调试方法和注意事项嵌入式系统开发过程实际上就是一个调试诊断的过程，而且调试诊断将一直伴随着一个产品的终身，即使是最成熟的产品也偶尔会出现这样或那样的问题，这都需要开发人员去诊断、排查。
嵌入式系统的调试包括硬件调试、软件调试以及综合调试。硬件调试一般是指系统刚开发出来时上电前后的检查，包括：
1）上电前检查电源和地是否短路，目视检查是否有虚焊、漏焊；
2）上电后检查时钟线上的频率和波形、幅度是否正常，各电源电压是否稳定正常，各芯片温度是否正常，各指示灯是否正常。
软件调试一般是指保证硬件一切正常的情况下验证程序执行的时序是否正确，逻辑和结果是否与设计要求相符，能否满足功能和性能要求等。软件调试的方法有很多，包括： 1）用指示灯跟踪调试； 2）用串口打印调试；
3）用简单的调试器进行汇编代码级调试； 4）用比较高端的调试器进行源代码级调试； 5）用仿真器进行硬件仿真。
上述单纯的硬件调试或软件调试都是相对比较简单的，困难的是综合调试。下面我先举一些自己在工作中曾经碰到的疑难问题，然后再从中归纳出一些一般的调试方法和注意事项。
例 1：我们自主设计制作的PPC860（Motorola）网络引擎平台的调试已接近尾声，同一批生产的4块板子都通过了全部软件测试，于是又去焊了第二批，可是在第二批板子中有1块板子的FEC不能正常工作，我们几个软件和硬件工程师使用了各种手段，重新看了多遍芯片手册，还是没找出原因，于是把板子发回工厂重新焊接BGA，可是回来问题还是照样存在，没办法最后打算将这块板子当作个样处理，把板子上的芯片都焊下来。按常理来说这种做法很符合逻辑，因为元器件都是一样的，板子也是一批的，那就可能是这块板子的某个地方焊接不好，但又不好查，反复重新焊接可能会把主板焊坏。后来有人从PPC860芯片上用放大镜都要睁大眼睛才能看清的字符上（据说我国第一代国产高端处理器芯片“寒心”就是某“科学家”将“摩托”同一类型芯片上的这些字母磨掉后刻上“寒心一号”摇身一变造出来的！！！）发现这块板子的CPU版本号是“D4”，而其他板子的CPU版本号是“D3”，可芯片手册上并没有这两个版本之间的比较说明，从网上找到PPC860的勘误手册，发现在PPC860TZP50D4版本中，ECNTRL寄存器增加了一个叫FEC_PIN_MUX的位（bit2）来控制FEC各管脚的复用功能，如果要使用FEC就必须将该位设置为1，所以要在FEC的相关程序中加上ECNTRL |= 0x00000004语句行。
例2：当我调试业余自制的MC68VZ328板子时，电路板硬件检查没有问题，用Code warrior通过串口往flash中烧制编译好的uClinux程序也一切正常，但是重新上电，发现串口没有任何数据，用万用表检查（当时自己没有示波器等“先进设备”）也没查出结果，然后每天上下班把这块板子放在包里，没事就拿出来瞪大眼睛看看，看着也不免窝火，但有一天却发现一个标着电阻符号的地方却焊上了电容，回到家把电阻换上去再上电，串口一下就打印出uClinux的启动信息，呵，那滋味，比喝了蜂蜜都甜，当然当时也是因为没有太多经验，如果这问题放现在，估计一天内肯定解决掉。另外在初次调试自制的S3C4510开发板时，就是不能从串口输出字符，费了半天时间才发现把串口电平转换芯片 max3232cse的第6脚上的旦电容极性焊反了。--中嵌学院--
例3：在调试SB1250嵌入式服务器主板时，由于使用的是DDR1代内存条，数据线和时钟线上串并联的去耦电容电阻相当多，第一批焊回来的板子几乎没有一块能够顺利进入CFE（BIOS）菜单界面的，检查时钟波形和电源与借用的 DEMO板相比都很好，我把主板上DDR DIM槽周围的那些去耦电阻电容都全部用烙铁重新过一遍锡，嘿嘿，还真管用，这种方法屡试不爽，而且在后面调试PCI和HT总线时使用这招也很有用，可能是因为SB1250系统是高频电路，对焊接要求比较高，稍微有一点漏焊或者虚焊都不行，我是这样认为的。
例4：在一个使用实时时钟芯片 SD2000的应用系统中，经常会出现读出的时间被复位到 “2000年1月1日”的情况，我用自己编写的测试程序经过多次测试发现，按照SD2000芯片手册中的时序进行连续读写确实会经常出现复位现象，好像是芯片错把读写时序当成了复位 *** 作时序，而且每次必出，所以我感觉到芯片本身应该有Bug，于是告诉同事可能是芯片本身有问题，让他跟厂家联系，但因为这个芯片在老产品中用了比较长的时间，所以同事不太认同我的看法，但还是与SD2000厂家取得了联系，厂家经过两天专门强化测试后通知我们“SD2000本身确实有Bug，可能因为干扰导致芯片复位到2000年1月1日”。--中嵌学院--
例5：在用PNX1700（DSP）处理器设计成的音视频开发平台上，常会出现CVBS输出黑白图像（应该是彩色）或颜色不正常现象，于是先详细阅读CVBS输出芯片AVS3169的手册，然后用示波器测量3169芯片的时钟管脚，在测量的过程中经常会出现颜色恢复正常的现象，再做多次测试发现这种现象是由于将场同步VSYNC信号与相邻的数据线Data7短路造成的，再测试发现将VSYNC与其他数据线（Data[0:6]）任一根短接一下都可以恢复正常，再用视频时钟信号CLK与数据线短接一下有时也能恢复正常，但有时也不能恢复，所以怀疑是视频场同步信号有问题。顺着这根线索查了一下AVS3169的VSYNC信号与PNX1700的连接方式，发现在用CVBS输出时，PNX1700上与AVS3169的VSYNC信号相连的引脚是输出QVCP_VSYNC信号，检查VO输出模式设置没有问题，再查QVCP的设置，看哪个寄存器能控制QVCP_SYNC信号，发现在QVCP_CONTROL(0x10e020)寄存器中有对HSYNC和VSYNC的控制，用命令在线修改了直接相关的该寄存器中4个位的值，但没有任何效果，再在整个PNX1700芯片手册中查找关键字VSYNC，发现在398页有对QVCP VSYNC设置要求的描述：该寄存器的bit1(Master)要求设成1，即从模式，而我们现在是设成0，即主模式，我把该位改成1后屏幕出现黑屏，没有任何显示，再把这位恢复到0，竟然出现了颜色，屡试不爽，仔细研究这个寄存器的bit1和bit0分别是控制屏幕时钟发生器（STG）工作模式（主/ 从）和STG的复位，分析觉得在系统上电后对QVCP初始化之前先把QVCP的STG置成从模式并且复位STG，然后再用原有的初始化程序，这样应该可以解决视频信号的时钟和数据不同步问题，所以在主程序中初始化QVCP之前加入MMIO(0x10e020) = 0x20050006行，测试果然不再出现上述问题，问题解决；并顺势延伸一下，以前用SAA7105做CVBS输出时偶尔也会出现屏幕顶部显示不正常问题应该与这个问题一样，所以用上述相同的方法修改程序后对SAA7105 CVBS输出进行强化测试（每8秒钟重新启动一次，强化测试3天），结果没有再出现显示不正常现象；--中嵌学院--
例6：同样是PNX1700音视频开发平台上遇到的问题，VGA输出时OSD菜单会抖动，最先想到的方法是把OSD的scaler改用QVCP来做而不是MBS来做，这样在1500上会减轻 OSD抖动现象，几乎不出，但在1700上测试效果还是很不好，抖动仍然很厉害，后来安排同事将1500种DDR时钟的工作频率从166MHz提高到 200MHz，并告诉他需要改哪个模块的哪几个寄存器，这时正好是用VGA做视频输出（一般情况是用CVBS做视频输出，但因为此时正在跟踪VGA中 OSD抖动问题，所以用了VGA输出模式）来调DDR工作频率的，在同事修改DDR寄存器过程中我却发现OSD怎么不抖了，仔细研究同时修改过的寄存器相关位的定义，发现在DDR模块中有两个寄存器与DDR仲裁相关，一个是ARB_HRT_WINDOW（0x65184，DDR仲裁硬件实时窗口），另一个是ARB_CPU_WINDOW（0x65188，DDR仲裁CPU窗口），将这两个寄存器分别设置成ARB_HRT_WINDOW = 0xffff及ARB_CPU_WINDOW = 0x0就不会出现OSD抖动，因为在这种设置情况下DDR对DMA的占有权高于CPU对DDR的拥有权，DDR可以抢断CPU，原来的设置使CPU可以抢断DDR占有DMA。其实在发现问题VGA中的OSD抖动问题之初我也找过与memory相关的寄存器设置，因为根据以前经验和习惯思维，DDR配置寄存器只是负责DDR部分，而memory与CPU之间关系的寄存器应该在系统寄存器中，所以没有去查找DDR配置寄存器，可是在这一例子中却偏偏在DDR配置寄存器中。--中嵌学院-- 从上述几个例子中我们可以总结归纳以下几点调试方法和注意事项：
1）加深理解法：加深理解包括加深对硬件和软件的理解，加深对硬件的理解主要是详细阅读相关的芯片数据手册，而加深对软件的理解是因为现在开发嵌入式系统并不是所有程序都需要自己编写，很多都是已经做好的，直接从网上获取或者采购获得，但这些软件不一定是完全针对我们自己的目标板的，所以在使用过程中经常会发现一些问题，特别是底层软件，而一旦出现问题，开发人员首先必须了解出现问题的代码。只有建立在对相关硬件和软件深入理解的基础上才可能做出更符合实际的判断，才可能更好地解决问题。
2）比较法：比较的方法有很多，比如将同样的软件放在两个类似但不相同的硬件平台上运行比较现象；将两个不同版本的软件放在同一个硬件平台上运行比较现象；将相同的软件放到相同批次但不同的两个硬件平台上运行比较现象。对于一些不是很隐蔽的问题通过比较法通常能得到不错的效果。
3）分解法：当碰到分析起来比较复杂、可能有很多因素的问题时，可以把问题分成解几个小问题来测试诊断，比如编写几个单独的小测试程序对各种可能因素进行排查测试，根据这些测试结果再进行科学判断。
4）软硬件结合法：这种方法是需要一定灵感和悟性的。比如上面的例5，在测试过程中，可以在不破坏硬件的前提下临时改变一下硬件的状态（比如该例中将数据线和时钟线短路），看问题现象会不会有所变化，如果有，那么多做类似试验找出变化规律和关键因素，然后再进行分析解决。在底层软件开发中，对于时序要求严格的硬件模块的软件编程要特别注意，一旦程序的时序出了问题，而这部分软件已经与其他系统软件融合到一起，那么这种软件让别人去检查是很难查出问题的。
5）诊断、排故要建立在大量实验的基础之上，要多动手，不能光知道臆想，不愿实际 *** 作，还美其名曰“善于思考和分析”。嵌入式系统开发是一门实践性很强的科学，需要在实践中总结出事物客观规律，从而更好地认识和利用它们，让它们更好地按我们的意图工作。
6）嵌入式系统开发调试要求开发人员有严谨细致的工作态度，决不放过调试过程中发现的任何一点蛛丝马迹，因为它很可能就是打开潘多拉宝盒的钥匙。
7）要有实事求是的工作作风，要有敢于怀疑一切的精神和勇气，我们理当尊重权威和前人的科技成果，但当出现矛盾时我们更应该相信实验结果，这样科学才会进步。
8）要勇于挑战自我，抛开习惯性思维和成见，拓宽思路，多角度分析问题。
9）嵌入式系统开发特别是底层软件和 *** 作系统内核开发因为需要同时跟软件和硬件打交道，所以是一件比较艰苦的工作，很有挑战性。即使我们各方面都做得非常好，考虑得非常细致周全，目标系统仍然可能跟我们开一些小小的玩笑，我们经常会碰到一个非常小的问题困扰我们几天甚至几周的时间，这期间我们可能茶饭不思、夜不能寐，因此嵌入式系统底层软件开发人员不但要有平和的心态，且具备一定的耐心和毅力，还要有勇于克服一切困难的勇气和信心！只要我们做得足够好，那么可能解决一个具体疑难的过程带有一定偶然性，但我们终将排除所有阻碍！ --中嵌学院--
所以说，嵌入式系统调试过程就是一个更加深入了解我们的目标系统以及系统中的每个单元模块特性的过程，就是一个锻炼我们的逻辑思维和分析推理能力的过程，就是一个开拓思路、向习惯思维和权威挑战的过程，就是一个培养严谨细致的工作态度和实事求是工作作风的过程，就是一个锻炼我们耐力和毅力的过程，最终是一个学习进步的过程！
嵌入式系统调试诊断能力的提升是一个长期实践、积累、提高的过程！
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）