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