嵌入式应用软件开发流程.ppt

  1. 1、本文档共12页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
嵌入式应用软件开发流程

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

文档评论(0)

shuwkb + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档