软硬件设计

Transcription

1 关于本书 这是一本工程师与工程师之间交流经验的书, 本书的作者是一位嵌入式系统工程师, 毕业以来, 一直从事嵌入式系统开发, 从未中断 本书中, 作者将和广大读者共享其多年积累的经验 当你捧起这本书, 笔者为此感到荣幸, 为有机会和你交流而兴奋, 在工程技术领域, 交流是提高的重要途径, 希望能从你获得有益的建议 本书有经验的总结, 也提出了一些自己的观点, 就像上帝不会造出两张一摸一样的脸一样, 也不可能有两个观点一摸一样的人, 笔者不强求你认同本书的所有观点, 但至少希望能拓展你的视野 如果你对本书涉及的问题有不同的看法, 设计可靠的产品和可移植的技术是本书的两大主题 怎样设计可靠的产品? 笔者多年的职业生涯中, 涉及研制的都是电力和电信行业相关的工业类产品, 这种产品的特点是可靠性要求高, 使用时效长 它不像消费类民用产品, 更新淘汰得很快, 在使用中, 即使出现故障, 也不会造成严重的损失, 顶多是看不成电视, 听不到音响而已, 维修时也可以随时关闭电源 开机拆解, 而且维修也是以更换部件为主, 而不会深入分析故障原因 而许多工业监控类产品需要长期不间断运行, 出现故障即有可能造成严重损失, 设计中要防止局部故障导致严重损失 这些产品的服务期很长, 动辄 5 年 8 年, 甚至超过 10 年也很常见 在这么长的运行期中, 生产厂家需要分析每一起故障, 分析可能存在的隐患, 不但要改进新产品, 还要升级正在服役的产品, 防止出现新的故障 更有甚者, 在维修过程中可能还不能关闭电源, 不能退出运行 从而使笔者能够长时间跟踪产品, 充分暴露 发现隐含的问题, 从中总结出宝贵的经验, 笔者最近一年的主要工作职责之一, 就是产品失效分析, 分析产品的每一起售前或者售后故障, 找出改进点 设计可移植的技术, 是本书的又一主题 由于工业现场条件复杂多变, 使得工业类嵌入式产品的衍生型号很多, 如何使产品能够适应不同的环境, 或者使技术在不同产品间具有最大的可移植性, 是一门艺术 有人说, 我的软件是用 C 语言写的, 是可移植的 这句话看起来很有道理, 实际上谬之大矣! 等于是说 : 我用钢笔写字, 我的书法具有可移植性 灵活的系统结构, 一致的模块接口, 清晰的软硬件脉络, 才是可移植的关键 也有人认为移植只是换个平台这么简单, 其实能满足不同平台只是可移植软件的最低要求, 可移植的软件最重要的是在当用户的需求发生变化时, 能够迅速调整, 重新组合, 满足用户的需求, 即使软件有较大的规模, 船大也要好掉头才行 要完成可靠性和可移植性目标, 不是某一个模块性能优越能达到的, 最优化设计的模块, 不一定能组装出一个整体性能优越的产品 ; 而整体性能优越的产品, 其局部模块可能很粗糙, 这是一个系统工程的 本书以笔者自己开发的 djyos 操作系统为范例讲述产品设计的系统性思想,djyos 是一个软件, 但本书并不是一本软件教科书,djyos 专门为软硬件综合进行系统架构优化提供了支持 计算机技术发展到现在, 已经有很多技术积累, 开发一个复杂的嵌入式产品, 要懂得 拿来主义, 不要完全从 0 开发全部软件和硬件 但是, 怎样拿来呢? 开发高可靠的产品, 对使用外来代码会非常谨慎, 甚至只使用有商业支持的外来代码 任何外来代码, 都要经过通读 仔细分析, 完全测试过以后才允许使用, 有商业支持的代码, 供应商会提供支持, 这个过程进行得就快些 ; 而没有商业支持的所谓开源代码, 这些代码甚至没有完整的注释, 读懂这样的代码, 所花费的时间甚至不会比自己开发少多少 所以, 高可靠产品的 拿来主义, 主要靠继承企业自身积累的软件模块, 来降低开发工作量 要使新产品开发时有东西可以拿来用, 企业产品开发过程只就要非常注重 可拿去性, 一句话, 不拿去, 何以拿来, 而可拿去性, 实质上就是可移植性!djyos 系统支持下, 在系统设计时强调 可拿来性, 即系 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 1 页共 409 页

2 统融合现成的软件模块的能力 ; 在模块设计方面, 强调 可拿去性, 即模块应该能适应不同的运行环境 djyos 系统融合现成模块的能力, 重点不在于支持并发运行, 而在于支持程序设计者组合现有模块成为一个新产品, 以及设计可组合模块的能力 可靠性和可移植性并不是孤立的指标, 他们是互相促进的 可移植性是可靠性的基石, 产品的可靠性来自于 3 个方面 : 1. 正确设计以减少缺陷 2. 充分测试以修正缺陷 3. 充分使用中暴露缺陷 开发工作是一个创新性很强的工作, 没有一个设计师敢声称自己设计的产品是没有缺陷的, 即使有人这样说, 也不会有人相信 同样, 没有一个测试师敢声称能找出所有 bug 反复使用是暴露 bug 的一个重要手段, 同时也是暴露设计缺陷的手段 只有可移植性强的模块, 才有机会在不同的产品 不同的使用环境中反复使用 拿来 一个可移植的 经过反复使用考验的模块, 显然是设计高可靠性产品的最好的保证 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 2 页共 409 页

3 目录 关于本书...1 目录...3 第 1 章 设计嵌入式产品 嵌入式系统的特点 模拟电路和数字系统紧密结合 内存受限 可靠性要求高 外设非标准 CPU 速度受限且非标准 硬件平台不固定 可确定的系统 软件平台变化很大 软件被固化 传统的设计方法 软硬件联合设计方法 系统方案设计阶段 软硬件分工设计阶段 反馈 - 软硬件分工调整阶段 联合设计会影响进度吗? 软硬件联合设计范例 需求 设计方案 产品功能升级 软硬件协同分析问题 软硬件相互转化 软硬件互存互容 软硬件协作提高可靠性 硬件措施 软件措施 可靠性分级设计 防错还是容错 确定关键模块 cehw 系数应用 电梯控制器设计 非 cehw 设计方案 cehw 设计方案 echw 系数应用 手机通话模块...41 第 2 章 认识内存 嵌入式系统的存储设备 存储器保护组件 :MPU 简介 存储器多重映射组件 :MMU 简介 栈...52 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 3 页共 409 页

4 2.5 堆 汇编语言程序中使用栈 全局变量局部化 在栈中定义局部变量 堆与栈的关系 单线程的堆和栈 多线程的堆和栈 该为系统配置多少内存 图解多线程环境栈溢出 测算线程需要多大的栈 内存分配 静态分配和动态分配 任意长度分配法 固定块分配法 块相联分配法 适时分配和释放堆内存 动态分配与内存枯竭 提高栈的复用率 windows 内存粉碎机 数据对齐...77 第 3 章 嵌入式实时操作系统基础 实时系统 实时系统的实时性指标 非实时操作系统多道程序设计 实时操作系统多道程序设计 在实时操作系统中运行多个应用程序 实时性 紧急性与可靠性 案例 : 降低速度, 提高实时性 友好组 软件界的 智子疑邻 游戏 友好组划分 友好组保护 友好组隔离的实现 虚拟机 超级虚拟机 进程虚拟机 线程虚拟机 第 4 章 djyos 崭新的操作系统 术语 djyos 系统的基本元素 事件 事件类型 mark 标记 线程 事件 事件类型与线程 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 4 页共 409 页

5 4.3 事件调度 调度的实质 分配 CPU 时间 不允许直接控制线程和进程 数据结构说明 事件类型控制块数据结构定义 登记事件类型 删除事件类型 事件控制块数据结构定义 空闲事件控制块队列 就绪事件队列 不能删除事件 线程虚拟机数据结构定义 创建线程虚拟机 删除线程虚拟机 虚拟机分配与暂存 永久性线程虚拟机资源 线程虚拟机操作函数 事件状态 就绪态 阻塞态 状态变化 事件优先级体系 事件切换 何时执行事件切换 事件到事件切换 异步信号 ISR 中执行事件切换 事件处理完成后切换到就绪事件 事件重复弹出 事件生命周期 弹出事件 事件开始处理 事件处理完成 允许和禁止调度 mark 型事件 事件与事件类型小结 线程的栈 时钟嘀嗒 运行模式 单映像模式 (si 模式 ) 动态加载单进程模式 (dlsp 模式 ) 多进程模式 (mp 模式 ) 系统启动 系统启动过程各模式公共部分 CPU 初始化 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 5 页共 409 页

6 预加载操作系统 初始化中断系统 调用安全钩子函数 加载操作系统 准静态内存分配初始化 操作系统内核初始化 内核组件初始化 系统启动过程 si 模式部分 操作系统外围组件初始化 加载应用程序 用户应用程序初始化 动态内存分配初始化 启动多线程管理 系统启动过程 dlsp 模式部分 初始化文件系统 安全钩子模块 操作系统外围组件初始化 动态内存分配初始化 加载可执行文件 从文件系统加载可执行文件 从固定地址获取可执行文件 从 DROM 中读取可执行文件 调试模式加载可执行文件 九九加一原则 第 5 章 同步 闹钟同步 事件同步 事件类型弹出同步 事件类型完成同步 异步信号同步 内存同步 锁同步 数据结构定义 锁模块初始化 创建和删除锁 请求和释放锁 使用锁保护资源 信号量和互斥量的区别 优先级继承 阻塞超时 第 6 章 中断 中断与硬件设备 硬件操作 中断只是异步事件 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 6 页共 409 页

7 6.2 中断的软件模型 实时中断与异步事件 异步事件的优先级模型 理想模型 : 优先级混合 djyos 模型 :ISR 引擎 中断控制数据结构 初始化 异步信号 实时中断 禁止和允许中断 建议的中断配置策略 ISR 函数 第 7 章 内存管理 准静态内存分配 块相联分配法 内存组织 块相联分配模块初始化 分配一块内存 释放一块内存 固定块分配法 固定块分配模块初始化 创建内存池 分配内存 释放内存 堆和内存池 内存同步 局部内存回收 djyos 内存管理的特点 第 8 章 资源管理 资源管理模型 宿主数据结构 使用资源链表 第 9 章 泛设备驱动 模块泛设备化 泛设备 driver 分类 设备分类原则 内核泛设备 driver 独立泛设备 driver 私有泛设备 driver 谈谈硬件驱动 实现泛设备驱动程序 辅助组件 环形缓冲区 线性缓冲区 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 7 页共 409 页

8 栈缓冲区 泛设备驱动程序数据结构 struct dev_handle 结构 struct pan_device 结构 struct dev_io 结构 内存池 初始化泛设备管理模块 建立和使用设备 创建新设备 打开设备 关闭设备 快速打开设备在实时系统中的应用 防止资源泄漏 设备的读 写 控制 内窥镜泛设备 第 10 章 看门狗 看门狗的硬件 看门狗的软件原理 看门狗设计的常见误区 为了喂狗而喂狗 过度喂狗 过分倚重看门狗 定时器中断喂狗的特例 djyos 系统的看门狗模块 看门狗模块初始化 看门狗服务执行流程 创建和删除看门狗 使用看门狗示例 第 11 章 组件化开发 ( 本章未完成 ) 可移植是软件的灵魂 组件化的困惑 耦合 时间耦合 CPU 运行速度耦合 临界资源耦合 内存耦合 全局变量耦合 功能性耦合 解释性耦合 编译器耦合 不要图一时之快 组件的接口与实现 组件化的好处 解放专业设计者 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 8 页共 409 页

9 升级维护, 得心应手 系统规划, 性能优越 划分模块的原则 一致性原则 可维护性原则 可移植性原则 功能独立实现原则 可靠性分级原则 实时性分级原则 djyos 为组件化开发提供的支持 第 12 章 文件系统 djyfs 与 ANSI C 文件 IO 的差异 约定规范 文件系统整体结构 文件系统设备和初始化文件系统 文件柜设备 格式化文件柜 文件资源 文件资源树 创建文件 打开文件 删除文件 ( 目录 ) 读 写文件 关闭文件 其他文件操作 数据结构访问权限 存储介质接口函数 format 格式化文件柜 write 写文件 read 读文件 flush 刷新文件 query_file_stocks 查文件库存 query_file_ cubage 查文件库容 set_file_size 设置文件长度 seek_file 设置文件指针 create_item 创建文件或目录 remove_item 删除文件或目录 open_item 打开文件或目录 close_item 关闭文件或目录 lookfor_item 查找文件或目录 rename_item 修改文件或目录的名字 check_folder 查询子项目数量 dfsmd 部分 第 13 章 flash 文件系统驱动程序 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 9 页共 409 页

10 13.1 芯片存储体布局 数据结构 DFFSD 初始化与挂载芯片 掉电恢复块 磨损平衡算法 数据结构设计 跳跃换区法 分配一块 对 djyfs 的接口函数 芯片驱动接口 nand flash 芯片范例 :2808U0B nor flash 芯片范例 :SST39VF 第 14 章 其他文件系统驱动程序 RAM 文件系统驱动程序 串口文件系统驱动程序 简易文件系统驱动程序 第 15 章 djyos 移植 ( 本章未完成 ) 可移植性的考虑 充分注释 平台无关 严格遵守 ANSI C 慎用汇编 便于应用程序迁移 需要移植的部分 CPU 初始化文件 配置文件 makefile 连接脚本文件 线程相关函数 创建线程虚拟机 复位线程虚拟机 复位老线程, 切入新线程 上下文切入 上下文切换 从异步信号 ISR 中返回时的上下文切换 中断系统 系统定时 CPU 的自留地 ARM7 版本 S3C44B0X ARM 的自留地 中断设计 线程栈结构设计 常量配置 线程相关函数 复位线程虚拟机 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 10 页共 409 页

11 重置老线程, 切换到新线程 直接切入上下文 上下文切换 从异步信号 ISR 返回时的线程切换 中断系统 cortex-m3 版本 DSP 版本 TMS320F 第 16 章 嵌入式 C 语言编程杂谈 对齐及数据长度 强制类型转换 慎用 union 适应运行环境 软件效率 定长数据类型 数据完整性 精简代码与阅读困难 用户习惯 空函数指针 BOOL 变量的第三值 第 17 章 api 参考手册 事件与事件类型 资源管理 泛设备管理 中断 内存分配 ( 从堆中分配 ) 内存分配 ( 从内存池中分配 ) 定时 锁 ( 信号量和互斥量 ) 看门狗 文件系统 附录一 编码规范 一 排版 二 注释 三 命名规则 四 代码约定 第 1 章设计嵌入式产品 本书讲述嵌入式产品的软硬件设计, 开讲之前, 我们先来认识一下什么是嵌入式系统的问题, 做到有的放矢 给嵌入式系统下定义是个困难的事, 不同的人对嵌入式系统有不同的理解, 有很多讲嵌入式系统的书, 对嵌入式系统的定义也各不相同, 没有统一的定义 因此, 本书不企求对嵌入式系统下一个统一的定义, 只是要交代一下本书所讨论的中心议题 嵌入式产品是以嵌入式系统为核心的电子产品, 本书讨论如何设计优秀的嵌入式系统并把它组成 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 11 页共 409 页

12 优越的产品 嵌入式系统是电子产品的一个功能模块, 图 1-1 所示是一个典型的嵌入式产品组成结构图, 它典型地包含以下模块, 计算机核心系统模块, 与通用计算机不同, 这是为专门用途设计的计算模块 硬件设计时, 也会根据用途采取专门的设计, 例如使用 DSP 处理大量数学运算需求 包含专用软件, 并且可以通过修改软件适应新的功能 人机界面模块, 这个模块也是为专门用途设计 输入和输出模块, 与通用计算机的 I/O 不同, 嵌入式系统的 I/O 没有确定的地址, 而且与具体硬件紧密相关, 还可能包括模拟量 I/O 有许多嵌入式系统还包含通信模块, 这些模块往往用来连接成一个专用现场网络, 像汽车上常用的 CAN 网一样 ; 也可能用来与 PC 机连接, 用于设定工作参数, 转移采集的数据等 图 1-1 典型的嵌入式产品 1.1 嵌入式系统的特点 模拟电路和数字系统紧密结合 很多人都知道, 传感器检测到的信号需要经过放大 滤波 A/D 转换后, 才能被数字系统处理 ;CPU 输出的控制信号, 也要经过与传感器检测相反的信号路径, 才能实现功能 如何设计模拟电路与数字系统的实现方法息息相关, 即使简单的模拟 RC 一阶低通滤波电路设计, 使用精密电阻和电容, 软件就不用进行复杂的补偿, 而使用普通电阻和电容, 降低了物料成本, 但可能导致需要用软件做复杂的补偿 两种方案对软件运算的需求差异, 甚至可以影响到 CPU 的选择, 这单纯从软件设计和硬件设计方面都是很难想象的 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 12 页共 409 页

13 1.1.2 内存受限 桌面系统中, 内存动辄几十几百 M, 而且可以把磁盘作为虚拟内存交换使用, 使程序员看起来拥有无限大的内存, 一般的嵌入式系统, 内存只有几十 K 至几 M, 一般没有磁盘, 即使有磁盘, 也几乎没有硬盘页面交换能力, 内存对系统的限制非常大 同时, 为了保证系统的实时性, 一般都没有内存碎片侦测和收集功能, 所有内存使用都要由设计者直接干涉, 一个由多人共同开发的系统, 如何使用有限的内存, 系统设计师应该在设计初期就做出决定, 避免程序员在编程过程中随意申请内存, 这样会导致混乱 可靠性要求高 PC 软件是允许死机的, 偶尔出点错, 用户也不会较真, 我们常戏称经常死机的软件为 盖茨标准 但嵌入式控制系统经常用于关键的工业控制系统中, 是不允许出错的, 任何软件的或者是硬件的错误都可能是致命的 一个从技术角度讲并不算很严重的错误, 如果发生在工业控制现场, 就有可能是一场灾难性的事故 而很多工程师经常对一些小错误不以为然, 比如当输出高电平时却输出了低电平, 工程师常常一句 笔误而已 便敷衍过去了, 但嵌入式工业控制系统中这种错误可能比系统崩溃更为严重 这样的 笔误, 如果出现在炼钢厂的高炉控制设备中, 可能会造成一个价值数百万的设备损毁 ; 如果出现在发电机保护设备中, 可能使价值数亿的发电机报废并造成大面积停电 ; 如果出现在生命维持设备中, 那可真是人命关天的大事 外设非标准 对于桌面系统, 无论是台式机还是笔记本电脑, 从早期的 XT 总线到后来的 ISA 总线到 PCI 总线,CPU 均用标准总线与外设相连 无论是串行口还是并行打印口还是 USB 总线, 最后都转换成这些标准总线供 CPU 访问 PC 开发商甚至还对外设进行事先归类, 不同种类的外设的接入地址和中断号都已经事先分配好, 比如并口的 I/O 地址必然是 0x278 或 0x378, 中断号必然是 IRQ5 或 IRQ7 外设供应商开发产品时, 也总是使产品与某一种总线兼容, 否则将无法接入计算机 或者说, 桌面系统可以拒绝不符合自己要求的硬件接入 桌面系统的软件工程师, 在开发硬件驱动程序或者硬件相关的产品时, 只要使用操作系统提供的标准函数操作总线就可以了, 剩下的就是按设定的格式解释数据 因此, 桌面系统的硬件接口环境, 对于嵌入式系统开发者来说, 简直就是天堂! 可怜的嵌入式开发工程师, 他们面对的 CPU 种类超过 1000 种, 操作系统也超过 1000 种 他们面前根本就没有总线的说法, 要说有, 也就是 CPU 的数据总线或者地址总线 嵌入式系统是用于解决某一个具体的问题而存在的, 其硬件都是针对专用系统定制的, 硬件的配置五花八门, 它无需具备太多的通用性, 自身浑然一体 只要你喜欢, 你可以随意把一个外设安排在任意一个端口上, 甚至可以用 IO 口线去操作内存, 事实上, 有些 MPU 根本就没有外部存储器接口总线, 当内部存储器不够时, 往往要设计专门的接口来扩充存储器, 比如 I2C 接口的存储器 同时, 软件需要处理各种硬件异常情况 如果软件处理不好, 硬件的变化会对软件产生很大的干扰, 使其升级维护极其痛苦 还有一个容易被产品开发阶段忽略的问题, 就是芯片停产改型带来的问题 工业及现场控制类的产品往往有较长的生命周期, 一个产品开发定型后, 连续销售 10 年甚至更长时 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 13 页共 409 页

14 间都是有可能的 芯片厂商总是会不断地更新产品, 停产老产品, 工业控制类产品的产量往往不高, 企业缺乏向芯片厂商叫板的筹码, 遇到停产只能自己修改产品 在漫长的生命周期中,CPU 以及外围器件都有可能遭遇停产 人们往往只在硬件选型时考虑持续供货问题, 而在软件开发中却缺乏考虑 当因器件供货问题局部修改设计时, 往往会碰到新旧版本软件兼容升级的问题, 不但增加了设计更新的工作量, 也给软件版本管理带来极大的压力 因此, 嵌入式产品设计中一个很重要的问题就是统一外设, 至少在一个企业范围内, 要限制硬件设计的随意性, 限制 cpu 种类, 统一安排硬件地址, 这样可以有效降解软件设计的复杂性, 提高软件模块在一个企业内部不同产品之间的可移植性, 要预估可能变化的硬件, 对其相关代码组件化, 当发生硬件配置变化时, 单独修改相应的组件就可以了 在产品升级时, 可以最大限度继承老版本的软件 CPU 速度受限且非标准 嵌入式系统空间狭小, 散热空间也小, 出于可靠性的考虑, 绝大多数没有散热风扇, 这直接限制了 CPU 运算速度的提高 所有的计算系统都一样, 不同的配置间速度差别很大, 但桌面计算机一般不应用于关键控制, 速度快慢差别并不是致命的, 顶多影响用户的等待时间 ; 而大部分嵌入式系统用于实时控制环境, 有些操作对定时要求相当严格, 过快或者过慢都不行 CPU 运行快慢有可能对系统造成致命影响, 编写软件时就应该考虑到运行速度的差别, 防止留下隐患, 优秀的软件, 可以自动地适应不同的 CPU 运行速度 虽然同一个产品在硬件平台一般是不变的, 但如果不注意系统速度差别的话, 可以轻松地保证你的软件是不可移植的 硬件平台不固定 嵌入式系统一般都是为专门用途设计, 同一个产品在其生命周期内硬件平台一般是不变的, 但是, 一个企业一般都有系列化的产品, 而且可能不止一个系列 同一个系列内的产品, 可能会有一个公共的 CPU 平台, 配以不同外设, 衍生不同的产品 ; 不同系列的产品, 则 CPU 平台也可能不一样 更不幸的是, 嵌入式系统工程师面对的还不仅仅是一个企业的产品, 就算相似的应用, 不同的公司使用的硬件配置也可能不一样, 外设配置甚至 CPU 都会发生改变 为了避免重复劳动, 特别是减少重复的 bug, 嵌入式软件的跨软硬件平台移植的要求很高 设计者应该考虑到, 当硬件和操作系统平台发生变化时, 尽可能重用软件代码 ; 当产品功能要求发生变化时, 尽量保持硬件和操作系统平台的稳定 软件和硬件重用的意义主要有两方面, 一方面可以缩短产品开发周期, 加快产品推出时间, 另一方面可以使产品越来越稳定, 我们知道, 软件是可能存在 bug 的, 使用时间越长, 则 bug 暴露得越充分, 只要发现 bug 时及时修改, 就能使 bug 越来越少, 产品的可靠性也越来越高 可确定的系统 计算机系统的可确定性包含两层意思, 一是时间可确定, 二是结果可确定 嵌入式系统的可确定性需求来自于两个方面, 一是嵌入式系统可能用于实时控制, 二是它是它可能用于无人值守或者无控制界面的环境 实时系统对时间要求非常高, 它要求计算机在限定的时间内完成计算任务并给出正确的 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 14 页共 409 页

15 输出 通用计算机系统往往要求尽量高效地使用计算机, 只要求计算机尽可能公平地干尽量多的活 嵌入式系统往往直接控制硬件, 很多硬件有严格的定时要求, 例如在自动剥线机控制中, 要求精确控制刀口动作的时间以保证剥线的长度 ; 在大米自动筛选机中, 传感器首先感知到有不良大米颗粒到达筛选口, 然后计算机通过采样和运算获知不良颗粒到达, 再命令机械装置剔除不良颗粒, 整个过程都要求快速而且精确定时, 检测的速度和准确度直接影响筛选效果和生产效率 因此, 许多嵌入式系统是时间关键系统, 要求在指定的时间内完成指定的操作, 而效率是否最高反而是次要的 在桌面系统中, 对应用程序的定时需求, 一般使用 尽量满足 的策略, 而在嵌入式系统中, 却要求 绝对满足 这些区别使这嵌入式系统和桌面系统的设计观念上有很大的区别, 他们的作业调度算法几乎完全不一样 靠自己, 别指望上帝! 无人值守环境或者无控制界面环境意味着, 如果计算机遇到异常情况下, 这些异常情况包括外部错误的输入 计算机自身软件和硬件 bug 导致的错误, 嵌入式系统应该自己做出决定, 而不是等待人工干预 在桌面系统中, 软件在遇到异常情况而不知道下一步该怎么做时, 往往弹出对话框, 让用户决定下一步该怎么做, 把包袱扔给用户, 而嵌入式系统却可能没有这种待遇, 它必须自己做出决定 嵌入式系统的异常情况有两类, 一类是可以预见但不可避免的, 比如, 硬件虚焊或者元器件损坏导致部分电路永久性失效, 或者通信数据包由于干扰或者对方计算机出错导致错误的数据, 这些都是可预见但不可避免的, 嵌入式软件需要有确定的策略处理 另一类是可以避免的异常, 比如内存不足, 在支持动态内存分配的环境中, 可能出现内存不足的情况, 嵌入式系统也不例外 在桌面系统中, 遇到内存不足时, 操作系统可以提示用户关闭一些应用程序, 或者关闭一些端口, 而嵌入式环境呢, 最好仔细计算好各计算任务的内存需求, 按最大可能配置内存, 或者在设计之初限制可能支持的通信端口数量 或者可打开的文件数量, 以限制内存需求量, 不要使关键任务在运行中得不到内存 软件平台变化很大 与桌面平台 windows 系统和 unix 系操作系统一统天下相比, 嵌入式系统的平台可谓是五花八门, 全世界嵌入式操作系统有好几百种, 流行较广的就不止 10 种, 还有许多系统根本就不用操作系统 与嵌入式硬件和软件平台相对应, 其开发平台也不一致, 不同的平台有不同的编译器, 这些编译器又大多根据特定平台有所扩展, 以产生在特定平台上最优化的目标代码 但一般而言, 我们尽量少使用编译器的特定扩展部分, 最好只使用 C89 标准兼容的代码, 在不得已使用特定扩展时, 应该给出详细的注释, 说明使用扩展功能的原因, 最好还能给出标准 C 语言的实现方法 C99 标准虽然已经出台多年, 但本书开始编写时, 笔者广泛搜索, 发现目前除 GNU C 涵盖了大部分 C99 标准特性以外, 没有一个嵌入式开发工具宣布实现了 C99 标准 如果哪位读者发现了支持 C99 的嵌入式编译器, 需请你慎重选用, 不要让你的软件变得不可移植 软件被固化 当然, 嵌入式程序员得到的也不全是令人沮丧的消息, 软件被固化在非易失存储器中的, 只能由软件设计者修改, 这就使嵌入式软件可以避开不怀好意者的搔扰 在桌面系统中, 令人愤怒的病毒, 令人讨厌的流氓软件 令人不快的垃圾邮件, 使我们防不胜防, 我们不得不安装各种防火墙, 各种操作系统补丁, 组成铜墙铁壁, 把操作系统绑得严严实实, 令计算机效率低下 即使如此, 尚不能保证操作系统和应用程序正确运行, 整天提心吊胆的生怕一不 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 15 页共 409 页

16 小心中毒 在嵌入式环境中, 一般不会执行外来程序, 程序员所有工作就是使应用程序本身正确运行, 而无需担心被外来程序破坏 1.2 传统的设计方法 很长时间以来, 软件和硬件分开设计被认为是天经地义的, 硬件工程师只负责硬件, 顶多再写一些驱动程序之类的简单代码, 他们不知道软件特别是系统软件是如何使用 CPU 和内存的, 他们遵循软件工程师的要求提供足够的内存和 CPU 运算速度, 剩下的事情就不关他们事了 ; 在他们看来, 软件工作就是趴在电脑前写代码, 把一堆 if-else 和 for( ) 堆在一起就可以了 软件工程师完全不懂硬件也被认为是理所当然的, 他们认为硬件设计就是选个 CPU, 再给它添加一些内存, 以及若干数量的外设, 然后给画个 PCB 就可以了, 谁都会做, 他们不知道计算系统是如何工作的, 也不知道如何编程才能使 CPU 系统发挥最大效用, 才能降低硬件的复杂程度, 从而降低成本 虽然有些企业会有一些嵌入式软件和硬件都熟悉的人才, 他们在设计硬件时, 就会考虑一些软件实现得问题, 也会根据软件实现来调整硬件设计, 但在传统设计方法下, 本质上还是软硬件独立设计 这种设计方法将硬件和软件分为两个独立的部分 产品外特性确定以后, 在整个设计过程中, 通常软件和硬件方案会独立设计, 具体实施则采用 硬件先行的原则 这种设计方法存在许多弊端: 软件工程师做软件方案时, 单纯使用软件方法, 脱离硬件平台思考软件算法的问题 他们甚少考虑软件方案如何适应广泛的硬件环境, 最终的结果也是软件在独特的硬件环境上调试通过, 导致的后果是, 硬件做任何细微的修改, 都可能导致软件大幅度的修改, 反之亦然 硬件工程师做硬件方案设计时, 会先向软件工程师征求意见, 诸如需要多少位的 CPU, 要多高主频, 多少内存等, 软件工程师则按照经验粗略估计硬件配置需求 硬件工程师获得配置需求后, 独立进行硬件方案设计, 方案设计过程中, 硬件工程师主要从硬件的角度考虑问题, 他们不熟悉软件方案, 而且此时软件方案往往也还没有完成, 他们甚少对软件方案提出建议 由于在硬件设计过程中缺乏对软件构架和实现机制的清晰了解, 从软件工程师处获得的需求也很模糊, 硬件设计工作带有一定的盲目性 软件工程师由于不熟悉硬件, 估计硬件需求时, 有经验的老工程师能给出一个比较准确的配置, 一些年轻工程师便只能根据流行方案再结合宁多勿缺的原则给个配置, 同样的功能, 给出的配置可能差别很大, 甚至会提出一些完全不切实际的要求 如果低估了系统配置要求, 在软件开发过程中会要求硬件工程师修改设计, 增加配置 ; 如果高估了配置要求, 冗余的硬件可能会增大体积, 增加功耗, 而且直接造成产品成本过高 无论硬件配置被高估还是低估, 都会造成反复修改 反复试验, 整个设计过程在很大程度上依赖于设计者的经验, 在反复修改过程中, 常常会在某些方面背离原始设计的要求 每一次硬件的修改都会付出大量的开发成本, 更重要的是, 每一次硬件修改都要经过原理图设计 PCB 设计,PCB 加工, 元器件备料, 板件焊接和调试这些工序, 导致硬件改版的周期很长, 这对项目进度的影响常常是致命的 由于开发进度的问题, 使许多硬件的优化不能实现, 反而要求软件削足适履去适应不太匹配的硬件 导致系统优化只能改善硬件软件各自的性能, 不可能对系统做出较好的综合优化, 得到的最终设计结果很难充分利用硬软件资源, 难以适应现代复杂的 大规模的系统设计任务 这种设计方法还不利于技术创新, 嵌入式技术每天都在发展, 新器件 新方案层出不穷 软硬件独立开发, 由于专业方向的限制, 硬件工程师可能不是太了解行 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 16 页共 409 页

17 业软件发展水平, 从而无法在硬件设计中予以支持, 而最新的软件技术往往需要某些硬件方面的支持 例如, 基于 RTOS 进行的软件设计, 如果硬件能提供信号量指令, 象 ARM 的 swp 指令, 会大大提高系统的性能 而软件工程师则可能不了解最新的硬件技术发展趋势, 在估计硬件需求时的依据也许是数年前的经验, 不能根据当前技术发展水平提出恰当的需求 做软件方案时也不能很好地利用硬件技术进步带来的好处, 使设计停留在落后的平台基础上 跟不上行业技术发展的节奏, 你的产品就会缺乏竞争力, 你所选用的器件可能很快停产, 不从软硬件结合的角度考虑, 你有可能会选择非主流的器件, 这些器件的生命周期可能很短 嵌入式产品尤其是工业控制类产品往往有很长的生命周期, 它要求厂家有持续供货和维护能力, 而元器件的正常供应是最基本的要求, 笔者所服务的公司就有一些 15 年前设计的产品, 现在仍然在供货, 现在生产的产品起码还要为用户维护 10 年, 加起来至少 25 年的生命周期 你可能不得不使用老旧的开发工具, 也可能得不到元器件厂家充分的技术支持, 生产商一般对新器件提供最为充分的技术支持, 而对老器件只提供最基本的支持 需求确定, 开始设计 软件方案设计 软件工程师建议 硬件方案设计 硬件原理图 PCB 设计 NO 软件工程师验收 测试 YES 硬件测试版输出 此过程可能多次反复 软件编码 调试 硬件板件输出 硬件符合需求吗? NO 提出修改意见 硬件调整设计 YES 软件输出 硬件输出 图 1-2 传统的 软硬件分开设计的流程传统的 软硬件独立进行的设计, 还易导致技术上 踢皮球 的现象 这里说的踢皮球, 不是要讨论工作中可能出现的敷衍应付 推诿塞责的情况, 这是企业管理的事, 不是本书的主题 我们在这里要讨论的是, 在所有开发者都认真负责的情况下, 如何从技术组织和人员 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 17 页共 409 页

18 分工角度上, 防止出现在职责定位上模棱两可的问题 这个问题, 在本书后续章节提到的 djyos 操作系统中, 也有考虑, 其组件独立化的设计思想和支持, 使问题局限在独立的组件内部, 避免模糊 我们在产品开发过程中, 经常碰到分不清是软件问题还是硬件问题的情况, 现在来看看笔者亲历的一个问题, 为了避免涉嫌泄露笔者曾经服务的公司技术秘密, 下面的描述是参照真实问题虚构的 有一个产品, 开发时做了 10 台样机, 该产品有通信功能, 但调试中发现其中 9 台通信正常,1 台通信偶尔会少发送一些数据, 该产品开发中, 软件工程师与硬件工程师是分开的, 项目经理也是软件出身, 所有软件工程师包括项目经理都断定是硬件有问题, 理由是相同的软件在其他机器上能正确, 肯定是不正确的这台样机的硬件有故障, 于是安排硬件工程师解决这个问题 硬件工程师用通信测试程序检测没有发现不正常的现象, 检查各信号从通信线直到 CPU 引脚都是正常的, 那些丢失的数据确实没有出现在 CPU 的输出端口上, 确实是软件没有把数据发出来 而软件工程师用仿真器调试有故障的机器时, 通信却又正常了 就这样, 软件工程师和硬件工程师都很努力, 都陷入苦闷之中, 无从下手, 他们怎么看都觉得问题与自己无关 时间在流逝, 项目进度却不能拖延, 硬件工程师实在没有办法的时候就开始啃软件代码, 通过仔细分析发现了其中的问题, 且看下面这段代码 : void func(void) if(status==true) }else } } 这段代码中, 如果 if(status==true) 条件成立, 就会认为通信已经完成, 不会再发送数据 status 是一个综合条件, 与 CPU 的一组 IO 端子上的信号有关 如图 1-3 是其中一个 IO 端子示意图, 实际电路中没有图中的 R1 软件初始化 CPU 内部和外部硬件寄存器时, 错误地把所有与该 IO 口相连的外设端口都设置成输入口, 导致 CPU 的 IO 端子实际上处于类似悬空的状态 处于悬空状态的输入端子, 读入的数据是不确定的, 间接地导致 if(status==true) 语句错误判断,CPU 就跳过这帧数据不发送 这本来是一个小问题, 但查找的过程中走了许多弯路, 花费了大量的时间, 直接使开发进度后延了 10 天, 为什么会出现这样的结果呢? VCC R1 被设为输入态的外部器件端口 1 CPU IO 口 被设为输入态的外部器件端口 2 图 1-3 IO 端子设置不当引发软件 BUG 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 18 页共 409 页

19 首先是这个项目的分工有问题, 它把嵌入式系统的软件和硬件当成是两个独立的 不相关的模块, 并且按照这种观点进行项目人员组织 这种技术观念和分工方法自然导致人才选择和培养上的缺陷, 在建设软件工程师队伍时完全不考虑其是否掌握基本的硬件知识, 硬件工程师也一样 这种分工组织最直接的后果就是没有人能够处理软件和硬件结合部分的问题, 这个项目最后能把问题查出来, 完全是侥幸, 项目的硬件工程师恰好具备较强的软件知识, 能读懂并分析代码 在实际工作中, 这种分工方法也容易造成软件工程师和硬件工程师缺乏沟通, 各自闭门造车 其次是在技术本身, 在软件工程师和硬件工程师独立分析问题的情况下, 上述问题确实难于判断是硬件故障还是软件 bug 造成的 通信问题自然可能跟通信接口硬件相关, 大家都知道, 通信口与产品外部世界相连, 容易受各种干扰甚至破坏性的干扰, 比如静电放电, 是容易出故障的部分, 在只有一台样机异常的条件下, 的确容易使人误判为硬件故障 ; 该软件确实在大多数装置上运行流畅, 只有个别装置上出问题, 从日常经验上也容易判为硬件故障 但实际上这个故障是软件和硬件同时存在问题造成的, 软件 bug 刚才已经讲过了, 而硬件的问题在于没有从设计上避免 CPU 输入端子上数据不确定的情况, 如果在设计时在 CPU 的 IO 上增加一个上拉电阻 ( 如图 1-3 中的 R1), 就可以是使输入信号在任何时候都是确定的,10 台样机, 要么全部通过, 要么全部不通过, 避免了随机性 顺便提一句, 在设计输出控制电路时, 也应该保证在 CPU 复位期间状态的确定性和安全性 象这种和软件硬件都有关系的问题, 如果不用软硬件综合的方法去分析, 如果工程师不同时掌握软硬件知识, 要排查这个问题确实不容易 在这个开发小组中, 软件开发和硬件开发是严格分开的, 硬件工程师只负责硬件, 软件工程师只负责软件, 软件和硬件的结合部就成了三不管地带, 出了问题只能靠老天爷了 本例中, 虽然最后由硬件工程师查出了问题, 但却要付出加倍的代价, 要知道, 查别人写的半成品软件可不是一件容易的事 如果项目中不把软件和硬件割裂, 而是有专人负责软件和硬件结合部, 则情况可能会好很多 那么, 同样的软件, 为什么会在 9 台样机上成功, 只有一台不成功呢? 问题就出在 IO 口悬空上, 读入悬空的输入口上的数据, 结果是不确定的, 通常情况下, 会得到一个固定的值, 比如读入悬空的 TTL 输入口, 一般得到 1, 而 CMOS 口则大多数时候得到 0 但这样的 1 和 0 是不可靠的, 他容易受各种干扰的影响, 在一定条件下, 就会满足本例中 if(status==true) 条件, 不同的板子满足条件的情况出现几率不一样, 恰好出故障那块出现的几率比较大, 就出现了上述现象 而带上仿真器, 又改变了电路的工作状态, 使故障不再重现 其实, 只要测试次数足够多, 其他 9 块板子也会出现类似故障的, 在后来的测试中验证了这个猜想 1.3 软硬件联合设计方法 传统与联合的方法最大的差异在于软硬件等同的概念和软硬件模块间的接口设计上 随着数字电子技术的发展, 原来只有硬件才能解决的问题, 越来越多地可以用软件方法实现 ; 反过来, 随着可编程逻辑器件功能的日益强大, 硬件器件的可编程配置化, 以及软件模块的硬件化, 使得越来越多原来只能用软件实现的功能, 可以用硬件实现 软硬件的界限已经不是非常清晰, 很多问题可以从硬件方面去解决, 也可以从软件的角度解决, 需要根据实际情况灵活把握 这对嵌入式设计工程师提出了更高的要求, 特别是系统设计工程师, 需要同时掌握硬件的特征和软件的特征 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 19 页共 409 页

20 D: 其他部分 A: 纯软件 B: 软硬件 C: 纯硬件 图 1-4 现代电子产品典型组成图图 1-4 现代电子产品典型组成图, 从图中我们看到, 现代电子产品主要由 4 个部分组成, 分别是 : A: 纯软件部分, 即只能用软件代码实现的部分, 也有人说, 从广义上说, 是没有硬件实现不了的, 也就没有纯软件, 但这不免有些钻牛角尖了, 这部分是软件工程师需要全面掌握的 B: 软硬件, 即可用软件也可用硬件实现的部分, 我们平常说的软硬件联合设计指的就是这部分 在这部分, 软件工程师侧重于软件部分, 需要了解硬件部分 ; 硬件工程师侧重于硬件部分, 但要了解软件部分 ; 系统工程师则软件部分和硬件部分都需要熟练掌握 C: 纯硬件部分, 即系统中只能用硬件实现的部分, 例如显示器, 射频模块, 大功率电路等, 这部分是硬件工程师需要熟练掌握的 D: 其他, 即非电子部分, 比如外壳, 外观图案, 商标等 我们谈论软硬件联合设计, 并不是不加区分地把硬件和软件撸在一起进行设计, 这样你会无所适从 软硬件联合设计要解决两个问题, 一是如何拆分系统需求, 恰当地用软件和硬件实现系统部件, 使系统综合性能最优化 ; 二是要解决软硬件模块互相转化的问题, 为了达到设计需求, 软硬件联合设计要求部分软件模块和硬件模块具有互换性, 在互换过程中不能大幅度修改设计, 尤其不能修改与之无关的模块 第 9 章将提出一套解决软硬件互换问题的系统设计方法 要实现软硬件联合设计, 要求系统设计师同时掌握软件和硬件知识, 嵌入式软件工程师掌握基本的硬件知识, 硬件工程师也要掌握基本的软件知识 不再把硬件和软件看成是有严格区分的领域, 而应该是相互补充且相互可以替代的领域, 把硬件功能模块和软件功能模块统一对待, 统称做产品功能组件 ; 在开发过程中, 或者在维护过程中, 排查故障和设计缺陷时, 更不应该把硬件和软件割裂, 这样会让你多走很多弯路 在第 9 章中我们还会看到, 软硬件联合设计的思想会使传统属于软件范畴的中断驱动程序和设备驱动程序的开发方法发生很大的变化 图 1-5 是一个典型的软硬件联合设计的过程, 整个产品开发过程中, 都没有严格区分软件和硬件, 而是以系统实现为中心, 平衡开发进度 开发成本 生产成本 维护成本 产品性价比的条件下, 软硬件择优使用 软硬件联合设计之于传统设计的区别, 是一种设计思想上的转变, 而不仅仅是软件设计和硬件设计谁先进行的差别 仅从项目进度上讲, 软硬件联合设计也可能先执行硬件开发 再执行软件开发, 特别是一些中小项目, 需要部分工程师同时执行软件开发和硬件开发的工作 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 20 页共 409 页

21 硬件发展现状及趋势 软件发展现状及趋势 不同型号间移植的需要 公司产品路标规划 公司产品升级换代移植 需求 规格确定, 开始设计 反馈 系统方案设计 反馈 划分实现方式 : A: 纯软件部分 B: 软硬件均可 C; 纯硬件部分 细分 B 部分, 明确软硬件分工 B 部分模块之间接口设计, B 部分与 A C 部分接口设计 辅助工具 : CORSAIR,POLIS 等协同设计软件 反馈 注 : 完成划分以后, 有些项目已经可以启动软件和硬件方案设计了 软件方案设计 硬件方案设计 接口设计模块设计编码调试测试 软件设计过程 软件工程师验收 测试 软件微调本次调整涉及的模块 NO YES 硬件原理图 PCB 设计 硬件测试版输出 第一版输出 B 部分调整后输出 硬件板件输出 此过程可能多次反复 软硬件配比合适吗? YES 结束 NO 提出修改意见 调整 B 部分软硬件比例 图 1-5 软硬件联合设计过程 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 21 页共 409 页

22 1.3.1 系统方案设计阶段 需求和产品规格是本阶段最重要的输入数据, 这里所说的需求是指经过提炼的 适合设计师阅读的需求, 通常客户并不是嵌入式系统的专业设计人员, 也不是产品设计人员, 他们用自己的想象 自己的话而不是专业术语来表达需求, 这种表达很不严谨, 甚至会有一些不切实际的期望 对于用户描述的需求, 不同的嵌入式设计人员会有不同的理解, 直接作为设计输入会在设计团队中制造混乱 在开始设计之前, 必须先把用户需求转化为用专业术语描述的需求和规格说明, 这个说明必须是严谨的 一致的的说明, 任何嵌入式设计人员阅读时都能得到一致的理解 图 1-5 中, 系统设计是产品设计最初的抽象阶段, 在这个阶段, 会把需求翻译成一个体系结构框图, 框图中包含一个个相对独立的功能模块, 规定了每个模块的主要功能和模块间的数据流 这个框图仍然很抽象, 它没有设计任何实现细节, 也没有划分软件部分和硬件部分 简化模块间数据流非常重要, 过于复杂的数据流将增加系统的复杂性, 以及模块间互相关联的可能性, 甚至会使模块间产生过多的互相依赖性, 我们称之为模块耦合, 在第 11 章有详细论述 模块间的耦合有两种, 一种是运行时的耦合, 两个模块争夺 CPU, 或者一个模块需要使用另一个模块输出的数据, 就属于运行时耦合, 同一个程序里的所有模块都或多或少地会有一定的运行耦合 运行时的耦合是不可避免的, 只要合理分配好资源, 这种耦合一般没有太大的危害 另一种是代码互相耦合, 即一个模块的实现方法与另一个模块的实现方法有关, 当修改一个模块内部实现时, 可能导致其他模块也做相应的修改 模块间接口设计不当经常产生这种耦合, 这种耦合就非常有害了 在这个阶段中, 企业产品路标规划起着举足轻重的作用, 对企业产品开发来说, 技术可移植性首要考虑的是企业内不同产品之间的移植 ( 参见 节 ) 在系统设计阶段考虑引入产品路标, 从全局角度进行抽象, 会使产品具有最大的可移植性, 使企业产品开发逐步走向标准化, 开发工作越来越轻松, 而大量模块的重复利用, 将使企业产品越来越稳定 即使有些公司没有明确的产品路标规划, 也要考虑企业产品可能的发展方向 有人会怀疑, 这样会不会增加工作量, 增加成本? 这种担心是有道理的, 在功能相同的情况下, 可移植的模块需要考虑各种可能的情况, 会比专用模块复杂一些, 开发难度也相应会大些, 导致开发成本的上升 ; 更加复杂的模块会需要更多的资源和更快的 CPU 速度, 这可能导致生产物料成本增加 但这也是相对的, 因为你为别的产品提供可重用组件的同时, 你也可以大量使用其他产品的组件, 节省大量开发时间 因此, 如果没有组件库或者库中的可用组件很少时, 确实会增大开发难度 ; 当产品组件库达到一定规模时, 新产品开发就会如鱼得水, 左右逢源 构件的重复使用, 会大大增加产品的可维护性和可靠性, 由此带来的生命周期成本降低, 可能会弥补增加的生产成本甚至超过生产成本增加量 管理软件开发过程的 7 个主流模型中, 就有 3 个是基于可重用组件的 [5], 而最好的最可靠的可重用组件存在于企业自己的产品中 有许多企业都很重视货架技术建设, 并有专门开发力量进行货架建设, 货架技术 实际上就是可重用的组件 根据产品路标规划, 从每一个产品系统设计时提出, 并在开发过程中实现的组件, 具有无与伦比的实用性 软硬件业界发展水平也是系统设计阶段首要考虑的因素, 不能使用过于超前或者滞后的技术, 孔子过犹不及的思想在这里得到了最好的诠释 系统方案需要用符合当前技术发展水平和趋势的 主流的技术方案去实现产品需求和规格书的要求, 否则你会为此付出代价 为什么不能使用太超前的技术方案呢? 首先, 会增加开发成本, 超前的技术方案会使你的设计成为无根之木 无源之水, 开发过程中能够的到的外部技术支持非常少, 会使你的开发力量大量消耗在新技术 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 22 页共 409 页

23 的探索中去 在这个技术分工日益细化的世界, 嵌入式产品开发处于技术开发的下游, 而处于上游的是芯片 开发工具厂商, 中游厂商则开发许多中间件, 比如嵌入式 gui 模块 TCP/IP 模块等, 下游厂商应该使用上游厂商完成技术验证后的芯片和开发工具, 再根据需要选用适当的中间件, 然后构造自己的产品 系统方案如果过于超前, 你将难于得到上游和中游厂商足够的支持, 另外, 在网络和 BBS 上讨论也是重要的开发支持资源, 过于超前的技术在这里同样得不到支持 其次, 会增加生产成本, 上游和中游厂商为了收回技术开发投资, 在产品推出的初期, 往往定价较高, 然后逐步下降 再次, 会增加产品开发风险 电子技术发展的前端, 总是百花齐放, 百舸争流, 各种先进技术激烈竞争, 其中只有一小部分能够成为主流应用, 非主流产品很快就会枯萎, 相关芯片也会很快停产 超前的技术方案, 如果没有侥幸地恰好选择了主流技术, 将使我们所有的开发工作付之东流 使用过于超前的技术方案不可取, 那么, 使用滞后的方案为什么也不对呢, 这同样可以从技术 成本 风险角度进行分析 现代电子产品开发中, 上游厂商的技术支持非常重要, 但是上游厂商的技术支持一般集中在其主流产品方面, 对处于生命周期后期的产品, 只提供基本的技术支持 如果系统方案滞后于当前主流技术, 将迫使后续的硬件设计选择处于生命周期后期的芯片 不单是硬件, 软件也同样面临问题, 我们可能得不到合适的中间件, 或者得到了中间件但是得不到充分的技术支持 至于生产成本增加, 这是显而易见的, 所有厂商都会调高不再主推的芯片价格, 迫使用户转移设计, 直到停产 在开发过程中, 选择一款芯片之前, 要养成一个习惯, 咨询芯片生产商, 确认该芯片是否主流产品, 也可以在网上查到该信息, 大多数厂商会在网上列出产品目录, 目录中, 老产品上往往标明 不推荐用于新设计, 或者目录中根本就不列出即将淘汰的型号 至于风险, 是不言而喻的, 处于生命周期后期的芯片, 随时有停产的可能, 芯片都停产了, 还有什么说的 图 1-6 芯片的价格和厂商技术支持曲线把握技术趋势是一项复杂艰巨的工作, 而且存在一定的风险 一般来说, 嵌入式系统的规格主要由计算机运行速度和存储器配置两方面决定, 速度指标应该是目标系统相关领域的测试基准衡量的实际系统运行速度, 而不是 cpu 主频, 比如用于整数数字逻辑处理的计算机, 可以使用 dhrystone 基准, 用于浮点运算的计算机, 用 whrystone 基准, 用于数学分析的计算机, 则应该使用 DBTImark2000 基准 在系统设计阶段, 需要确定嵌入式系统的规格, 这要求系统设计师必需对整个系统的复杂性有充分的认识, 需要大体确定哪些构件由硬件实现, 哪些构件由软件实现, 哪些构件由软硬件共同实现 嵌入式系统的规格也基本确定了其 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 23 页共 409 页

24 造价和开发工作量, 这又可以反过来核对需求和规格书是否合理 在系统设计阶段, 应用面向对象的方法非常重要, 面向对象的设计方法虽然首先是从软件学中发展起来的, 但它并不是软件设计的专利 设计师应该从需求和规格书中抽象出系统组件的工作, 其实就是把需求对象化, 而这些系统对象必需有严谨而完备的输入输出说明, 但并不涉及其内部实现细节, 也不关心组件对象的内部行为, 更不用关心这个组件是用软件实现还是用硬件实现的 这样, 既明确规定了下一步需要做的工作, 又留下了广阔的灵活设计空间 系统方案中还要考虑易于用相匹配的软件方案和硬件方案实现, 如果在系统方案设计时考虑不周, 那么在后续的软件方案设计和硬件方案设计中, 就有可能迫使工程师选择不相匹配的方案 软硬件分工设计阶段 完成系统设计后, 接下来要做的就是软硬件划分, 在这个阶段, 系统设计工程师的实际灵感 知识结构和经验非常重要, 一个项目, 通常分为 : 纯软件部分 纯硬件部分 软硬件均可以实现的部分 软硬件共同实现的部分 划分模块后, 设计模块间和模块内的接口是本阶段最重要的工作 有些模块, 它并不是单纯的用软件或者用硬件实现, 而是用软件接口和硬件共同实现, 比如模拟量输入模块就是非常典型的一种 在这种模块就像跷跷板一样, 既可以朝硬件倾斜, 采用高性能的 A/D 转换器件, 让硬件做更多的工作, 以降低软件的负担 ; 又可以朝软件倾斜, 用软件的方法提高 A/D 转换性能, 让软件做更多的工作, 可以降低产品成本 软件 硬件 图 1-7 象跷跷板一样改变软硬件实现比例以成本换进度, 迅速占领市场, 然后再进一步开发以降低成本, 是企业竞争中常见的策略 在这种市场策略指导下, 产品开发的初期是不会仔细计较成本的, 表现在图 1-7 中, 就是硬件的分量大于软件的分量 此时, 设计师不会仔细估计所需要的计算机性能, 可能选择大大超出要求的 CPU; 不会仔细估计存储器速度和容量需要, 片面地配置高速大容量存储器 ; 外设配置方面, 也会片面地配置高性能外设 总之, 能实现需求和规格书的要求就好, 成本不是最重要的 产品成功推向市场后, 继续进行二次开发, 发展功能相同的低成本版本, 或者根据市场反应停止开发 这个时候, 软件的分量就要加重, 软件开发虽然要付出开发成本, 但是制造成本会因此大大降低 传统开发模式下, 软件针对特定硬件开发, 低成本方案开发时, 如此大规模地修改硬件配置, 很可能会引起软件大规模的修改, 甚至重新开发 使用软硬件联合设计的方法, 整个软硬件系统天生就有匹配不同软硬件配置的能力, 修改硬件配置时, 完全可以做到只修改与 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 24 页共 409 页

25 被改动的硬件直接相关的代码, 使 高成本版本 的软硬件模块可以最大限度地转移到 低成本版本 中, 使两个版本保持高度一致性, 这种一致性将带来莫大的好处 首先, 可以降低二次开发的工作量和测试工作量, 加快低成本版本的上市时间, 为企业节省大量开发和生产成本 其次, 可以降低维护成本, 两个版本保持一致, 可以用一致的方法维护, 用户也可以用一致的方法养护产品, 这两者都可以大大降低维护和培训成本 反馈 - 软硬件分工调整阶段 在系统设计阶段, 要准确估计软硬件需求是极其困难的, 甚至是不可能的 现代嵌入式产品是如此复杂, 准确估计单个模块的计算机运算能力需求和内存需求都是很困难的, 不同的软件算法对硬件的需求都不一样 而且, 嵌入式系统除了 CPU 运算能力和内存以外, 还涉及到许多实时性的问题, 模块间配合的问题, 这些都对我们估计软硬件配置和比例提出了挑战 既然我们不能指望准确估计硬件需求, 那么, 我们最好避开它, 不战而屈人之兵才是上上之策 避开并不是逃避, 完成产品设计才是我们的最终目的, 我们需要一种设计方法和技术, 保证我们不需要在系统设计阶段准确估计软硬件配比, 使我们既可以在设计过程中灵活调整软硬件配置和比例, 又能够控制开发进度 运用软硬件联合设计方法, 我们可以在系统设计阶段粗略估计软硬件配置, 并给软硬件可以互相转化实现的部分设计严格的接口, 使其高度封装, 我们姑且称这种模块为 协作模块 其他的软件模块和硬件模块只能看见封装后的协作模块, 而根本不知道其内部是由软件实现还是硬件实现 如果某协同模块用软件实现, 它就必然占用 cpu 执行时间和内存资源, 如果在软件设计过程中发现资源紧缺, 就可以要求调整该协作模块的软硬件配比, 并反馈给硬件设计, 要求增加该协作模块的硬件功能, 等硬件设计完成时删除该协作模块的冗余的软件部分 整个过程就像图 1-7 所示的跷跷板一样, 所有的修改工作均封闭在这个模块内部进行, 不影响别的模块, 也不影响系统运行, 硬件开发工作和软件开发工作均按自己的程序进行, 互不影响, 反之亦然 软件设计中反馈调整硬件设计, 是传统设计方法和软硬件联合设计方法都需要的步骤 但是两者有着巨大的区别, 对传统设计方法来说, 软件要求调整硬件设计是一种设计错误导致的异常事件, 会对开发进程造成冲击, 有经验的工程师会为估计发生这种异常事件的可能性, 并在计划中预留缓冲时间 但是, 究竟保留多少时间 哪里可能出现异常 什么时候会发生异常, 只有天知道! 这种冲击严重的可能导致硬件整体被推翻, 重新设计 现实中, 许多项目延迟就是因为这种软硬件之间反复调整导致的 传统设计方法常常使软件针对特定硬件设计, 没有对可能的硬件修改保留兼容接口, 不具备可移植性, 硬件的修改反过来影响软件设计, 导致软件大规模修改 如果由于进度的问题, 不允许硬件重新设计的话, 那么软件就必须削足适履地适应不太合适的硬件, 从而限制了产品性能 而对于软硬件联合设计来说, 由于在系统设计阶段就已经考虑到了可能的软硬件配置调整, 并且为软硬件协作完成的功能独立出来并做了完备的封装, 软硬件可能出现交互的地方也设计了良好的接口, 当软件设计要求调整硬件时, 硬件稍作修改就可以 ; 软件工作也无需因此而停下来等待硬件, 因为软件并不会因硬件调整做大的修改, 仅仅是局部模块的内部做些微调而已, 开发过程不会依赖新版本软件, 完全可以在硬件的调整过程中继续进行 由于在系统设计阶段就明确了协作模块的范围, 硬件设计甚至可以预先估计可能的软硬件配比调整, 预先完成多种版本的硬件, 在 PCB 设计中预先留下位置, 预先布线, 使软件设计要求调整硬件时焊接或者取下抑或更换器件就立即得到新版本 有许多电子元器件有序列化型号, 同一序列的不同型号的功能相同, 性能不同, 引脚兼容, 可以直接互换, 这也是动态调整软硬件配比的利器 例如串口驱动器, 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 25 页共 409 页

26 ST16C754 和 ST16C554 的功能就完全一样, 区别是 754 有更深的 fifo, 大容量 fifo 可以降低软件开销, 我们选择 754 还是 554 的过程, 实际上就是调整串口通信模块软硬件配比的过程 ; 又如 AD7656/57/58 序列的 ADC, 功能完全一样,pin-to-pin 互换, 不同的是精度不一样 采样理论告诉我们, 过采样可以提高 ADC 精度, 但过采样需要大量的软件开销, 等于说, 采样系统的精度要求已经确定的情况下, 加大软件开销, 可以降低 ADC 本身的精度要求, 等同于降低了硬件成本和设计难度 ; 采用高精度的 ADC 型号, 可以降低软件开销, 选择 ADC 的具体型号, 实际上等效于调整模拟量转换模块的软硬件配比 软硬件联合设计, 完全可以采用这种兼容器件来实现, 那么, 软硬件的调整就是更换器件而已 总之, 对软硬件联合设计方法来说, 软硬件配比的调整是主动的而且是可控的过程, 它不会打乱开发进程, 并使最终产品获得最佳的性能 ; 而传统设计方法中, 软硬件调整是被动的, 不可控的过程, 它可能破坏整个开发计划, 而且可能在最终产品中留下缺陷 联合设计会影响进度吗? 软硬件联合设计使我们在开发的初始阶段需要做更多更细致的工作, 具体软硬件启动时间肯定会比传统设计方法晚, 有不少人不愿意花这个时间, 他们认为这样会延误开发进度, 他们更喜欢的是短时间内见到阶段性成果 然而, 我要告诉你, 一个较为复杂的产品, 从开始到完成第一版样机的时间只占开发周期总时间很小的一部分 样机完成后, 开发远未结束, 还要花大量的时间进行软硬件的完善工作, 测试工作所占的时间也不在少数 产品开发过程中, 第一步需要做的是需求和规格定义, 此时, 具体的设计工作还没有开始, 需求个规格定义实际上是有一定的盲目性的, 它需要根据后续开发工作中反馈的信息调整规格 同样, 系统设计阶段的工作也是需要调整的, 这个调整的过程可能出现反复, 样机也许需要做许多版本 联合设计由于软硬件调整很方便, 降低了在系统设计阶段准确估计硬件性能的要求, 开发过程中硬件设计调整也不会影响软件设计的进度 联合设计虽然可能延迟第一版样机的完成时间, 但会大大加快后续改进版本的开发进度, 而且, 由于在系统设计阶段做了更加细致的工作, 还可以减少样机版本数量, 实际上非但不会影响进度, 反而会大大促进开发进度 1.4 软硬件联合设计范例 需求 我们以一个嵌入式系统中最常见的串行通信模块为例, 这是一个简单的工控产品, 其系统结构图如图 1-8 所示, 我们要设计的是其中的总控机部分 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 26 页共 409 页

27 图 1-8 一个典型的现场控制系统总控机功能需求如下 : 用 485 总线与监控设备通信, 采集现场设备的数据, 向监控设备发送指令, 控制监控设备工作 Baud=9600 在 PC 机读取数据之前暂存被采集的数据, 并记录数据采集时间 通过串口与 PC 机通信, 把采集量上送 ; 接受 PC 机的控制命令, 改变对监控设备的控制方法 通信 Baud=9600 用 IO 口点 LED 灯, 显示通信口状态和自身的工作状态 我们来试着设计这个产品的电路及部分软件实现 设计方案 本产品需要两个串口, 但计算量不大, 考虑选用 MCS51 单片机, 这个单片机公司原来用过, 开发工具是现成的, 软硬件开发工程师对这个单片机都比较熟悉, 容易上手, 可以加快开发进度 但该单片机只有一个串口, 虽然也有一些拥有两个串口的型号, 但选择范围窄且价格很高, 现在 51 机的工作频率已经可以达到 40M, 并且有双倍速甚至是 12 倍速的型号,CPU 的运算资源还有冗余, 因此决定使用 CPU 的 IO 口模拟一个串口, 系统结构如图 1-9 考虑到 IO 模拟串口的性能瓶颈问题, 将来产品升级很可能被替换成硬件串口, 故必须把它设计成一个软硬件协同模块, 它虽然在 CPU 内部, 但与其他软件隔离, 只提供一个与硬件串口一致的接口与其他软件模块打交道 内存方面, 由于从机数据量不大, 软件工程师认为外扩个 32K 就足够了,flash 有 4K 就足够了 工业产品可靠性要求高, 要外接一个看门狗电路, 因为要记录时间, 还要加一个实时时钟电路 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 27 页共 409 页

28 图 1-9 主控机软硬件结构单片机本身的串口用于和监控设备的 485 总线通信,IO 口模拟的串口用于和 PC 机通信, 因为 Baud=9600, 每个 bit 收发需 104.2uS, 考虑到要分辨脉冲宽度才能正确接收, 因此在 104.2uS 里至少要查询 3 次 IO 口, 因此启动一个 35uS 的定时中断, 该中断不停地查询 IO 口状态, 检查到有有效起始位时开始接收, 并把接收到的位通过移位程序拼成完整的字节 发送时, 则每 3 次中断往发送 IO 口移出一位数据, 直到发送完成 下面是软件伪代码 主程序 : 初始化各种硬件 ; while(1) SerialReceiver(com_IO); // 模拟串口接收 SerialReceiver(com_Hard); // 硬件串口接收 OtherModule( ); // 其他模块, 包括串口应用层收发模块 } 物理层接收程序 if (fifo 中有数据接收 ) 把数据读到接收缓冲区 ; 向应用层接收模块发信号 ; }else return; 中断服务程序 : 中断程序开始 ; 保护现场 ; if( 状态变量 == 等待起始位 ) 读取 IO 状态 ; 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 28 页共 409 页

29 if( 收到起始位 ) 状态变量 = 接收数据 }else if( 状态变量 == 接收数据 ) 接收 1 位数据 ; 接收到完整数据位则移入接收寄存器 ; if( 接收到完整字节 ) 数据存入模拟 fifo; if (fifo 达到触发条件 ) 设置接收标志 ; // 用于中断外程序从 Fifo 读数据状态变量 = 等待停止位 ; } }else if( 置状态变量 == 等待停止位 ) if( 收到停止位 ) 状态变量 = 等待起始位 ; } if( 超时 ) 置错误状态 ; } if(fifo 中有数据待发送 ) 每 3 次中断输出一位数据到 IO 口 ; 直到发送完成 ; 恢复现场 ; 中断程序返回 ; 该中断程序需要 5~15uS 的执行时间, 具体执行时间与串口工作状态有关 假设在开发中我们碰到几个问题, 讨论一下处理办法 产品功能升级 当产品使用一段时间后, 由于通信数据量的增加,9600 Baud 不能满足需要, 欲增加到 时, 怎么办? Baud=57600 时, 时钟中断间隔时间只有 5.8uS, 中断程序的执行时间却要 5~15uS, 显然不能满足要求 怎么解决这个矛盾呢, 通常会用以下几种方法解决问题 如果中断的执行时间足够短, 系统是能够满足要求的, 通过软件优化, 用汇编重写, 或者改进算法, 加快中断程序执行时间, 使其满足要求 这种方法的好处是不需要修改硬件, 仅升级软件就可以了 当升级软件不能达到要求时, 可以通过提高主频, 或者使用效率更高的 CPU, 缩短中断程序的执行时间 这种方法在同系列 CPU 中有合适的型号时, 硬件的改动最小, 同时软件移植工作量也小 当以上两种方法不能奏效时, 我们分析,CPU 用于串口通信的主要时间是花在一位一位处理数据上, 那么使用专用硬件, 比如改用内部带两个 Uart 的 CPU, 或者使用 16C554 等专用硬件, 代替图 1-9 中的 IO 串口模块 这样修改后, 系统框图就变成了图 1-10 的形式 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 29 页共 409 页

30 RXD CPU 及软件 485 驱动 TXD CPU 片内串口 1 监控设备通信 DB9 232 接口芯片 RXD TXD CPU 片内串口 2 物理层接收程序 应用层接收程序 其他程序 PC 机通信 内存, 看门狗, 时钟等硬件 图 1-10 用硬件加速主控机串口从问题二的解决方法中, 我们可以看到, 一个功能的实现, 可以用硬件的手段, 也可以用软件的手段, 换一种思维, 当用专用硬件实现串口接收时, 我们可以看做是把图 1-9 中的用于串口接收的部分软件和硬件都搬到了 CPU 外面, 用硬件的方法实现了软件模块 实际上 16C554 是典型的软件硬化后的硬件产品 因此, 我们应该改变固化的 硬件模块 和 软件模块 的观点, 在系统设计初期, 只有 功能模块, 具体一个功能模块在实现时究竟用软件还是硬件, 是要综合衡量的 在解决问题时, 也不能想当然地认为哪一类故障是软件故障, 哪一类故障是硬件故障, 而是应该从软硬件联合角度去分析 1.5 软硬件协同分析问题 在产品开发过程中, 或者是产品生命周期的维护过程中, 可能会发生很多问题需要分析 用软硬件联合设计的产品, 当然要用软硬件协同的方法来分析问题 软硬件相互转化 我们经常难于分清软件故障还是硬件故障, 是因为他们根本就是一致的东西, 在一定的条件下, 会互相转化的, 硬是人为地严格区分软件故障还是硬件故障, 只能使我们迷失方向, 使本来就艰难的工作添加更多的障碍 根据设计方法和运行条件的不同, 性质和外部表现都相同的问题, 既有可能是软件 bug 造成的, 也可能是硬件故障或者缺陷造成的 因此, 我们在开发调试和维护产品时, 一定要了解软件和硬件各自的特性, 避免主观臆想的思维定势, 不能抱定哪些问题是软件问题, 哪些问题是硬件问题, 记住软加问题和硬件问题有时候是很难区分且可能互相转化的 因此, 需要用软硬件联合的角度, 从故障特征判断是哪一个功能模块出了问题, 然后再根据这个功能模块的实现方式进一步定位问题的位置, 直到这个时候, 我们才能真正区分问题出在软件还是硬件上, 还是软硬件配合上 调试第 1.4 节所设计的产品时, 发现装置与 PC 机通信有时候会中断, 经检查确认 PC 端 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 30 页共 409 页

31 没有问题 检查此类问题时, 我们一般会从以下几个方面查问题 : 首先确定硬件有没有问题, 用示波器检查 232 转换芯片输出是否正常, 检查 232 接收信号是否正常 如果信号不正常, 则检查连接线接触是否可靠, 芯片有没有虚焊,232 电平转换芯片是否损坏 如果上述检查通过, 则怀疑软件有 Bug, 用仿真器或者其他调试手段检查中断程序是否正确接收到 PC 机发送的数据, 再检查发送给 PC 机的数据是否正确地送到发送 Fifo 就这样沿着程序执行时数据流向一步一步地查下去, 直到查到 Bug 的位置 我们看到, 排查问题时, 我们是同时从软件和硬件量两方面着手的, 并不是孤立地怀疑是硬件故障还是软件故障 经过跟踪程序运行, 我们发现不管有没有收到数据, fifo 中有数据接收 的标志总是被置成 1, 在主程序里查询该标志, 查到有数据接收标志后就启动数据接收程序, 如果中断总是设置该标志, 软件就总是忙于接收数据, 造成通信程序不正常 除通信程序工作不正常外, 由于通信程序占用大量 CPU 时间, 轻则会造成系统变慢, 重则造成系统死机, 使软件失去反应能力 这个问题的解决方法很多, 在这里就不浪费篇幅了 这是一个软件容错性方面的问题, 一个强壮的软件, 应该在一个模块出现错误时, 故障限制在出错的模块内部, 仅出错模块所在的功能部件工作不正常, 其他模块应该不受影响而且能通过设定的方法报告错误并记录 在本案例中, 一个模块工作异常就影响整机运行甚至造成整机死机是不允许的 现在讲一个笔者亲身经历过的一个案例, 该项目中软硬件也是分开设计的 某产品需要较多的串行通信口, 使用了一片 16C554 用于串口通信扩展,16C554 的 4 个中断输出相或后连接到 CPU 的外部中断上, 如图 1-11 所示 16C554 的 4 根中断线分别对应 4 个串口, 串口申请中断的方式是使相应的中断线变成高电平, 中断状态被清除后, 恢复低电平 16C554 的具体工作方式参见它的数据手册, 本书不表 串口输入 中断输出 16C554 CPU 图 个中断信号相或后接到 CPU 的一个中断输入上该例中, 在系统设计时并没有规定 CPU 使用电平中断还是边沿中断方式, 软件工程师按照自己的习惯选择电平中断方式, 只要外部中断线输出高电平就进入中断 开始运行了很长时间都没有发生问题, 终于有一天问题暴露了出来, 一台产品上电不工作, 键盘 显示 通信都没有任何反应, 后来又陆续出现了几次 最后查出来的结果是 16C554 故障, 有一个中断引脚总是高电平, 造成 CPU 一直出于中断状态下 该产品使用的是 ARM 系列的 CPU, 该 CPU 与 X86CPU 不一样,X86 系列在中断返回后至少要执行一条指令后才会再次进入中断, 即使出现连续中断的情况, 仍然会对外部操作做出蜗牛式的反应, 而 ARM 的中断结构不一样, 当中断函数返回后, 如果中断信号仍然存在, 就会立即进入新的中断服务函数, 中断外程序一条指令都不会执行, 导致产品没有任何反应 本节描述的两个问题, 其本质是相同的, 都可以描述成 当系统出现一个异常信号时, 使整个系统包括与该信号无关部分不工作 但前者毫无疑问是软件 Bug, 中断程序有一个明确直接的 Bug, 主程序有容错性方面的 Bug, 软件工程师责无旁贷 而后者却可以扯皮, 硬件工程师会说 这是元器件故障, 我不能完全杜绝, 而软件工程师也会说 这是硬件故障, 跟软件没有关系, 这不, 换硬件就好了!, 最后是谁都没有责任,bug 随着产品一同发 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 31 页共 409 页

32 布出去 这两个性质一致的问题, 对 CPU 来说, 都是判断一个标志量, 根据这个标志量的值决定是否要读串口接收缓冲区, 所不同的是, 前者这个标志量由中断程序给出, 后者通过 CPU 的中断引脚给出 ; 而两者造成的后果都是一样的, 就是造成 CPU 忙于执行串口接收工作, 导致系统异常甚至死机 ; 两者的解决方法也一样, 当 CPU 检测到该标志总是存在时, 屏蔽相应的中断, 使错误仅局限于出错模块, 使其他模块正常工作 在这里, 同一个功能, 根据实现方法的不同, 软硬件问题相互转化了 我们常常会碰到一些潜伏很深的故障, 几小时, 几天甚至几个月才出现一次, 这说明, 很多故障是要符合特定的条件才能暴露出来的 由于硬件的离散性, 输入端子上的电压处于临界状态时,CPU 读该端子上的数据, 有些器件可能读到 1, 另一些器件可能读到 0, 有些特定条件可能在这块板出现, 而另一块板则不出现 而大量的可编程, 可配置的硬件的出现, 如果这些器件没有正确地编程或配置, 往往会使程序运行出现截然不同的结果 我们常常听到软件工程师抱怨, 一样的软件, 在这块板上能运行, 而在那块板上则出现错误, 昨天能运行, 今天就不能运行了, 从而陷入迷茫中, 其实出现这类故障, 有可能是硬件有故障, 也有可能是软件对硬件的离散性或者初始化状态考虑不足, 或者没有对可配置的硬件正确初始化, 例如未初始化的内存 嵌入式软件工程师应该对硬件尤其是可编程可配置的硬件有所了解 而硬件开发和底层驱动程序的开发, 也要考虑尽可能地给软件工程师一个标准化的, 一致的编程接口 软硬件互存互容 既然有许多功能使用软件和硬件都可以达到, 我们在设计中更倾向于把软件和硬件模块等同对待, 在系统中互存互容, 使系统功能高度积木化, 这会对软件开发提出更高的要求 高度积木化的设计, 使产品系列的开发也具有高度的弹性化, 快速化 例如在产品开发初期, 为了能快速推出占领市场, 对开发进度的要求会远大于成本控制的要求 这时候, 我们可以根据公司软件开发力量和硬件开发力量的对比, 控制软件模块和硬件模块的选用, 使开发工作同步快速进行, 以期缩短开发周期 ; 但随着产品产量的增加, 我们可能很快就要面对成本的压力, 这时候, 可以把一些硬件模块转换成软件模块, 从而降低成本 高度积木化和弹性化的设计, 将大大降低移植的风险, 加快移植的进度 软硬件设计过程中应该互相配合, 互为容错, 以下几点一定要注意 : 1 硬件要容软件的错, 在软件出错时, 应尽可能减少硬件误动的可能 2 硬件要考虑软件死机, 硬件不但要复位系统, 而且要在复位期间尽可能保持系统安全, 复位前, 复位中, 复位后都不能随便修改 IO 设计者还应确保不论软件做什么样的操作硬件都不应在短时间内发生永久性损坏 3 软件要容硬件出错, 硬件出错时, 软件应该使故障范围缩到最小, 除出故障部分工作不正常以外, 其他部分应该继续正确工作 绝对不能因部分硬件错误导致整机不工作 4 软件除了在模块之间要容错外, 还应该有诊断硬件故障的能力, 当硬件故障时, 应记录并显示或通过通信送出故障状态 5 当确定是软件错误时, 并不代表硬件设计者就完全没有责任了, 应该检查硬件是否考虑了容错, 同样, 确定硬件故障时, 也不代表软件工程师就可以高枕无忧了, 也应该检查软件是否考虑了硬件容错 尤其要避免的是互相推诿扯皮, 最后问题就挂在那谁也不理, 等到产品大面积故障时再处理就晚了 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 32 页共 409 页

33 1.6 软硬件协作提高可靠性 硬件措施 在硬件设计中使重要的输出端子的状态可以回读, 使软件可以做相应的容错检查 假设软件可能存在严重的 Bugs, 确保不论软件做什么样的操作硬件都不应在短时间内发生永久性损坏 保证软件运行环境正确, 寄存器 CPU 状态 内存以及固件数据不被意外修改 软件出错时, 尽可能降低硬件误动的可能, 比如对一些重要的操作规定严格的时序或状态组合, 使出错代码难于满足该时序或状态组合 重要的数据存储在串行操作的存储器里, 如 I2C 总线, 错误代码是很难满足 I2C 总线时序的 甚至还可以做双备份容错 如果软件发生严重错误而死锁, 要有复位计算机从而使软件恢复运行的机制, 比如使用看门狗复位, 硬件要保证复位期间系统安全, 也不能随意改变系统的输出状态 软件措施 软件措施虽然不能防止造成硬件永久性损坏的干扰, 但只要处置得当, 还是能防止很多不可恢复的故障 ( 需复位解决 ) 和可恢复的故障 ( 造成短时间混乱 ) 要编写抗干扰能力强的软件, 就要牢记 不确定性 四个字, 一定不能认为端口 寄存器等的状态是确定的 在严重的干扰下,CPU 外设的寄存器可能会意外改变, 这些改变可能会立即导致灾难性的后果, 也可能不会立即表现出来, 而且只要软件做适当的处理就能消除错误 如同硬件上的抗干扰措施一样, 软件抗干扰措施也是有代价的 通常, 程序代码会更大一些, 程序执行会慢一些, 这意味着更多的存储器 更高的 CPU 速度, 要权衡这些代价与使用硬件方法抗干扰的成本 软件措施一般可以概括为 : 定期检查状态 定期检查 IO 端子的配置和状态, 使输入端子始终保持输入状态, 而对于输出端子, 则根据检查结果作出相应处理, 如果输出端子所控制的设备是电平敏感的, 则定期用正确的数据刷新输出端子的输出电平就可以了 如果输出端子所控制的设备是边沿 ( 即电平的改变 ) 敏感的, 则不能简单地刷新状态了事, 而是要根据设备的特性做出相应的处理 上述 IO 端子包括 CPU 本身端子和扩展端子 定期检查外设的状态, 在出现异常时用正确数据重新初始化外设 ( 包括 CPU 片内和片外扩展外设 ) 陷阱强烈的干扰或者是软件 bug 有可能使程序指针 PC 跑飞 ( 即 PC 值不在正常代码范围以内 ), 有一些 CPU 设置了非法指令地址捕获结构, 当 PC 跑到非法程序地址时, 就会发生中断, 记下发生错误的指令地址, 然后 PC 跳转到指令异常中断向量处 我们可以在非法地址中断处理程序中写入相应的处理程序, 以降低干扰对系统的危害 使用非法指令地址异常设计陷阱的过程如下 : 1 正确设置 CPU, 使合法地址为包含正常代码地址最小范围 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 33 页共 409 页

34 2 编写指令异常中断处理程序, 对错误做出相应的处理 对于没有指令异常处理机构的 CPU, 处理起来就要困难一些, 但还是有办法处理的, 在 空闲 ROM 地址处写入调用诊断函数的代码, 出错处理函数的流程如图 1-12: 图 1-12 没有指令地址异常捕获功能时的陷阱设计注意, 在空闲地址空间要填写函数调用指令而不是跳转指令, 因为使用跳转指令的话诊断程序无法确定是从什么地方跳过来的, 而函数调用指令 CPU 会自动保存返回地址, 有些 CPU 保存在栈里, 有些 CPU 保存在特定寄存器里, 这个返回地址对诊断函数正确诊断错误原因是非常重要的 还要注意的是必须保证函数调用指令被正确解码, 否则不能捕获跑飞的程序指针 对 RISC 处理器来说, 直接填写调用指令就可以了, 对于 CISC 处理器来说, 函数调用指令往往是多字的, 每条指令间就要填写若干条 nop 指令, 以防止函数调用指令被中间截断,nop 指令的条数应该等于函数调用指令的字数 以最常用的 51 单片机为例, 假定诊断函数的地址为 0x0075, 从 0x1000 处开始是空闲地址, 则从 0x1000 开始放置指令 Lcall ox0075 Lcall 指令的汇编码为 0x12, 于是从 0x1000 开始的内存数据如下, 0x1000 0x1001 0x1002 0x1003 0x1004 图 1-13 陷阱指令被错误译码此时, 如果在干扰条件下使 PC 跳到 0x1002 处, 则 CPU 从 0x1002 处开始取指, 不幸的是,0x75 刚好是指令 mov dptr,#data16 的汇编码, 于是 CPU 便一直执行 mov dptr,#0x1200 直到内存终点,lcall 指令将不能得到执行, 诊断函数自然也不起作用了, 如果我们在每 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 34 页共 409 页

35 条 lcall 指令后加入 2 条 nop 指令, 则无论如何 lcall 指令都能执行到 0x1000 0x1001 0x1002 0x1003 0x1004 图 1-14 确保陷阱指令被正确执行为了配合诊断函数的运行, 软件应该在关键的地方留下脚印, 诊断程序会根据这些脚印作出正确的诊断, 记录这些信息也为事后的人工诊断提供信息, 这对软件维护和消除 bug 都是至关重要的, 许多系统都有一个日志文件, 这个日志文件里就包含了许多诊断信息, 嵌入式系统由于大多数时候都是在无人监控的条件下运行, 而可靠性要求又那么高, 因此保留诊断信息就显得特别重要 1.7 可靠性分级设计 众所周知, 功能相同的产品, 如果可靠性要求不同, 其成本和技术复杂度并不一样 ; 同一个产品, 也由多个模块共同构成, 各个模块的可靠性要求也可能不一样 我们常说嵌入式系统的可靠性要求高, 究竟高在哪里呢? 是所有模块的要求都很高吗? 显然不是,80/20 原则告诉我们, 在绝大多数情况下, 高可靠性产品, 往往只有 20% 的模块是要求高可靠性的, 另外 80% 的模块, 可靠性降低一点是允许的 比如汽车电子系统, 刹车控制部分的可靠性要求很高, 必须做到万无一失, 而汽车音响 车载 DVD 系统这些娱乐设施, 其可靠性要求不会高于普通民用影音产品 按照功能的可靠性要求不同合理地分割模块, 可以合理地分配有限的研发资源, 降低整个系统的平均可靠性要求, 从而加快研发速度, 抢占市场 ; 降低研发和生产成本, 增加产品竞争力 火星探路者号上的软件设计是一个很典型的可靠性分级设计的案例 探路者号刚上火星不久, 就开始犯傻 开始无规律地重启, 火星探路者号上使用 vxworks 作为操作系统, WindRiver CTO David Wilner 先生在 IEEE 实时系统会议上分析说, 由于优先级翻转导致巡航软件严重错误, 正是这个错误导致了软件重启 火星探路者号的工程师们花费了极大的精力用于保证着陆软件部分的质量, 使其几乎达到了完美的程度 因为如果着陆失败的话, 整个火星探测计划就完全失败了, 所以, 完全可以理解工程师们为什么会对相比之下次重要的陆地巡航软件的小问题不那么在意, 只是把简单的重启当作错误处理 问题分析清楚以后, 工程师们用远程升级方法解决了上述问题 防错还是容错 偏重防错的策略, 该策略机制偏重于使用户容易编制无错的程序, 以及出错后如何纠正错误使软件重回正确的轨道, 一旦出现不可修正的错误可能导致严重的后果 偏重容错的策略, 该策略机制偏重于在应用程序出错的情况下隔离出错的程序, 防止错误扩散, 尽量保证系统的其他部分正确运行, 只有出错模块自身不能正确地运行, 或者得不 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 35 页共 409 页

36 到所申请的服务 在通用计算机的操作系统上, 可能更加偏重于容错, 因为桌面系统经常执行很多进程, 由很多用户或者程序同时使用, 一个不守规矩的程序出错时, 其他用户和程序的安全运行全由操作系统来保证, 操作系统自身必需足够健壮, 在这样的系统中, 操作系统自然是整个环境的核心模块, 必需加以仔细保护, 而与保护操作系统相比, 用户程序反而显得没有那么重要了 当一个用户模块出现致命错误时, 操作系统宁可杀死这个模块也不能让错误扩大而影响其他用户的安全, 总之, 安定团结的大局面是最重要的, 对于少数破坏份子, 就一个字 : 杀 所以, 通用操作系统的出错处理可以比较简单, 往往是保护自己第一, 防止多用户间互相干扰第二, 恢复出错的程序第三 再看看嵌入式系统, 虽然操作系统支持多任务, 但往往只有一个用户一个程序在运行, 这个程序虽然被分成多个线程, 但其本质还是只有一个程序在运行, 这个程序就是整个嵌入式系统的全部家当, 如果这个程序被杀死, 那么就算操作系统仍然健壮地运行, 但只有操作系统在运行的计算机是毫无意义的 因此, 嵌入式环境下编程, 确保所有线程正确运行是最重要的, 如果是不太重要的线程出错, 可以把线程杀死再重新建立, 甚至可以直接杀死 ; 如果是核心线程出错, 核心线程是无论如何都不能杀死的, 就算杀死重新创建也不一定能保证正确运行, 故核心线程出错时, 即使操作系统本身运行正常, 也会直接把整个系统重启 事实上, 所有可靠性要求比较高的系统都配备了看门狗电路, 看门狗由于守护核心线程正常工作, 一旦核心线程出现异常, 看门狗就会复位整个系统 如果核心线程出错, 容错将变得毫无意义, 不必等待看门狗, 直接重新启动计算机才是最佳选择 因此, 嵌入式操作系统比桌面系统在这方面有更高的要求, 它不但要保持自身的健壮, 而且处理用户程序 bug 的策略也比桌面系统更加复杂 确定关键模块 关键模块是对产品质量有重大影响的模块, 在系统设计阶段, 应该把该产品的关键模块分解出来, 并且采取特别的措施保证关键模块被正确地实现 有很多设计者有重技术轻应用的倾向, 他们往往会根据技术实现的难度, 把系统中各个模块进行排序, 把最复杂最难实现的模块作为核心模块 ; 许多时候, 操作系统及相关模块会被当成核心模块, 这在大多数情况下是正确的, 因为操作系统崩溃的话将导致所有任务异常 这种分类方法是不对的, 因为嵌入式系统是以开发产品为目标的, 应该从使用者的角度, 把实现产品目标最为关键的部分确定为关键模块 有些系统虽然由很多模块组成, 但其中 1 个或少数几个模块起关键作用, 这些模块可能比操作系统更加重要 这里介绍一种确定关键模块的 cehw 系数法, 系统设计时, 罗列出产品的所有功能模块 ( 从使用角度 ), 分别根据模块的特性确定各模块的 cehw 系数, 各系数大于 0 小于 1, 所有模块的同一个系数加起来等于 1 比如某产品可以分为 5 个模块, 根据市场调查得出用户使用各模块的平均时间比例分别为 0.6,0.2,0.1,0.06,0.04, 则各模块的使用频度 c 也分别就是上述系数, 各模块的 c 系数的总和为 1 使用频度 c, 经常使用的功能模块系数大, 不经常使用的功能系数小 比如移动电话中实现通话功能的模块,c 系数就很大 故障恶感度 e, 把用户对产品使用中出现的故障的反感程度排序, 用户非常反感的故障 e 系数大, 反之 e 系数小 还是移动电话的通话模块为例, 如果正说到关键处, 因手机故障断了线, 你说有多扫兴, 通话 e 系数自然很高 好感度 h, 某功能模块正常使用能获得用户好评, 该功能的微小改进能极大地增加用户的满意度, 则调高本系数, 反之降低本系数 比如在电话查号服务中, 语音报电话号码时是一个一个数字蹦出来的, 如果能实现连续流畅地报号, 用户会感到很 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 36 页共 409 页

37 亲切, 好感度系数 h 就高 危险度 w: 用于衡量一个模块正常与否与生命财产安全的关联程度, 关联度高的系数也高, 反之系数降低 比如汽车的刹车控制模块,w 系数将很大 把某模块上述各系数相加即得到该模块的关键系数, 系数越大说明该模块的关键程度越高, 关键度特别高的模块应该确定为关键模块 就象修房子, 房梁分主梁, 次梁, 墙面分承重墙和间隔墙, 主梁和承重墙需要特别加固, 嵌入式系统设计也是这样, 关键模块的可靠性需要特别关注 从系统设计, 到详细设计, 到代码编写或者电路设计, 再到测试都要进行重点照顾, 这对提高产品的综合素质可以起到事半功倍的效果 cehw 系数应用 电梯控制器设计 本节我们分别用两种方法模拟设计一种电梯控制器模型, 这不是一个真实的产品设计, 只是抽象出来的一个模型, 用它只是为了阐明观点, 可能与真实的电梯控制器相差很远 电梯控制器分轿厢内和楼层控制器以及总控制器, 这里仅以轿厢内控制器为例 我们略过规格和需求定义, 直接进入系统阶段 一般来说, 软件上, 电梯控制器包含以下 5 个模块, 分别是电梯运行调度模块 运行控制模块, 轿厢门开关模块 按键处理模块 紧急制动模块 硬件也包含 5 个模块, 分别是升降电机驱动模块 轿厢门开关驱动模块 按键模块 轿厢超速检测模块 紧急制动驱动模块 非 cehw 设计方案 每种电梯都有紧急制动功能, 当发生意外事故时, 轿厢超速下滑 ( 如钢丝绳折断, 轿顶滑轮脱离, 牵引机蜗轮啮合失灵, 电机下降转速过高等原因 ), 或者乘员按紧急制动按钮时 ( 有些电梯有这个按钮 ) 刹车装置就会立即启动, 通过一系列电子或机械动作, 使轿厢卡在导轨上缓慢下落 这个功能也许在电梯的生命周期内一次都不会遇到, 但一旦发生事故, 就是致命的 即使不使用 cehw 方法, 人们也会想到, 紧急制动功能是非常关键的模块, 需要特别注意 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 37 页共 409 页

38 电梯调度模块 CPU 紧急制动模块 ( 硬件中断 ) 电梯运行模块 轿厢开关模块 人机界面模块 运行电机驱动 轿厢门开关驱动 按键 +LED 显示 轿厢超速检测器 紧急制动机构 图 1-15 不使用 cehw 系数的电梯控制器方案图 1-15 的控制器方案中, 软件被分解为 5 个模块, 各软件模块控制相应的硬件模块, 其中除紧急制动模块外的其他模块在主程序中之行 考虑到轿厢超速检测及紧急制动模块的可靠性要求特别高, 如果此模块出现错误导致紧急制动失败将直接关系到生命安全, 所以本模块由硬件中断单独处理 这样, 即使主程序出现故障处于异常状态, 只要中断寄存器和代码没有被破坏, 紧急制动机构还能正确动作 我们来分析一下这个方案, 方案中, 显然已经考虑到了紧急制动模块的特殊性, 并且做了相应的处理, 使紧急制动模块的可靠性高于系统中其他软硬件模块, 但是仍然存在下列问题, 可能导致紧急制动失败 : 1. 紧急制动功能由软件控制, 该软件模块与其他软件模块在同一个 CPU 上运行, 那么紧急制动模块就有受其他软件影响的可能, 即使紧急制动模块本身没有 bug, 但很难保证整个软件都没有 bug 就算紧急制动模块在单独的中断函数中实现, 其他模块的 bug 一般不会影响到它, 但是如果 bug 错误地修改了中断寄存器, 或者改变了 CPU 的工作状态, 那么紧急制动模块就可能会出错 2. 工业计算系统一般都有看门狗电路, 在看门狗复位其间发生的紧急制动中断将得不到响应 3. CPU 系统的硬件可靠性问题也值得注意 CPU 由于内部结构复杂, 往往是整个计算机系统的可靠性瓶颈 在外界干扰下,CPU 可能出现两种故障, 一种是, 在软件本身没有错误的情况下, 外界干扰可能使 CPU 错误地执行指令, 从而导致软件失效, 在绝大多数情况下, 如果看门狗电路和软件设计合理, 将会由看门狗电路复位整个 CPU 系统从而恢复正常, 但是在从软件失效到复位完成这段时间内, 紧急制动模块将失效 另一种是, 强烈的干扰导致硬件死锁 由于功耗问题, 现代 CPU 大都采用 CMOS 电路, 由于单向可控硅效应,CMOS 电路可能出现死锁的情况, 这种状态下, 要么直接烧毁 CPU, 要么 CPU 进入一种既不执行程序, 也不响应中断和复位, 与软件死机对应, 我们称这个状态为硬件死机 有一个简单的实验, 可 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 38 页共 409 页

39 以让我们切身感受一下干扰使 CPU 硬件发生故障的情况, 用我们手头很容易找到的打火机, 拆下其电火花芯, 在 CPU 附近放几个火花,CPU 很容易就会死机复位, 或者发生硬件死锁 软件死机是可以通过硬件看门狗复位来重新启动程序的, 而硬件死锁只有断电冷启动一条路 电梯工作在工业环境, 且直接控制电机, 电机的火花有点象打火机的火花, 是很严重的干扰源, 电机起动和停止时也有很大的冲击电流, 这都是潜在的严重干扰 紧急制动功能由软件控制, 所以, 它的可靠性不可能高于 CPU 系统硬件可靠性 综上所述, 由于 CPU 以及软件是紧急制动模块的一部分, 我们只有把整个 CPU 硬件系统的可靠性提高到紧急制动模块的可靠性要求, 才能满足紧急制动模块的可靠性需求 而且, 其他软件模块的可靠性也随之提高, 即使其他模块允许一定程度的 bug, 但决不允许存在影响到紧急制动模块 bug cehw 设计方案 表格 1-1 电梯控制器的 cehw 系数表模块名 c 系数 e 系数 h 系数 w 系数关键指数 电梯调度模块运行控制模块轿厢门开关模块人机界面模块紧急制动模块备注 , 如果调度错了楼层, 多么尴尬 , 电梯要 是停在半空 中, 佛祖也 会发火的 忽略 忽略 前 4 个功能 紧急制动功 如果紧急制 轿厢门控制 每次坐电梯 能平时根本 动有故障, 失灵可能会 都需要使 就用不到, 即使没有造 夹伤人, 所 用,c 系数相 就算 正常 成伤害, 也 以分配了一 同 值班, 用户 会造成严重 定的 w 系数 也感觉不到 的心里影响 在 cehw 系数表中, 紧急制动模块的关键指数非常大, 轿厢门开关模块次之, 其他三个模块的关键指数是相同的 因此, 紧急制动功能是电梯控制器的关键模块, 它的关键系数是如此之高, 让我们不得不用特别的手段保证其可靠性 从软件程序员的角度来说, 一个从设计到实现都完全没有缺陷的软件是足够可靠的 ( 姑且不辩论这样的软件是否存在 ), 然而, 嵌入式系统是软硬件结合的产品, 既然软件只是产品中的一个模块而已, 那么,100% 可靠的软件并不等于 100% 可靠的产品, 是的, 任何产品的可靠性都不是由其中单个模块决定的! 由于紧急制动模块的关键指数远高于其他四个模 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 39 页共 409 页

40 块, 如果该模块与其他模块一起用一个 CPU 控制, 势必要求整个 CPU 系统都要达到紧急制动模块的可靠性要求 除了紧急制动软件模块的设计和实现过程要满足紧急制动模块的安全要求外, 还要求在同一个 CPU 上运行的其他软件模块的可靠性达到很高要求, 要求硬件保证 CPU 正确取指令和数据 保证 CPU 正确地执行指令 实际上, 从纯技术角度讲, 紧急制动模块是一个很小的模块, 为了一个小模块的可靠性而把整个系统的可靠性要求升高数个等级, 是否值得呢? 如果把紧急制动模块与其他四个模块分离, 独立实现, 其他四个模块用 CPU 控制, 则这个 CPU 系统的可靠性要求大大降低 降低可靠性要, 伴随的是成本的大幅降低, 开发时间也会大大缩短 紧急制动模块虽然可靠性要求非常高, 但其功能实现方面其实非常简单, 不使用 CPU, 很容易直接用小规模硬件实现 这样的话, 我们只要保证这一小块电路达到高可靠性就可以了 著名的 80/20 原则又一次得到了体现 : 分量只占很小一部分的紧急制动模块的可靠性决定了整个系统的可靠性 其次, 轿厢门开关模块也有较高的关键指数, 它的关键指数较高是因为它比其他模块的危险系数 w 高一些, 如果从机械结构上降低它的危险系数, 那么控制电路部分的关键指数就与其他模块一致了 选择适当的轿厢门开关的电动机功率, 使其在任何情况下都不能输出足以伤人的机械力, 就可以达到控制危险性的目的, 从这一点上讲, 系统设计已经从软硬件结合发展到电子系统与机械控制结合 至此, 我们可以画出按 echw 系数设计的电梯控制器的系统结构图了 轿厢超速检测器 电梯调度模块 CPU 硬件控制逻辑 电梯运行模块 轿厢开关模块 人机界面模块 运行电机驱动 轿厢门开关驱动 按键 +LED 显示 紧急制动机构 图 1-16 根据 echw 系数设计的电梯控制器改进后的设计与原设计相比, 仅仅把紧急制动的控制逻辑从 CPU 软件改为硬件, 但是带来的好处是全方面的 1. 增加了可靠性, 小规模的电路本身比大规模的 CPU 电路具有较高的可靠性, 对于性命悠关的功能, 我们更倾向于使用小规模的电路直接实现 紧急制动模块是系统中可靠性要求最高的模块, 它的可靠性就代表了整个控制器的可靠性, 而用小规模 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 40 页共 409 页

41 电路直接实现具有无可比拟的高可靠性 2. 降低了成本, 与非 echw 方案比,echw 方案增加了硬件, 看起来似乎是增加了成本的, 怎么会降低成本呢? 这里顺便谈谈产品生产的成本因素, 一个产品的成本应该包括生命周期的平均总成本, 它包括物料成本 加工成本 生产调试成本, 安装调试成本 营销成本 运行维护成本 更广义一点说, 还包括由于产品质量问题导致品牌声望下降带来的无形资产损失的成本, 更高的安全性将降低因紧急制动故障造成伤害乘员的可能性, 而这种人身伤害对品牌的打击是致命的 电梯这种产品, 注定是一个工程产品, 他的产量不会很高, 它对原材料的直接成本不敏感, 但是安装和维护费用很高, 对开发 调试 生产的成本更加敏感 而且电子控制部分的成本占材料成本的比例也很低, 用硬件实现紧急制动控制逻辑增加的成本, 几乎可以忽略不计 但是经这样修改, 整个 CPU 系统的可靠性要求却降低了, 这降低了 CPU 选型的要求, 软硬件系统的测试费用也降低了 软件可靠性需求的降低还能大大缩短开发时间, 加快产品研发进度 echw 系数应用 手机通话模块 电梯控制器的特点是其中有一个高度危险性相关的模块, 它的设计是围绕这个使用频度系数 c 非常低而危险性系数 w 非常高的模块展开的 我们再分析一个围绕使用频度展开设计的例子 移动电话 写到这里的时候, 我想起了修手机的经历, 到目前为止, 笔者用过 5 款手机, 其中有两款维修过, 两者的故障很相似, 一个手机是通话过程中会自动关机, 另一个手机经常出现对方听不到我讲话而我能听到对方讲话 应该说明的是, 这两个手机虽然不同品牌, 但都出自全球性的大公司, 牌子又硬又老 两次修手机的经历惊人地相似, 保修中心的服务员态度很好, 效率惊人, 我还没有说完故障现象, 她已经把维修单填好了, 并且很有礼貌地递给我, 说 : 一小时后来取机, 给您带来不便, 抱歉! 可是我还没有说完呢 我还想说下去 不用说了, 我已经清楚了, 谢谢 一样的笑容可掬 毕竟是名牌服务, 让你无可挑剔 低头看, 在处理结果一栏赫然写着 软件升级 维修中心环境很好, 有沙发, 还有报纸看, 而且又没有什么事, 于是就打算在里面看看报纸打发这一个小时的时间 当时保修中心还有几个要求修手机的, 在等待的过程中, 又有一些人进来 出于开发工程师的职业习惯, 我就和待修手机的顾客以及店员聊天, 了解手机的故障分布情况 故障原因中, 有 1/2 是软件 bugs, 升级软件即可, 软件 bugs 中, 有约 60% 是通话问题, 其次是电话本 短消息问题 这就奇怪了, 一般来说, 通话功能是一个不复杂的模块, 与界面显示 游戏等模块的复杂度完全不是一个量级的, 而且从手机问世起, 通话功能就基本没有改变过, 应该是经过了长时间使用验证的模块, 而且是手机中最重要的功能, 怎么会故障最多的功能模块呢? 这些品牌又都有悠久的历史, 应该积累了丰富的经验 俗话说, 不做不错, 做多错多, 上述故障分布正好与用户的使用频度吻合, 用户使用手机时, 当然最主要的是打电话, 其次是翻电话本, 记录电话, 发短消息 从开发工程师的角度, 我们可以得出三个结论 : 1. 故障涉及到多个型号与品牌手机, 这些不同型号和品牌的手机的 bug 都集中在通话模块中是不可能的 而是因为通话功能经常使用, 所以通话模块中 bug 的表现机会最多 2. 手机软件中, 虽然无法得知通话功能是否作为一个独立模块开发, 但可以肯定的是, 通话模块并没有作为核心模块受到特别的重视, 而是与其他模块一视同仁 其可靠 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 41 页共 409 页

42 性比其他模块高主要是因为这个模块比较简单 3. 通话模块的故障会引起用户特别反感, 而且记忆深刻, 对品牌形象的影响非常大 假设我们要设计一款手机, 该手机由通话模块 界面模块 短消息模块 电话本模块以及 WEB 上网模块组成, 我们用 echw 系数法分析一下各模块的重要性排队 表格 1-2 手机的 echw 系数模块名 c 系数 e 系数 h 系数 w 系数关键指数通话模块 忽略 1.8 界面模块 忽略 0.7 短消息模块 忽略 0.19 电话本模块 忽略 0.22 WEB 上网模块 忽略 0.09 备注手机上网往打不了电话往能给人意是多么恼火外惊喜 的事情 由于手机并没有多少危险性, 故 w 系数被忽略 打电话是手机最重要的功能, 故通话模块的关键指数远高于其他模块 ; 除通话模块以外, 其他模块都要依赖于界面模块, 故界面模块也有较高的关键指数 ; 电话号码本功能和短消息模块相差不大, 大约并列第三 ;WEB 上网功能则属于锦上添花的功能 上述排序与人们日常使用电话的习惯是吻合的, 想像一下, 当你正在打一个重要的商务电话, 谈到关键时候断了线, 这时候你会发誓不再买这个牌子的手机, 而如果是浏览器断了线, 你只会抱怨网络不稳定, 然后重新连接, 过几天你就会忘记 因此, 通话功能是手机的生命, 而且通话模块很简单, 与之相比, 操作系统反而是次要的 因此, 任何手机开发人员都不会不重视通话模块, 否则, 这款手机也不太可能与用户见面 通常会把通话模块当作最优先考虑的模块来开发, 往往会安排最有经验的工程师执行通话模块的开发, 而且在软硬件资源分配和测试时优先考虑通话模块 再者, 正如前面所说的, 通话模块自从 GSM 手机问世起就没有改变过, 应该是最成熟且最久经考验的模块, 其本身的 bug 应该会比其他模块少 那么为什么使用中会有那么高的故障率呢, 可能的情况是 : 1. 通话模块被当作重要模块设计, 而且经过多年的验证, 本身的 bug 是比较少的 事实上, 手机通话模块的使用频度是超过 90% 的, 而表现出来的故障率只有 60%, 也说明通话模块的可靠性确实有比较高的可靠性 2. 通话模块虽然已经作为重要模块设计, 但在软硬件系统上, 并没有从系统的角度上使其具有特殊的位置, 当操作系统出错时, 或者其他模块出现严重错误时, 通话模块就有可能被破坏 通话模块是一个并不是很复杂但有特殊重要地位的模块, 但其可靠性要求与上一节提到的电梯紧急制动模块相比, 又要低得多, 而且手机这种消费类产品, 其硬件材料成本是相当敏感的, 而且其节电与体积指标也很重要, 决定了不可能添加独立的硬件来提高手机通话模块的可靠性, 但在软件上, 通过灵活的系统设计, 我们可以把这个模块设计成在其他模块发生致命错误时, 本模块能独善其身 中断就有这样的特性, 如果把通话模块设计在独立于操作系统的中断里, 那么, 中断外的程序包括操作系统崩溃时, 也只有很小的概率会破坏到中断寄存器, 只要中断寄存器不被破坏, 那么通话模块就可以确保无虞 图 1-15 所示的电梯设计方案中紧急制动模块的处理方式, 其实可以用在手机的通话模块设计中 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 42 页共 409 页

43 第 2 章认识内存 我们有时候会碰到这样的问题, 程序在开始时一切正常, 但运行数月后却出现错误, 甚至整体崩溃, 很有可能就是内存丢失或者碎片积累导致内存耗尽造成的 要开发高可靠性的嵌入式产品, 就不得不深入的了解计算机系统的内存管理 由于嵌入式系统的特殊性, 嵌入式系统的内存往往是非常紧凑而且有限的, 不同的应用程序一般没有独立的地址空间, 甚至连操作系统都没有独立的地址空间, 所有的应用程序和操作系统一起挤在一个地址空间中运行, 稍有不慎就会导致整个系统崩溃 而桌面系统不一样, 桌面系统配置有很多物理内存且支持虚拟内存, 且每个进程都有独立的地址空间, 在 32 位机上, 这个空间可达 2G 甚至更大, 发生严重的内存碎片和内存泄漏时, 程序仍然能正常运行, 当程序退出时, 泄漏的内存和碎片都将由操作系统统一收回, 所以, 桌面程序员几乎觉察不到内存限制的存在 随着嵌入式计算的日趋复杂和普及, 对程序员的需求急剧增加, 许多嵌入式程序员是从桌面系统转过来的, 他们习惯了在桌面系统中自由自在的感觉 在嵌入式环境中, 内存管理必需由程序员自己来完成, 内存管理方面的 bug 是最容易发生, 发生后最难定位和排除, 很难通过测试和老化暴露 bug, 甚至会在运行数月至数年以后才暴露出来, 而且一旦发生就是致命的 因此, 内存管理是最具挑战性的工作, 本章讲述嵌入式系统内存使用的基础知识以及 djyos 系统的内存管理 2.1 嵌入式系统的存储设备 嵌入式系统中的存储设备, 按照其使用特点和可以分为以下几类 : 1. 内存映射随机存储器 RAM, 俗称内存, 常见的有 SRAM,SDRAM 等设备, 这些设备可以直接与系统总线相连, 能对 CPU 的读写存储器的指令做出正确的反应 内存的访问速度最快, 但断电后数据立即消失, 上电后的数据是随机的 内存可以运行程序, 但是运行程序之前必须先把代码和数据从 rom 中 copy 到内存中 可以用来存储变量 栈, 可以动态分配 (molloc) 给用户使用, 是嵌入式系统的内存管理的对象 2. 设备式随机存储器, 最常见的是包含在串行访问的 RTC( 实时时钟芯片 ) 内或者 MCU 监控芯片内的 RAM 这类存储器的内部存储阵列的组织也许与内存是一致的, 但接口比较复杂, 它不能直接挂在系统总线上,CPU 访问的时候, 不能直接用访问存储器的指令进行读写, 不能执行程序 这种存储器通常用在 MCU 没有外部总线接口而又需要扩展少量内存的应用, 比如是利用 RTC 将你的 RAM 实现掉电保存 3. cache, 就是高速内存构成的一小块存储器, 它的体积比主存小, 但速度很快, 可以直接与 CPU 的速度匹配 硬件以一定的算法把 CPU 早先访问过的数据暂存在 cache 中,CPU 再次访问相同的内存地址时, 就直接访问 cache, 减少等待慢速存储器的时间, 提高整个系统的运行速度 cache 相对软件来说是透明的, 也就是说, 指令不能直接寻址 cache, 也 看不见 cache 的存在 cache 的存在与当今电子制造工艺特点有关,CPU 运行速度可以做得很高, 而且软件需要大量的内存, 如果把所有内存的速度都制造成与 CPU 匹配的话, 成本和功耗势必很高, 体积也很大, 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 43 页共 409 页

44 而一定数量的 cache 再配以高效的 cache 命中算法, 系统的实际速度可以接近全高速内存的速度, 而成本和功耗和体积则可以降低很多 4. BROM(Bus ROM) 是直接挂在 CPU 的总线上,CPU 可以像读内存一样读写的固态存储器, 可以执行程序, 掉电内容不丢失, 但读 BROM 的速度一般会比读内存慢许多 BROM 分为可写类型和不可写入类型,flash 是典型的可写 BROM, 工厂掩模的 ROM 则是典型的不可写入 BROM 即使是可写的 BROM, 也不能像内存一样随机写入, 而是要经过一系列复杂的操作才能实现写入, 而且写入的速度也很慢 所以,BROM 里的数据不会被不经意的软件误操作改写, 程序在 BROM 里执行会比在内存中安全一些, 但缺乏灵活性, 执行速度也可能会慢一些 有很多为嵌入式用途设计的 CPU, 内嵌了一定数量的 flash 和 RAM, 而且由于 ram 的数量很少, 程序一般都不 copy 到 ram 而是直接在 flash 中运行 需要一些技巧来解决慢速存储器与快速 CPU 的矛盾, 不同的芯片商有不同的做法, 嵌入式系统设计师要仔细阅读相关资料 philips 的 LPC 系列处理器, 使用 128 位的 flash 接口宽度配合指令预取 ; 比如 Ti 的 TMS320F28x 系列 DSP 的 flash 访问速度仅为 36nS, 只能把性能关键的代码和数据 copy 到 ram 中执行 5. 设备式固态存储器, 我们称之为 DROM(Device ROM), 例如 nand flash, 磁盘等 DROM 与 BROM 的不同之处在于 DROM 不是直接挂在 CPU 总线上,CPU 不能象读内存一样读 DROM, 因此不能在 DROM 中执行程序 DROM 一般用于用少量的 IO 引脚扩展固态存储空间, 比如 IIC 总线的 EEPROM, 或者用有限的寻址空间扩展海量固态存储空间, 比如 nand flash, 只占用 2 个地址, 但可以扩展几百兆的存储空间 内存和 BROM 是所有计算机系统都有的, 系统上电后, 最初的一段代码必定在 BROM 中执行, 有的嵌入式系统程序始终在 BROM 中执行, 有些则在完成一系列初始化工作后, 把代码 copy 到内存中, 然后在内存中运行 而 DROM 和 cache 并不是所有嵌入式系统都有的, 主频在数十 Mhz 以内的系统往往没有 cache 也有一些 CPU 内部集成了 nand flash 硬件管理器, 使其能够象访问 BROM 那样访问 nand flash 部分存储空间, 例如三星的 ARM9 系列的 S3C2410, 它可以象 BROM 一样访问 nand flash 的前 4K, 从而可以不配备 BROM 按照程序运行前和运行时代码和数据在存储器中保存的方式, 表格 2-1 列出了嵌入式系统的几种常见的存储模式 由于嵌入式系统存储器配置多种多样, 在此不能一一尽列, 不尽之处, 读者应根据自己的实际存储器配置灵活分析 表格 2-1 嵌入式系统存储模式代码全部在 BROM 中执行的模式特点 : 系统只配备了 BROM 和内存, 且内存很小, 不适宜用来执行代码 未配备 DROM( 例如 IIC 总线的 flash), 或 DROM 只作为存储数据 初始化代码其他代常数表格初始化的未初始化局部变量码全局变量的的全局变量启动前保存在 BROM BROM 中 BROM 中无无 BROM 中的中复位向量处启动过程执行代码无操作无操作拷贝到内内存区域无操作存中清零执行时 BROM 中, BROM BROM 中, 内存中内存中内存 ( 栈 ) 地址不变中, 地址地址不变中 版权所有, 转载必须注明出处, 注明 : 来自 字样 第 44 页共 409 页