嵌入式软件的开发流程_嵌入式软件的调试

　　嵌入式软件的发展

　　第一阶段：早期的嵌入式系统设计方法，通常是采用“硬件优先”原则。即在只粗略估计软件任务需求的情况下，首先进行硬件设计与实现。然后，在此硬件平台之上，再进行软件设计。因而很难达到充分利用硬件软件资源，取得最佳性能的效果。同时，一旦在测试时发现问题，需要对设计进行修改时，整个设计流程将重新进行，对成本和设计周期的影响很大。这种传统的设计方法只能改善硬件/软件各自的性能，在有限的设计空间不可能对系统做出较好的性能综合优化，在很大程度上依赖于设计者的经验和反复实验。

　　第二阶段：90年代以来随着电子系统功能的日益强大和微型化，系统设计所涉及的问题越来越多，难度也越来越大。同时硬件和软件也不再是截然分开的两个概念，而是紧密结合、相互影响的。因而出现了软硬件协同（codesign）设计方法，即使用统一的方法和工具对软硬件，协同设计软硬件体系结构，以最大限度地挖掘系统软硬件能力，避免由于独立设计软硬件体系结构而带来的种种弊病，得到高性能低代价的优化设计方案。

　　嵌入式软件的开发流程

　　在嵌入式系统的开发过程中，一般采用的方法是现在通用PC机上编程；然后通过交叉编译和链接，将程序做成目标平台上课运行的二进制代码格式；最后将程序下载到目标平台上的特定位置，由目标板上启动代码运行这段二进制代码，从而运行起嵌入式系统。

　　嵌入式软件开发的基本流程：整个过程中的部分工作在主机上完成的，另一部分工作在目标板上完成。首先，是在主机上的编程工作。纯粹使用汇编代码编写源代码，除了编写困难外，调试和维护困难也是汇编代码的难题；而c语言可直接对硬件进行操作，而且又有高级语言程序结构化、容易移植等优点，因而嵌入式系统源代码主要是由汇编语言和c语言混合编写。源代码编写完成后容易保存为源文件，再用主机上建立的交叉编译环境生成.obj文件，并且将.obj文件按照目标板的要求链接成合适的.image文件。最后通过重定位机制和下载过程，将.image文件下载到目标板上运行。由于无法保证目标板一次就可以运行编译、链接成功的程序，因此后期的调试排错工作就特别重要。调试只能在运行态完成，因此在主机和目标板之间通过连接，由主机控制目标板上程序的运行，可达到调试内核或者嵌入式应用程序的目的。

　　作为从事了5年之久的嵌入式软件开发，以下职责是必须要掌握的，嵌入式软件工程师能根据项目管理和工程技术的实际要求，按照系统总体设计规格进行软、硬件实际，编写系统开发规格说明书等相应的文档;组织和指导嵌入式系统靠法实施人员实施硬件电路、编写和调试程序，并对嵌入式系统硬件设备和程序进行优化和集成测试，开发出符合系统总体设计要求的高质量嵌入式系统;具有工程师的实际工作能力和业务水平。

　　同时在这样一个技术日进千里的时代中，嵌入式软件开发工程师该干嘛，我给出大家列一个嵌入式软件开发流程，对你一定有所帮助。

　　1.学习那些让因特网实现的技术，建议嵌入式工程师学习因特网有关的技术，对职业生涯发展会有加分效果。

　　2.学习利用搜索引擎，不要闭门造车，要善用开放源码世界的信息，很多常见的设计问题其实透过因特网就能找到同领域菁英贡献的程序代码，与同领域的其他工程师们相互交流、互相帮助。

　　3.离开舒适圈，走出舒适圈，挑战自我、去学习原本不熟悉的东西，包括工程以外的知识。

　　4.熟悉实时操作系统，嵌入式工程师从一些较小型的系统着手，累积相关技术经验。

　　5.培养多元化技能与系统观，尝试着去开发手机应用程序、或者是学习后端服务器的相关技术，能让你开启完全不同的观点，去熟悉开放性硬件，现在市面上有不少现成的开发板，能让工程 师专注于学习独特算法的开发。

　　6.了解软件也要了解新的处理器，除了要深入了解C或C++等基本程序语言，有时也要认识一些热门的新程序语言以因应特殊设计需求，但更重要的是了解新的处理器技术;处理器才是嵌入式系统的本质。

　　7.要能熟悉开放源码软件，建议工程师避免只专长单一领域，因为那可能会阻碍你的成长。对 嵌入式工程师来说，确保自己对软硬件技术都很了解，是非常宝贵的价值。

　　8.建立系统级的工程思维，嵌入式工程师拥有系统导向的思维是很重要的，此外每个嵌入式工程师都应该具备优良的项目管理技巧，力求准时完成负责的项目。

　　9.要能明确表达自己的想法与意见透过文字或绘图，无论是哪一种工程师，都需要能有效表达自己的想法与意见。

　　10.学习无线连结技术，嵌入式工程师需要在接下来1—3年学习无线连结技术，特别是Wi-Fi与蓝牙低功耗;因为现在的嵌入式设备与使用者智能手机连结的主要方式。

　　嵌入式软件的调试

　　在嵌入式软件开发过程中，一般来说，花在测试和花在编码的时间比为3:1（实际上可能更多）。这个比例随着你的编程和测试水平的提高而不断下降，但不论怎样，软件测试对一般人来讲很重要。很多年前，一位开发人员为了对嵌入式有更深层次的理解，向Oracle询问了这样的一个问题：我怎么才能知道并懂得我的系统到底在干些什么呢？　Oracle面对这个问题有些吃惊，因为在当时没有人这么问过，而同时代的嵌入式开发人员问的最多的大都围绕“我怎么才能使程序跑的更快”、“什么编译器最好”等肤浅的问题。所以，面对这个不同寻常却异乎成熟的问题，Oracle感到欣喜并认真回复了他：你的问题很有深度很成熟，因为只有不断地去深入理解才有可能不断地提高水平。并且Oracle为了鼓励这位执着的程序员，把10条关于嵌入式软件开发测试的秘诀告诉了他：

　　1.懂得使用工具

　　2.尽早发现内存问题

　　3.深入理解代码优化

　　4.不要让自己大海捞针

　　5.重现并隔离问题

　　6.以退为进

　　7.确定测试的完整性

　　8.提高代码质量意味着节省时间

　　9.发现它，分析它，解决它

　　10.利用初学者的思维

　　这十条秘诀在业界广为流传，使很多人受益。本文围绕这十条秘诀展开论述。

　　1.懂得使用工具

　　通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导致灾难性的后果，即使是非安全性系统，由于大批量生产也会导致严重的经济损失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和验证。随着越来越多的领域使用软件和微处理器控制各种嵌入式设备，对门益复杂的嵌入式软件进行快速有效的测试愈加显得重要。

　　就象修车需要工具一样，好的程序员应该能够熟练运用各种软件工具。不同的工具，有不同的使用范围，有不同的功能。使用这些工具，你可以看到你的系统在干些什么，它又占用什么资源，它到底和哪些外界的东西打交道。让你郁闷好几天的问题可能通过某个工具就能轻松搞定，可惜你就是不知道。那么为什么那么多的人总是在折腾个半死之后才想到要用测试工具呢？原因很多，主要有两个。一个是害怕，另一个是惰性。害怕是因为加入测试用具或测试模块到代码需要技巧同时有可能引入新的错误，所以他们总喜欢寄希望于通过不断地修改重编译代码来消除bug，结果却无济于事。懒惰是因为他们习惯了使用printf之类的简单测试手段。下面来介绍一些嵌入式常用的测试工具。

　　2.尽早发现内存问题

　　内存问题危害很大，不容易排查，主要有三种类型：内存泄露、内存碎片和内存崩溃。对于内存问题态度必须要明确，那就是早发现早“治疗”。在软件设计中，内存泄露的“名气”最大，主要由于不断分配的内存无法及时地被释放，久而久之，系统的内存耗尽。即使细心的编程老手有时后也会遭遇内存泄露问题。有测试过内存泄露的朋友估计都有深刻地体验，那就是内存泄露问题一般隐藏很深，很难通过代码阅读来发现。有些内存泄露甚至可能出现在库当中。有可能这本身是库中的bug，也有可能是因为程序员没有正确理解它们的接口说明文档造成错用。

　　在很多时候，大多数的内存泄露问题无法探测，但可能表现为随机的故障。程序员们往往会把这种现象怪罪于硬件问题。如果用户对系统稳定性不是很高，那么重启系统问题也不大;但，如果用户对系统稳定很高，那么这种故障就有可能使用户对产品失去信心，同时也意味着你的项目是个失败的项目。由于内存泄露危害巨大，现在已经有许多工具来解决这个问题。这些工具通过查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存泄露的问题。每个工具都有利有弊，不过总的来说，用要比不用好。总之，负责的开发人员应该去测试内存泄露的问题，做到防患于未然。

　　内存碎片比内存泄露隐藏还要深。随着内存的不断分配并释放，大块内存不断分解为小块内存，从而形成碎片，久而久之，当需要申请大块内存是，有可能就会失败。如果系统内存够大，那么坚持的时间会长一些，但最终还是逃不出分配失败的厄运。在使用动态分配的系统中，内存碎片经常发生。目前，解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现谁是导致内存碎片的罪魁祸首，然后改进相应的部分。

　　由于动态内存管理的种种问题，在嵌入式应用中，很多公司干脆就禁用malloc/free的以绝后患。

　　内存崩溃是内存使用最严重的结果，主要原因有数组访问越界、写已经释放的内存、指针计算错误、访问堆栈地址越界等等。这种内存崩溃造成系统故障是随机的，而且很难查找，目前提供用于排查的工具也很少。

　　总之，如果要使用内存管理单元的话，必须要小心，并严格遵守它们的使用规则，比如谁分配谁释放。

　　3.深入理解代码优化

　　讲到系统稳定性，人们更多地会想到实时性和速度，因为代码效率对嵌入式系统来说太重要了。知道怎么优化代码是每个嵌入式软件开发人员必须具备的技能。就象女孩子减肥一样，起码知道她哪个地方最需要减，才能去购买减肥药或器材来减掉它。可见，代码优化的前提是找到真正需要优化的地方，然后对症下药，优化相应部分的代码。前面提到的profile（性能分析工具，一些功能齐全IDE都提供这种内置的工具）能够记录各种情况比如各个任务的CPU占用率、各个任务的优先级是否分配妥当、某个数据被拷贝了多少次、访问磁盘多少次、是否调用了网络收发的程序、测试代码是否已经关闭等等。

　　但是，profile工具在分析实时系统性能方面还是有不够的地方。一方面，人们使用profile工具往往是在系统出现问题即CPU耗尽之后，而profile工具本身对CPU占用较大，所以profile对这种情况很可能不起作用。根据Heisenberg效应，任何测试手段或多或少都会改变系统运行，这个对profiler同样适用！

　　总之，提高运行效率的前提是你必须要知道CPU到底干了些什么干的怎么样。

　　4.不要让自己大海捞针

　　大海捞针只是对调试的一种生动比喻。

　　经常听到组里有人对自己正在调试的代码说shit！可以理解，因为代码不是他写的，他有足够的理由去shit bug百出的代码，只要他自己不要写出这种代码，否则有一天同组的其它人可能同样会shit他写的代码。为何会有大海捞针呢？肯定是有人把针掉到海里咯;那针为何会掉在海里呢？肯定是有人不小心或草率呗。所以当你在抱怨针那么难找的时候，你是否想过是你自己草率地丢掉的。同样，当你调试个半死的时候，你是否想过你要好好反省一下当初为了寻求捷径可能没有严格地遵守好的编码设计规范、没有检测一些假设条件或算法的正确性、没有将一些可能存在问题的代码打上记号呢？关于如何写高质量请参考林锐的《高质量c++/c编程指南》或《关于C的0x8本“经书”》。

　　如果你确实已经把针掉在海里是，为了防止在找到之前刺到自己，你必须要做一些防范工作，比如戴上安全手套。同样，为了尽能地暴露和捕捉问题根源，我们可以设计比较全面的错误跟踪代码。怎么来做呢？尽可能对每个函数调用失败作出处理，尽可能检测每个参数输入输出的有效性包括指针以及检测是否过多或过少地调用某个过程。错误跟踪能够让你知道你大概把针掉在哪个位置。

　　5.重现并隔离问题

　　如果你不是把针掉在大海了，而是掉在草堆里，那要好办写。因为至少我们可以把草堆分成很多块，一块一块的找。对于模块独立的大型项目，使用隔离方法往往是对付那些隐藏极深bug的最后方法。如果问题的出现是间歇性的，我们有必要设法去重现它并记录使其重现的整个过程以备在下一次可以利用这些条件去重现问题。如果你确信可以使用记录的那些条件去重现问题，那么我们就可以着手去隔离问题。怎么隔离呢？我们可以用#ifdef把一些可能和问题无关的代码关闭，把系统最小化到仍能够重现问题的地步。如果还是无法定位问题所在，那么有必要打开“工具箱”了。可以试着用ICE或数据监视器去查看某个可疑变量的变化;可以使用跟踪工具获得函数调用的情况包括参数的传递;检查内存是否崩溃以及堆栈溢出的问题。

　　6.以退为进

　　猎人为了不使自己在森林里迷路，他常常会在树木上流下一些标记，以备自己将来有一天迷路时可以根据这些标记找到出路。对过去代码的修改进行跟踪记录对将来出现问题之后的调试很有帮助。假如有一天，你最近一次修改的程序跑了很久之后忽然死掉了，那么你这时的第一反映就是我到底改动了些什么呢，因为上次修改之前是好的。那么如何检测这次相对于上次的修改呢？没错，代码控制系统SCS或称版本控制系统VCS（Concurrent Version Control，CVS是VCS的演化版本）。将上个版本check in下来后和当前测试版本比较。比较的工具可以是SCS/VCS/CVS自带的diff工具或其它功能更强的比较工具，比如BeyondCompare和ExamDiff。通过比较，记录所有改动的代码，分析所有可能导致问题的可疑代码。

　　7.确定测试的完整性

　　你怎么知道你的测试有多全面呢？覆盖测试（coverage testing）可以回答这个问题。覆盖测试工具可以告诉你CPU到底执行了那些代码。好的覆盖工具通常可以告诉你大概20%到40%代码没有问题，而其余的可能存在bug。覆盖工具有不同的测试级别，用户可以根据自己的需要选择某个级别。即使你很确信你的单元测试已经很全面并且没有dead code，覆盖工具还是可以为你指出一些潜在的问题，看下面的代码：

　　if （i 》= 0 && （almostAlwaysZero == 0 || （last = i）））

　　如果almostAlwaysZero为非0，那么last=i赋值语句就被跳过，这可能不是你所期望的。这种问题通过覆盖工具的条件测试功能可以轻松的被发现。

　　总之，覆盖测试对于提高代码质量很有帮助。

　　8.提高代码质量意味着节省时间

　　有研究表明软件开发的时间超过80%被用在下面几个方面：

　　调试自己的代码（单元测试）

　　调试自己和其他相关的代码（模块间测试）

　　调试整个系统（系统测试）

　　更糟糕的是你可能需要花费10-200倍的时间来找一个bug，而这个bug在开始的时候可能很容易就能找到。一个小bug可能让你付出巨大的代价，即使这个bug对整个系统的性能没有太大的影响，但很可能会影响让那些你可以看得到的部分。所以我们必须要养成良好的编码和测试手段以求更高的代码质量，以便缩短调试的代码。

　　9.发现它，分析它，解决它

　　这世界没有万能的膏药。profile再强大也有力不从心的时候;内存监视器再好，也有无法发现的时候;覆盖工具再好用，也有不能覆盖的地方。一些隐藏很深的问题即使用尽所有工具也有可能无法查到其根源，这时我们能做的就是通过这些问题所表现出来的外在现象或一些数据输出来发现其中的规律或异常。一旦发现任何异常，一定要深入地理解并回溯其根源，直到解决为止。

　　10.利用初学者的思维

　　有人这样说过：“有些事情在初学者的脑子里可能有各种各样的情况，可在专家的头脑里可能就很单一”。有时候，有些简单的问题会被想的很复杂，有些简单的系统别设计的很复杂，就是由于你的“专家思维”。当你被问题难住时，关掉电脑，出去走走，把你的问题和你的朋友甚至你的小狗说说，或许他们可以给你意想不到的启发。

　　总结：嵌入式调试也是一门艺术。就想其它的艺术一样，如果你想取得成功，你必须具备智慧、经验并懂得使用工具。只要我们能够很好地领悟Oracle这十条秘诀，我相信我们在嵌入式测试方面就能够取得成功。