我对敏捷开发过程有一个很好的想法，但我不知道如何将其映射到具有重大硬件更改的嵌入式项目。
我将在下面描述我们目前正在做什么（Ad-hoc方式，尚未定义过程）。这些变化分为三类，每种变化使用不同的过程：
完成硬件更改
示例：使用不同的视频编解码器IP
a）研究新的IP
b）RTL / FPGA仿真
c）实施旧版界面 - 转到b）
d）等到硬件（磁带输出）准备就绪
f）在真实硬件上进行测试
硬件改进
示例：通过改进基础算法来提高图像显示质量
a）RTL / FPGA仿真
b）等到硬件和硬件测试
轻微改变
示例：仅更改硬件寄存器映射
a）等到硬件和硬件测试
担心的是，我们似乎对硬件变化的软件成熟度没有太多的控制和信心。这种信心对于项目的成功至关重要，因为启动时间表总是非常紧张，客户在更新到新版本的硬件时需要无缝更改。
您是如何管理此类硬件更改的？你有没有通过硬件抽象层（HAL）解决这个问题？您是否对HAL层进行了自动测试？ HAL适用于成熟产品，但对于快速变化的消费产品可能效果不佳。你是如何测试硬件平台何时没有准备好的？对于这种变化，您是否有详细记录的流程？
答案 0 :(得分：3)
如果您希望底层硬件在产品生命周期内发生变化，则必须添加硬件抽象层（HAL）。如果操作正确，您可以为HAL的两面创建单元测试。
例如，HAL只是从GUI到实际显示硬件的API。您可以编写一个不驱动物理设备的虚假硬件驱动程序，但以不同方式响应以验证您的上层API层是否处理来自HAL的所有可能响应代码。也许它会在内存中创建一个位图（而不是驱动外部I / O），您可以将其与预期的位图进行比较，看看它是否正确呈现。
同样，您可以编写一个单元测试，从上层提供良好的HAL覆盖，这样您就可以验证新硬件驱动程序是否正确响应。使用显示示例，您可以循环浏览所有可能的屏幕模式，界面元素，滚动方法等。不幸的是，对于该测试，您需要物理地观看显示，但是您可以与旧硬件并行运行。看速度改善或行为偏差。
回到你的例子。切换到另一个视频编解码器有何不同？你仍然只是在你的上层推动字节。如果您正在实现一个已知的编解码器，那么将源文件作为单元测试（涵盖各种可能的数据格式）将是有帮助的，以确保您的编解码器解码并正确显示它们（不会崩溃！）。对内存中的位图进行解码可以进行良好的单元测试 - 您可以将内存与原始解压缩帧进行比较。
我希望有所帮助。如果没有，请提出更多问题。