嵌入式软件开发流程.docx
- 文档编号:6973551
- 上传时间:2023-01-13
- 格式:DOCX
- 页数:54
- 大小:143.15KB
嵌入式软件开发流程.docx
《嵌入式软件开发流程.docx》由会员分享,可在线阅读,更多相关《嵌入式软件开发流程.docx(54页珍藏版)》请在冰豆网上搜索。
嵌入式软件开发流程
嵌入式软件开发流程
一、嵌入式软件开发流程
1.1 嵌入式系统开发概述
由嵌入式系统本身的特性所影响,嵌入式系统开发与通用系统的开发有很大的区别。
嵌入式系统的开发主要分为系统总体开发、嵌入式硬件开发和嵌入式软件开发3大部分,其总体流程图如图1.1所示。
图1.1 嵌入式系统开发流程图
在系统总体开发中,由于嵌入式系统与硬件依赖非常紧密,往往某些需求只能通过特定的硬件才能实现,因此需要进行处理器选型,以更好地满足产品的需求。
另外,对于有些硬件和软件都可以实现的功能,就需要在成本和性能上做出抉择。
往往通过硬件实现会增加产品的成品,但能大大提高产品的性能和可靠性。
再次,开发环境的选择对于嵌入式系统的开发也有很大的影响。
这里的开发环境包括嵌入式操作系统的选择以及开发工具的选择等。
本书在4.1.5节对各种不同的嵌入式操作系统进行了比较,读者可以以此为依据进行相关的选择。
比如,对开发成本和进度限制较大的产品可以选择嵌入式Linux,对实时性要求非常高的产品可以选择Vxworks等。
由于本书主要讨论嵌入式软件的应用开发,因此对硬件开发不做详细讲解,而主要讨论嵌入式软件开发的流程。
1.2 嵌入式软件开发概述
嵌入式软件开发总体流程为图4.15中“软件设计实现”部分所示,它同通用计算机软件开发一样,分为需求分析、软件概要设计、软件详细设计、软件实现和软件测试。
其中嵌入式软件需求分析与硬件的需求分析合二为一,故没有分开画出。
由于在嵌入式软件开发的工具非常多,为了更好地帮助读者选择开发工具,下面首先对嵌入式软件开发过程中所使用的工具做一简单归纳。
嵌入式软件的开发工具根据不同的开发过程而划分,比如在需求分析阶段,可以选择IBM的RationalRose等软件,而在程序开发阶段可以采用CodeWarrior(下面要介绍的ADS的一个工具)等,在调试阶段所用的Multi-ICE等。
同时,不同的嵌入式操作系统往往会有配套的开发工具,比如Vxworks有集成开发环境Tornado,WindowsCE的集成开发环境WindowsCEPlatform等。
此外,不同的处理器可能还有对应的开发工具,比如ARM的常用集成开发工具ADS、IAR和RealView等。
在这里,大多数软件都有比较高的使用费用,但也可以大大加快产品的开发进度,用户可以根据需求自行选择。
图4.16是嵌入式开发的不同阶段的常用软件。
图1.2 嵌入式开发不同阶段的常用软件
嵌入式系统的软件开发与通常软件开发的区别主要在于软件实现部分,其中又可以分为编译和调试两部分,下面分别对这两部分进行讲解。
1.交叉编译
嵌入式软件开发所采用的编译为交叉编译。
所谓交叉编译就是在一个平台上生成可以在另一个平台上执行的代码。
在第3章中已经提到,编译的最主要的工作就在将程序转化成运行该程序的CPU所能识别的机器代码,由于不同的体系结构有不同的指令系统。
因此,不同的CPU需要有相应的编译器,而交叉编译就如同翻译一样,把相同的程序代码翻译成不同CPU的对应可执行二进制文件。
要注意的是,编译器本身也是程序,也要在与之对应的某一个CPU平台上运行。
嵌入式系统交叉编译环境如图4.17所示。
图4.17 交叉编译环境
小知识 与交叉编译相对应,平时常用的编译称为本地编译。
这里一般将进行交叉编译的主机称为宿主机,也就是普通的通用PC,而将程序实际的运行环境称为目标机,也就是嵌入式系统环境。
由于一般通用计算机拥有非常丰富的系统资源、使用方便的集成开发环境和调试工具等,而嵌入式系统的系统资源非常紧缺,无法在其上运行相关的编译工具,因此,嵌入式系统的开发需要借助宿主机(通用计算机)来编译出目标机的可执行代码。
由于编译的过程包括编译、链接等几个阶段,因此,嵌入式的交叉编译也包括交叉编译、交叉链接等过程,通常ARM的交叉编译器为arm-elf-gcc、arm-linux-gcc等,交叉链接器为arm-elf-ld、arm-linux-ld等,交叉编译过程如图4.18所示。
图4.18 嵌入式交叉编译过程
2.交叉调试
嵌入式软件经过编译和链接后即进入调试阶段,调试是软件开发过程中必不可少的一个环节,嵌入式软件开发过程中的交叉调试与通用软件开发过程中的调试方式有很大的差别。
在常见软件开发中,调试器与被调试的程序往往运行在同一台计算机上,调试器是一个单独运行着的进程,它通过操作系统提供的调试接口来控制被调试的进程。
而在嵌入式软件开发中,调试时采用的是在宿主机和目标机之间进行的交叉调试,调试器仍然运行在宿主机的通用操作系统之上,但被调试的进程却是运行在基于特定硬件平台的嵌入式操作系统中,调试器和被调试进程通过串口或者网络进行通信,调试器可以控制、访问被调试进程,读取被调试进程的当前状态,并能够改变被调试进程的运行状态。
嵌入式系统的交叉调试有多种方法,主要可分为软件方式和硬件方式两种。
它们一般都具有如下一些典型特点。
∙ 调试器和被调试进程运行在不同的机器上,调试器运行在PC机(宿主机),而被调试的进程则运行在各种专业调试板上(目标板)。
∙ 调试器通过某种通信方式(串口、并口、网络、JTAG等)控制被调试进程。
∙ 在目标机上一般会具备某种形式的调试代理,它负责与调试器共同配合完成对目标机上运行着的进程的调试。
这种调试代理可能是某些支持调试功能的硬件设备,也可能是某些专门的调试软件(如gdbserver)。
∙ 目标机可能是某种形式的系统仿真器,通过在宿主机上运行目标机的仿真软件,整个调试过程可以在一台计算机上运行。
此时物理上虽然只有一台计算机,但逻辑上仍然存在着宿主机和目标机的区别。
下面分别就软件调试桩方式和硬件片上调试两种方式进行详细介绍。
(1)软件方式。
软件调试主要是通过插入调试桩的方式来进行的。
调试桩方式进行调试是通过目标操作系统和调试器内分别加入某些功能模块,二者互通信息来进行调试。
该方式的典型调试器有gdb调试器。
gdb的交叉调试器分为GdbServer和GdbClient,其中的GdbServer就作为调试桩在安装在目标板上,GdbClient就是驻于本地的gdb调试器。
它们的调试原理图如图4.19所示。
图4.19 gdb远程调试原理图
gdb调试的工作流程。
∙ 首先,建立调试器(本地gdb)与目标操作系统的通信连接,可通过串口、网卡、并口等多种方式。
∙ 然后,在目标机上开启GdbServer进程,并监听对应端口。
∙ 在宿主机上运行调试器gdb,这时,gdb就会自动寻找远端的通信进程,也就是GdbServer的所在进程。
∙ 在宿主机上的gdb通过GdbServer请求对目标机上的程序发出控制命令。
这时,GdbServer将请求转化为程序的地址空间或目标平台的某些寄存器的访问,这对于没有虚拟存储器的简单的嵌入式操作系统而言,是十分容易的。
∙ GdbServer把目标操作系统的所有异常处理转向通信模块,并告知宿主机上gdb当前有异常。
∙ 宿主机上的gdb向用户显示被调试程序产生了哪一类异常。
这样就完成了调试的整个过程。
这个方案的实质是用软件接管目标机的全部异常处理及部分中断处理,并在其中插入调试端口通信模块,与主机的调试器进行交互。
但是它只能在目标机系统初始化完毕、调试通信端口初始化完成后才能起作用,因此,一般只能用于调试运行于目标操作系统之上的应用程序,而不宜用来调试目标操作系统的内核代码及启动代码。
而且,它必须改变目标操作系统,因此,也就多了一个不用于正式发布的调试版。
(2)硬件调试。
相对于软件调试而言,使用硬件调试器可以获得更强大的调试功能和更优秀的调试性能。
硬件调试器的基本原理是通过仿真硬件的执行过程,让开发者在调试时可以随时了解到系统的当前执行情况。
目前嵌入式系统开发中最常用到的硬件调试器是ROMMonitor、ROMEmulator、In-CircuitEmulator和In-CircuitDebugger。
采用ROMMonitor方式进行交叉调试需要在宿主机上运行调试器,在宿主机上运行ROM监视器(ROMMonitor)和被调试程序,宿主机通过调试器与目标机上的ROM监视器遵循远程调试协议建立通信连接。
ROM监视器可以是一段运行在目标机ROM上的可执行程序,也可以是一个专门的硬件调试设备,它负责监控目标机上被调试程序的运行情况,能够与宿主机端的调试器一同完成对应用程序的调试。
在使用这种调试方式时,被调试程序首先通过ROM监视器下载到目标机,然后在ROM监视器的监控下完成调试。
优点:
ROM监视器功能强大,能够完成设置断点、单步执行、查看寄存器、修改内存空间等各项调试功能。
确定:
同软件调试一样,使用ROM监视器目标机和宿主机必须建立通信连接。
其原理图如图4.20所示。
图4.20 ROMMonitor调试方式
采用ROMEmulator方式进行交叉调试时需要使用ROM仿真器,并且它通常被插入到目标机上的ROM插槽中,专门用于仿真目标机上的ROM芯片。
在使用这种调试方式时,被调试程序首先下载到ROM仿真器中,因此等效于下载到目标机的ROM芯片上,然后在ROM仿真器中完成对目标程序的调试。
优点:
避免了每次修改程序后都必须重新烧写到目标机的ROM中。
缺点:
ROM仿真器本身比较昂贵,功能相对来讲又比较单一,只适应于某些特定场合。
其原理如图4.21所示。
图4.21 ROMEmulator调试方式
采用In-CircuitEmulator(ICE)方式进行交叉调试时需要使用在线仿真器,它是目前最为有效的嵌入式系统的调试手段。
它是仿照目标机上的CPU而专门设计的硬件,可以完全仿真处理器芯片的行为。
仿真器与目标板可以通过仿真头连接,与宿主机可以通过串口、并口、网线或USB口等连接方式。
由于仿真器自成体系,所以调试时既可以连接目标板,也可以不连接目标板。
在线仿真器提供了非常丰富的调试功能。
在使用在线仿真器进行调试的过程中,可以按顺序单步执行,也可以倒退执行,还可以实时查看所有需要的数据,从而给调试过程带来了很多的便利。
嵌入式系统应用的一个显著特点是与现实世界中的硬件直接相关,并存在各种异变和事先未知的变化,从而给微处理器的指令执行带来各种不确定因素,这种不确定性在目前情况下只有通过在线仿真器才有可能发现。
优点:
功能强大,软硬件都可做到完全实时在线调试。
缺点:
价格昂贵。
其原理如图4.22所示。
图4.22 ICE调试方式
采用In-CircuitDebugger(ICD)方式进行交叉调试时需要使用在线调试器。
由于ICE的价格非常昂贵,并且每种CPU都需要一种与之对应的ICE,使得开发成本非常高。
一个比较好的解决办法是让CPU直接在其内部实现调试功能,并通过在开发板上引出的调试端口发送调试命令和接收调试信息,完成调试过程。
如使用非常广泛的ARM处理器的JTAG端口技术就是由此而诞生的。
JTAG是1985年指定的检测PCB和IC芯片的一个标准。
1990年被修改成为IEEE的一个标准,即IEEE1149.1。
JTAG标准所采用的主要技术为边界扫描技术,它的基本思想就是在靠近芯片的输入输出管脚上增加一个移位寄存器单元。
因为这些移位寄存器单元都分布在芯片的边界上(周围),所以被称为边界扫描寄存器(Boundary-ScanRegisterCell)。
当芯片处于调试状态时候,这些边界扫描寄存器可以将芯片和外围的输入输出隔离开来。
通过这些边界扫描寄存器单元,可以实现对芯片输入输出信号的观察和控制。
对于芯片的输入管脚,可通过与之相连的边界扫描寄存器单元把信号(数据)加载到该管脚中去;对于芯片的输出管脚,可以通过与之相连的边界扫描寄存器单元“捕获”(CAPTURE)该管脚的输出信号。
这样,边界扫描寄存器提供了一个便捷的方式用于观测和控制所需要调试的芯片。
现在较为高档的微处理器都带有JTAG接口,包括ARM7、ARM9、StrongARM、DSP等,通过JTAG接口可以方便地对目标系统进行测试,同时,还可以实现Flash编程,这是非常受欢迎的。
优点:
连接简单,成本低。
缺点:
特性受制于芯片厂商。
其原理如图4.23所示。
图4.23 JTAG调试方式
开发流程框图:
阶段
流程图
文档
项目
立项
阶段
任命项目经理
成立项目团队小组
项目建议书
可行性分析
市场信息反馈
签发项目任务书
可行性分析报告
项目任务书
项目
总体
规划
产品定义
系统分析
各部需求分析
需求分析评审
确定里程碑
编制质量控制计划
编制项目计划书
风险控制计划
需求分析报告
需求分析评审报告
产品定义
产品技术规范
项目开发计划
风险控制计划
质量控制计划
系统分析文档
设计
阶段
系统分析评审
硬件设计流程
软件设计流程
结构设计及制作流程图
软件V1.0
PCBV1.0
T1
工艺设计流程
工艺说明
T1
评审,过程文件归档
产品技术总体设计方案(包括工艺)
系统分析评审报告
软件设计过程文档
硬件设计过程文档
结构设计过程文档
工艺设计过程文档
软件V1.0
PCBV1.0
T1设计文档
工艺说明
分单元测试报告
设
计
验
证
阶
段
T1
整机测试及评估
软硬件及工艺调整版本升级
FTA准备
修模
例试报告及分析
装机报告
少量装机
装机准备
装机报告
例试分析报告
整机测试评估报告
软件FTA版本
硬件FTA版本
T2
FTA
修模
软硬件及工艺调整版本升级
CTA材料下单
例试、整机测试及评估
试产准备
小批量试产
FTA
T2设计文档
试产报告
例试分析报告
整机测试评估报告
软件CTA版本
硬件CTA版本
T3
CTA
软硬件结构及工艺调整
版本升级
量产版本确定
例试、整机测试评估
试产准备
CTA准备
第二次试产
CTA
T3设计文档
试产报告
例试分析报告
整机测试评估报告
量产
准备
阶段
生产工艺准备
全套文件归档
手工下单
封样
全套DVT报告
工艺文件
量产
转移
量产转移
附录:
1、结构设计及制作流程图
2、软件设计流程图
3、硬件设计流程图
附录1.结构设计及制作流程图:
阶段
流程图
表单
3D模型修改
结构
制定结构设计进度计划表
可行
评估
3D模型可行性评估
3D模型评估报告
结构设计进度表
详细结构设计
结构
详细
设计
结构设计进展汇报
结构设计修改
结构设计内部评审
结构设计进度表
结构
设计
验证
评审
相关资料准备
结构设计外部评审
模具制作检讨
workingsample验证
制作workingsample
签订商务合同
开模
结构设计修改
结构设计内部评审记录
workingsample配色表
workingsample验收报告
结构BOM
结构设计外部评审记录
模具制作检讨记录表
模具制作申请表
模具备品清单
模具制作注意事项表
工装夹具制作清单
物料进度按排需求表
配色方案表
模具制作进度表
参考文件:
《工业设计流程》,《ID设计流程》
附录2.软件设计流程图:
阶段
流程图
表单
软件
需求
分析
软件开发计划和配置管理计划进度计划表
软件需求分析(包括技术风险评估)
软件测试计划
软件需求规格书
软件开发计划
软件开发风险控制计划
软件测试计划
软件
详细
设计
详细软件设计
内部设计评审
软件详细设计说明书
软件接口设计说明书
软件设计内部评审记录
软件
实现
测试
编码调试
编写测试用例
单元测试
软件集成/调试
评审后发布并归档
软件修订
软件系统测试
发布系统测试版本
单元源代码
单元调试报告
单元测试用例
单元测试分析报告
集成后的软件及源代码
软件集成调试报告
软件操作手册
系统测试软件
系统测试用软件文档
软件系统测试分析报告
发布版本
参考文件:
附录3.硬件设计流程图:
阶段
流程图
表单
硬件
需求
评估
硬件开发计划和配置管理计划进度计划表
硬件需求分析(包括技术风险评估)
硬件测试计划
硬件需求分析报告
硬件开发计划
硬件测试计划
硬件
详细
设计
详细硬件设计
LCD认证流程
关键器件采购
PCB毛坯图设计
内部设计评审
硬件详细设计说明书
硬件电路原理图
硬件BOM
硬件设计内部评审记录
硬件
实现
测试
软件
投板前审查
PCB布板流程
打样、试产
硬件调试
硬件内部评审
PCB贴片
整机测试
评审后发布并归档
硬件修改
PCB数据
器件规格书
硬件子系统软件
装配图
硬件单元测试分析报告
电装总结报告
硬件系统测试版本
硬件系统测试分析报告
硬件评审验证报告
发布版本
参考文件:
1、PCB布板流程图
2、LCD认证流程图
PCB布板流程图:
阶段
硬件
结构
其他各部
表单
布板
需求
设计
硬件电路原理图
PCB布板设计
结构尺寸要求
项目需求/产品定义
PCB
确认
投板前审查
PCBGERBER
PCB
投板
PCB投板
参考文件:
LCD认证流程图:
阶段
硬件
结构
其他各部
表单
样品
提供
样品需求
SPEC
LCD供应商数据收集和选择
供应商提供样品
尺寸
各部
确认
各部确认?
供应商供样
与供应商沟通
SPEC
各部提出修改要求
电性能SPEC
尺寸确认
软件确认
装机
是否通过?
否
是
封样
装机验证
参考文件:
软件开发规范
SoftwareDevelopmentSpecification
Version:
V1.0
Date:
2010-06-22
Preparedby
DocumentRevisionHistory文档修订记录
VERSION版本
DATE
日期
DESCRIPTION
内容说明
INDIVIDUAL
修订人
1.0
2010-06-22
初稿
1Introduction简介
一个成熟稳定的组织或者团队,能够减少风险,经常地成功地达成目标。
成功的含义是:
按时、预算内【即符合成本要求】、符合质量要求。
换言之,成熟稳定的团队,能够避免以下问题:
Ø组织方面出现问题
Ø对需求缺乏管理
Ø缺乏计划和控制
Ø估算错误
同时,还要在以下几个方面做得比较出色:
Ø人员调度与工作安排
Ø工作量估计
Ø预算管理
Ø责权分配与平衡
Ø执行与监控
Ø沟通
本文档是软件开发规范,力求使团队打下一个良好的基础,以便逐步成长为成熟稳定的团队。
团队需要一个逐步标准、规范的开发过程,在这个过程中,团队得到锻炼,成员能力得到提高,风险得到控制。
主要内容是:
Ø定义软件开发的流程;
Ø定义软件开发的文档格式;
Ø定义涉及的角色;
Ø定义涉及的信息;
Ø描述开发流程;
Purpose目标
本文档的目标是:
Ø统一软件开发团队的流程、文档;
Ø促进团队成员的沟通,减少误解;
Ø促使程序员书写易维护的代码;
Ø提高代码编写效率;
Ø使每个成员成为一个高效的程序员;
Scope范围
本文档,包含:
Ø项目管理的流程;
⏹项目策划
⏹项目追踪
⏹配置管理
⏹质量保证
⏹同行评审
Ø涉及文档;
⏹项目计划mpp
⏹需求规格说明书SRS
⏹Delphi估算
⏹项目状态报告
⏹配置库样式
⏹CheckList
⏹评审表
⏹变更申请表
Ø开发工具的规范;
⏹数据库设计工具
⏹功能设计工具
⏹IDE
⏹配置工具
Definitions,Acronyms,andAbbreviations.术语,缩略词
ØSPP项目策划SoftwareProjectPlanning
ØSPTO项目追踪SoftwareProjectTracking&Oversight
ØSCM配置管理SoftwareConfigurationManagement
ØSQA质量保证SoftwareQualityAssurance
ØPR同行评审PeerReview
ØBaseLine基线
ØSCCB软件配置控制委员会SoftwareConfigurationControlBoard
ØCR变更请求ChangeRequest
ØSDLC软件开发生命周期SoftwareDevelopmentLifeCycle
ØRUP统一开发过程RationalUnifiedProcess
ØXP极限【敏捷方法】eXtremeProgramming
ØTDD测试驱动TestDrivenDevelopment
References引用
《CMM2》
《CMM3》
Overview文档组织
本文档主要分为四大部分:
Ø概述;
描述了团队组织开发过程的高层视图;
ØTSP和PSP;
按照团队和个人描述流程规范;
Ø工具规范;
描述了开发工具的详细规范;
Ø文档;
涉及的文档格式;
2TheOverallDescription概述
本部分是开发团队开发过程的高层描述。
它描述了开发过程规范的背景,用来和所有涉及各方就基本过程达成共识。
SoftwareDevelopmentOrganizing开发团队组织结构
说明:
表示公司的行政部门表示公司的逻辑部门
实线表示参加产品实现的组织和人员(不表示所属关系)
虚线表示工作的汇报关系,如SQAE向SQA经理汇报。
ProjectBaseProcess项目基本流程
识别需求
提出解决方案
执行项目
结束项目
投入力量
可行性分析报告
需求建议书
合同
项目目标
项目定义制定计划计划实施项目终止
时间
基本流程说明:
Ø项目启动:
本阶段主要是进行可行性分析,定义
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 嵌入式 软件 开发 流程
![提示](https://static.bdocx.com/images/bang_tan.gif)