目标硬件的瓶颈

目标硬件

产品代码最终运行的硬件载体

目标硬件的瓶颈

软件只能在目标硬件上运行，将面临一些瓶颈：

• 硬件就绪后于软件开发，推迟了软件测试；
• 目标硬件本身需要调试验证，叠加软件的调试验证，调试验证困难度增加；
• 系统的构建和上传普遍漫长

那如何解决硬件瓶颈问题呢？

• 传统手段：开发板
  可以解决项目早期硬件未到位及部分调试验证问题，但未解决系统构建上传漫长等问题；
• 更为有效的手段：双目标开发

双目标开发

• 双目标：目标硬件、开发系统
  • 代码从第一天就设计成至少在两个平台上运行

双目标好处：

• 硬件就绪之前就能测试代码
• 避免硬件和软件同时调试
• 帮助设计
  • 更关注软硬件的边界，软硬件解耦
• 快速移植到新硬件，自动化单元测试验证

双目标测试的风险：

• 编译特性、语言特性不同
• 基本数据类型可能不同
• 字节序及数据结构对齐可能不同

如何降低双目标测试风险？

开发系统尽量选用与目标硬件相同的编译、语言、数据类型、字节序及对齐等

嵌入式的TDD循环

• 平台1： TDD微循环
  • 写通用软件
  • 隔离硬件和软件
  • 频繁运行
• 平台2： 目标编译器兼容性检查
  • 每次采用新的语言特性时编译
  • 这可以提醒你一些移植性问题，比如有些头文件没有、不兼容的或者缺失的语言特性。
• 平台3： 评估板上运行单元测试
  • 一直保持在评估板上运行的能力
  • 前期可用于评估在目标硬件上的效果
  • 后期可用于排除目标硬件可疑行为
• 平台4：在目标硬件上运行单元测试
  • 若内存不能一次性装入所有测试，可以分割成多组测试套件，分批装入测试
• 平台5： 在目标硬件上运行验收测试
  • 手工测试不能完全被自动化的依赖于硬件的代码

双目标的不兼容性

如何处理与平台相关的不兼容性？

• 共用接口、独立实现（共用头文件、分平台独立目录及源文件）
• 每个平台有一个目录保存与平台相关的代码
• 利用编译器和链接器

和硬件一起测试

和硬件一起的测试应该自动化
3种可能的硬件测试：

• 自动化硬件测试
• 部分自动化硬件测试
  • 有效地最小化依赖于硬件的代码，并手工测试
• 利用外部设备的自动化硬件测试
  外部设备对目标系统进行一些输入，测试目标硬件的输出是否符合预期。
  比如LED硬件亮灭可能需要人工的半自动化测试，若有外部工具可以对其LED控制，并有相应LED效果的捕获手段即可完成全自动化的测试。