1、嵌入式应用软件开发流程目录 确定需求 确定方案 程序编码 代码调试 交叉编译 联调测试 打包程序 现场试用 稳定性测试确定需求 硬件资源：首先应确定目标板的硬件资源，包括各种器件和设备，这对内核编译和驱动的开发至关重要。软件资源：然后应确定我们能使用的有哪些软件资源，如工具链、IDE和第三方库等。功能需求：用户都需要哪些功能，在现有的硬件和软件资源情况下能否实现。界面需求：用户有没有界面需要，是彩色液晶还是单色液晶，操作键盘有多少个键，各个键的功能等。性能需求：稳定性、响应速度、运行速度、容错性等性能需求。接口需求：对外有多少个硬件接口和软件接口，都有哪些要求。其它需求：如工期、交付物形态等。
2、确定方案 开发工具：我们将使用哪种或哪几种语言进行编程，编程时会用到哪些工具等。开发方法：我们将采用哪种思想或哪种模式进行开发，开发过程需要哪些资源等。程序架构：程序的哪些内容可以做成平台，哪些内容应当实现成接口，哪些内容可以抽象等。程序详细方案：程序功能时序顺序、详细类结构和数据库结构等。程序编码 程序编码其实通俗易懂，就是将详细设计方案实现成代码的过程。但我们仍然应当注意以下几点：切记只使用标准C/C+的库，因为太多的第三方库会让你的程序变得臃肿，这违背了嵌入式的宗旨。面向对象在嵌入式Linux开发中可用，但不是到处都非用不可，有些地方不用反而更好。时刻牢记嵌入式软件的可扩展、可裁剪特性。
3、时刻牢记软件的异常处理，如可能发生的指针错误等，但你不可以抛异常，而应该记录异常。你应当熟悉甚至精通STL和系统的API函数库，并将其用到你的实际工作中，否则你的工作将会事倍功半。代码调试 代码编写完成后，我们应当进行调试，而且是100%覆盖率的逐行调试。由于我们只使用标准C/C+进行代码编写，所以我们一般会在开发主机中先对代码进行调试，来排查和编译器无关的问题。使用Eclipse等IDE，会让代码调试更加轻松，这比直接使用GDB进行调试要友好得多。原则：不放过一个警告，因为警告是潜在的错误。交叉编译 首先编写交叉编译脚本Makefile，定义CPU架构、代码目录和编译选项。执行make，编译
4、程序。排除出现错误，不放过一个警告。因为，警告是隐含的错误，也许将来警告就会变成错误。联调测试 这一步又叫集成测试，有两种集成：内部集成和系统集成。内部集成：多进程、多线程之间的联动测试，系统模块之间的联调测试。系统集成：和其它子系统的联调测试，比如自动路测仪应当和近端调试软件、远端控制软件进行联调测试，保证软件功能和其它子系统没有歧义。打包程序 准备需要打包的资源，如主程序、动态库、配置文件、脚本和第三方库等。编写打包脚本（开发主机）。编写安装脚本（开发主机）。测试打包脚本（开发主机）。测试安装脚本（目标板）。打包并发布程序和安装脚本。有些场合你可能还需要编写一个专用于刷写用户程序的PC程序
5、。现场试用 原因及其重要性：前面的过程基本上都是研发人员闭门造车的结果，能否满足用户需求，适应现场情况，还不确定。嵌入式设备一般都要求无故障运行很长一段时间，或者出现故障能够自动恢复，而且现场试用能够发现我们在实验室发现不了的问题。方法：假如现场已有工程点，则挑选一定数量的工程点进行试用。假如没有工程点，则应模拟实际现场情况进行测试。稳定性测试 稳定性测试是研发人员在进入维护阶段后应该认真执行的事，目的是发现一些细微的问题，或者是测试人员没有发现的问题，并确定程序能否满足长期运行的要求。嵌入式软件的稳定性要求非常之高，想象一下，假如程序不稳定，那么我们的技服人员可能需要每天疲于奔命的去追着公交车跑维护，那会是我们花不起的成本。结语 嵌入式软件的稳定性重于一切，从挑选工具和第三方库的时候，就应该考虑这一点。请研发人员重视测试！面向对象是好东西，用好，用恰当了是关键。考虑到代码大小和远程升级，用C可能是更好的选择。实现复杂度和代码体积总是成反比的。如果有远程通信，那么请一定为你的嵌入式软件设计远程升级和远程维护的手段，这是后期维护至关重要的功能。哪怕用户并不要求你远程升级，有些时候，一个小后门能够省却你跑到日晒雨淋的现场去调试程序。
