具有重大硬件变更的嵌入式项目的开发流程
我对敏捷开发过程有一个很好的想法，但我不知道如何将其映射到具有重大硬件更改的嵌入式项目。
我将在下面描述我们目前正在做的事情（临时方式，尚未定义流程）。更改分为三类，每一类都使用不同的流程：
完整的硬件更改
示例：使用不同的视频编解码器 IP
a) 研究新 IP
b) RTL/FPGA 仿真
c) 实现旧接口 - 转到 b)
d) 等待硬件（流片）准备就绪
f) 在真实硬件上进行测试
硬件改进
示例：通过改进底层算法来提升图像显示质量
a) RTL/FPGA 仿真
b) 等待硬件并在硬件上进行测试
小改动
示例：仅更改硬件寄存器映射
a) 等待硬件并在硬件上进行测试
令人担忧的是，我们似乎没有太多控制权，并且对硬件变化的软件成熟度的信心。这种信心对于项目的成功至关重要，因为启动时间表总是非常紧张，并且客户希望在更新到新版本的硬件时能够实现无缝更改。
您是如何管理这种硬件变更的？您是否通过硬件抽象层 (HAL) 解决了这个问题？你有HAL层的自动测试吗？ HAL 适用于成熟产品，但可能不适用于快速变化的消费产品。当硬件平台还没有准备好时，你是如何测试的？您是否有针对此类变更的详细记录的流程？
I have a good idea about Agile development process but I have no ieda how to map that to a embedded project with significant hardware changes.
I will describe below what we are currently doing (Ad-hoc way, no defined process yet). The changes are divided into three categories and different processes are used for each of them:
complete hardware change
example : use a different video codec IP
a) Study the new IP
b) RTL/FPGA simulation
c) Implement the legacy interface - go to b)
d) Wait until hardware (tape out) is ready
f) Test on the real hardware
hardware improvement
example : enhance the image display quality by improving the underlying algorithm
a) RTL/FPGA simulation
b) Wait until hardware and test on the hardware
Minor change
example : only change hardware register mapping
a) Wait until hardware and test on the hardware
The worry is it seems we don't have too much control and confidence about software maturity for the hardware changes. This confidence is critical for the project success , as the bring-up schedule is always very tight and the customer desired a seamless change when updating to a new version of hardware.
How did you manage this kind of hardware change? Did you solve that by a Hardware Abstraction Layer (HAL)? Did you have a automatic test for the HAL layer? HAL works for a matural product but it might not works well for a consumer product that change rapidly. How did you test when the hardware platform is not even ready? Do you have well-documented processes for this kind of change?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您希望底层硬件在产品的生命周期内发生变化，则必须添加硬件抽象层 (HAL)。如果操作正确，您可以为 HAL 的两侧创建单元测试。
例如，HAL 只是从 GUI 到实际显示硬件的 API。您可以编写一个假硬件驱动程序，它不驱动物理设备，但以不同的方式响应，以验证您的上层 API 层是否处理来自 HAL 的所有可能的响应代码。也许它会在内存中创建一个位图（而不是驱动外部 I/O），您可以将其与预期的位图进行比较，以查看它是否正确渲染。
同样，您可以编写一个单元测试，从上层提供 HAL 的良好覆盖，以便您可以验证新的硬件驱动程序是否正确响应。使用显示示例，您可以循环浏览所有可能的屏幕模式、界面元素、滚动方法等。不幸的是，对于该测试，您需要亲自观看显示，但您可以与旧硬件并排运行查看速度改进或行为偏差。
不过，回到你的例子。切换到其他视频编解码器有何不同？您仍然只是在上层推送字节。如果您正在实现一个已知的编解码器，那么拥有充当单元测试（涵盖所有可能的数据格式）的源文件会很有帮助，以确保您的编解码器正确解码和显示它们（不会崩溃！）。解码为内存中的位图可以进行良好的单元测试——您可以将内存与原始解压缩帧进行比较。
我希望这有帮助。如果没有，请提出更多问题。
Adding a Hardware Abstraction Layer (HAL) is a must if you expect the underlying hardware to change during the lifetime of the product. If done correctly, you can create unit tests for both sides of the HAL.
For example, the HAL is simply an API from your GUI to the actual display hardware. You can write a fake hardware driver that doesn't drive a physical device, but responds in different ways to verify that your upper API layers handle all possible response codes from the HAL. Maybe it creates a bitmap in memory (instead of driving external I/O) that you can compare to an expected bitmap to see if it's rendering correctly.
Likewise, you can write a unit test that provides good coverage of the HAL from the upper layers, so you can verify that your new hardware driver is responding correctly. Using the display example, you cycle through all possible screen modes, interface elements, scrolling methods, etc. Unfortunately, for that test you'll need to physically watch the display, but you can potentially run side-by-side with old hardware to see speed improvements or deviations in behavior.
Back to your example, though. How different is switching to another video codec? You're still just pushing bytes around at your upper layers. If you're implementing a known codec, it would be helpful to have source files that act as a unit test (covering a full range of possible data formats) to ensure that your codec decodes and displays them correctly (without crashing!). Decoding to a bitmap in memory makes for a good unit test -- you can just do a memory compare to a raw decompressed frame.
I hope that helps. If not, ask more questions.