具有重大硬件更改的嵌入式项目的开发过程

Question

我对敏捷开发过程有一个很好的了解，但是我没有ieda，但是我不知道如何将它映射到一个具有重要硬件变化的嵌入式项目中。

我将在下面描述我们目前正在做的事情(临时方式，还没有定义的过程)。这些更改分为三类，每一种都使用不同的过程：

1. 完全硬件更改

示例:使用不同的视频编解码IP

a)研究新的知识产权

( b) RTL/FPGA仿真

c)实现遗留接口-转到b)

( d)等到硬件(磁带输出)准备就绪

f)对实际hardware

• hardware改进的检验

通过改进底层算法来提高图像显示质量。

( a) RTL/FPGA仿真

( b)等待硬件和硬件测试

• 的小改动

示例:只更改硬件寄存器映射

( a)等待硬件并在硬件上进行测试

令人担忧的是，我们似乎对软件成熟度没有太多的控制和信心来应对硬件的变化。这种信心对于项目的成功至关重要，因为提升计划总是非常紧，客户在更新到新版本的硬件时希望有一个无缝的更改。

你是如何管理这种硬件改变的？你是通过硬件抽象层(HAL)来解决这个问题的吗？你对HAL层进行了自动测试吗？HAL适用于成熟的产品，但对于快速变化的消费品来说可能不太好。当硬件平台还没有准备好的时候，你是如何测试的呢？对于这种改变，你有详细的记录过程吗？

Answer 1

添加硬件抽象层(HAL)是必须的，如果您期望底层硬件在产品的生命周期中发生更改。如果操作正确，则可以为HAL的两侧创建单元测试。

例如，HAL只是从GUI到实际显示硬件的一个API。您可以编写一个不驱动物理设备的假硬件驱动程序，但可以以不同的方式进行响应，以验证您的上层API层是否处理了HAL中所有可能的响应代码。也许它会在内存中创建一个位图(而不是驱动外部I/O)，您可以将其与预期的位图进行比较，以确定它是否正确地呈现。

同样，您可以编写一个单元测试，从上层提供良好的HAL覆盖范围，这样您就可以验证新的硬件驱动程序是否正确响应。使用显示示例，您可以遍历所有可能的屏幕模式、界面元素、滚动方法等。不幸的是，对于该测试，您需要物理地观察显示，但您可以与旧硬件并行运行，以查看速度的提高或行为上的偏差。

不过，回到你的例子。切换到另一个视频编解码器有什么不同？你仍然只是在你的上层推字节。如果您正在实现一个已知的编解码器，那么让源文件充当单元测试(涵盖所有可能的数据格式)以确保您的编解码器解码和正确显示它们(不会崩溃！)将是很有帮助的。对内存中的位图进行解码是一个很好的单元测试--与原始解压缩帧相比，您可以只做一个内存。

我希望这能帮上忙。如果没有，问更多的问题。