目标硬件的瓶颈
目标硬件
产品代码最终运行的硬件载体
目标硬件的瓶颈
软件只能在目标硬件上运行，将面临一些瓶颈：
- 硬件就绪后于软件开发，推迟了软件测试；
- 目标硬件本身需要调试验证，叠加软件的调试验证，调试验证困难度增加；
- 系统的构建和上传普遍漫长
那如何解决硬件瓶颈问题呢？
- 传统手段：开发板
可以解决项目早期硬件未到位及部分调试验证问题，但未解决系统构建上传漫长等问题； - 更为有效的手段：双目标开发
双目标开发
- 双目标：目标硬件、开发系统
- 代码从第一天就设计成至少在两个平台上运行
双目标好处：
- 硬件就绪之前就能测试代码
- 避免硬件和软件同时调试
- 帮助设计
- 更关注软硬件的边界，软硬件解耦
- 快速移植到新硬件，自动化单元测试验证
双目标测试的风险：
- 编译特性、语言特性不同
- 基本数据类型可能不同
- 字节序及数据结构对齐可能不同
如何降低双目标测试风险？
开发系统尽量选用与目标硬件相同的编译、语言、数据类型、字节序及对齐等
嵌入式的TDD循环
-
平台1： TDD微循环
- 写通用软件
- 隔离硬件和软件
- 频繁运行
-
平台2： 目标编译器兼容性检查
- 每次采用新的语言特性时编译
- 这可以提醒你一些移植性问题，比如有些头文件没有、不兼容的或者缺失的语言特性。
-
平台3： 评估板上运行单元测试
- 一直保持在评估板上运行的能力
- 前期可用于评估在目标硬件上的效果
- 后期可用于排除目标硬件可疑行为
-
平台4：在目标硬件上运行单元测试
- 若内存不能一次性装入所有测试，可以分割成多组测试套件，分批装入测试
-
平台5： 在目标硬件上运行验收测试
- 手工测试不能完全被自动化的依赖于硬件的代码
双目标的不兼容性
如何处理与平台相关的不兼容性？
- 共用接口、独立实现（共用头文件、分平台独立目录及源文件）
- 每个平台有一个目录保存与平台相关的代码
- 利用编译器和链接器
和硬件一起测试
和硬件一起的测试应该自动化
3种可能的硬件测试：
- 自动化硬件测试
- 部分自动化硬件测试
- 有效地最小化依赖于硬件的代码，并手工测试
- 利用外部设备的自动化硬件测试
外部设备对目标系统进行一些输入，测试目标硬件的输出是否符合预期。
比如LED硬件亮灭可能需要人工的半自动化测试，若有外部工具可以对其LED控制，并有相应LED效果的捕获手段即可完成全自动化的测试。
