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