对比精灵和GPU及HMI建模方法

创建新的小型嵌入式显示器的嵌入式开发人员在图形处理单元 （GPU） 之外还可以考虑另一种选择。基于 Sprite 的芯片已在汽车应用中占据一席之地。这些显示控制器以类似于幻灯片放映的方式提供图形图像的无渲染操作。为了帮助寻求解决这一设计困境的工程师，Altia 提供了一套指南，可以帮助他们在这两个选项之间做出明智的决定。

重要的是要澄清 Altia 没有义务或议程来支持这两种机制。该公司与任何半导体公司或技术无关，其工具也不受限于一种操作系统。这些工具在每种解决方案中都得到了验证，因为公司正在将 Altia 生成的图形代码用于基于 sprite 的芯片和 GPU 上的生产。因此，本次讨论的目的是帮助设计人员在他们的产品中运行最佳人机界面 （HMI），并为其应用程序提供最佳机制。

让我们从一张图表开始——图 1 中精灵与 GPU 的图形对比——并进一步探索细节。

图 1：在为小型嵌入式显示器制定硬件决策时，设计人员必须考虑整个系统的特性——屏幕分辨率、图形复杂性、字体灵活性和颜色深度——以及 BOM 成本和规范稳定性等项目限制。

Sprites：更简单，但需要规划

sprite 选项适用于低端显示产品，并迅速成为 GPU 的替代品。那么基于 sprite 的显示控制器何时能成功适配 HMI？

当 HMI 由明确指定的静态图像组成时，Sprite 是一个很好的解决方案。规范应提前定义，以便设计人员在开发开始之前了解在 HMI 中以图形方式实现的内容。视觉和文本信息的 Z 排序不应该有很大的复杂性。Sprite 芯片在分辨率较低的显示器上表现最佳。这些显示控制器不能方便地处理文本，通常会施加限制，例如每个精灵一个字符或每个精灵一个单一颜色的文本。如果设计使用受限的物料清单 （BOM），那么 sprite 芯片是一个不错的选择。它们并不总是需要额外的支持芯片，如外部 RAM 或闪存，并且可以在最少使用内部资源的情况下运行。

这种新的硬件选项并非没有挑战。在这一点上，精灵芯片不能轻易地支持高分辨率显示器或低分辨率显示器上的高色深。随着精灵功能集成到显示控制器单元 （DCU） 中，内存带宽成为精灵芯片的限制因素。每次一帧输出到显示器时，DCU 都会不断地访问所有可见精灵的图形内存。必须注意确保 HMI 不会因重叠过多图形对象而违反带宽限制，否则会出现显示故障。

复杂的层次

目前，如果在项目开始时对 HMI 设计不够了解，那么 sprite 芯片是一个冒险的选择。这是因为一旦在芯片上实现 HMI 图形设计，就需要改变其相关的高成本。基于 Sprite 的芯片使用层的概念来表示单个图像（或 sprite）。在 HMI 中构建任何屏幕都需要将所有图像和文本放入这些层中，并按照设计者希望它们出现在显示器上的方式定位这些层。图形的 Z 顺序由图层的 Z 顺序决定。这是特定于设备的，通常在分配层后无法更改。因此，第 1 层将始终出现在第 2 层之上，依此类推。这仅在两层相交时才重要。交点由 （x，

使图层内容的布局和组织按需要显示需要深思熟虑。在层数有限的零件上，可以想象定义层内容和排序以使图像以某种方式出现的复杂性。图层排列的后期更改可能会对所有图层的内容产生严重影响，甚至是不相关屏幕上的图层。因此，精灵芯片的成功需要前期设计。图片和文字必须经过精心策划和安排。如果 HMI 设计需要灵活性，那么返工时间和成本就会变得昂贵。

应该注意的是，尽管 sprite 芯片是无渲染的，但可能需要一些渲染才能在芯片施加的约束内工作。一个例子是精灵芯片允许的精灵（层）的数量。当显示每个文本字符占用单个精灵的文本时，总精灵计数较低的芯片将受到限制。这样的芯片需要将单个文本字符组合或渲染到单个内存块中，该内存块可以显示为单个精灵。如果设备允许，渲染操作可以使用硬件资源（如 DMA 引擎）来完成。

GPU：灵活且强大，但更复杂

sprite 芯片的替代方案是 GPU，这是一种经过验证的解决方案，在生产中运行了广泛的样本。这种成熟且得到良好支持的技术在开发过程中提供了巨大的灵活性。

GPU 具有重要的优势，使其成为特定应用程序的明显选择。与 sprite 芯片不同，内存带宽限制不会导致显示失败，因为 GPU 与 DCU 是分开的。与精灵芯片相比，这允许更高的显示分辨率和颜色深度。关于图层组合和混合的限制很少。设计师可以更加灵活地处理文本，并可以在 GPU 上渲染更复杂的动画。当 HMI 规范不稳定时，这是一个很好的解决方案。GPU 的层数更少，从而降低了构建 HMI 时的复杂性。

更多关于引擎的资源

GPU 需要 BOM 具有一定的灵活性，因为这种解决方案显然比 sprite 更昂贵，尤其是考虑到它可能需要额外的外部 RAM 和闪存时。GPU 通常与系统级芯片 （SoC） 耦合，其主机处理器比通常使用基于 sprite 的显示解决方案更强大。When opting for a separate GPU and host processor， increased complexity is introduced in the board layout.

GPU 提出了一系列独特的挑战。首先，总成本是一个明确的考虑因素，尤其是在计算多个芯片、电路板空间和 PCB 布局复杂性时。由于 GPU 可以通过更大的文本和字体控制图像支持更深的颜色深度，因此内存消耗有爆炸式增长的趋势。一旦图像内存量变得太大，图像压缩就开始成为一种约束。设计人员需要处理图像压缩、解压缩以及相关的成本和性能问题，这意味着更多的复杂性和权衡。最后，GPU 编程的可变性仍然是一个问题。

尽管讨论了“开放”——OpenGL 和 OpenVG——标准在整个行业中的实施方式并不相同。驱动因素差异很大，不同的半导体公司优化方式也不同。因此，为特定平台获得优化的性能仍然需要一些定制。

建模和生成代码得到回报

考虑到底层图形引擎和手头编程任务的权衡，问题仍然存在：设计师如何获得成功的 HMI 设计？基于模型的开发是通往最高效和最有效的 HMI 的途径。

基于模型的开发在哪些方面影响了日常工程工作？传统的开发过程包括花费时间定义自然语言需求，然后是痛苦且昂贵的手动翻译步骤，以根据这种自然语言需求创建软件设计和实现。当引入基于模型的工程环境时，需求过程会更加高效，因为创建了复杂 HMI 行为的可执行模型。图 2 显示了基于模型的环境的概述。

图 2：通过基于模型的开发流程，团队可以围绕所需系统的详细表示进行更有效的协作，并且其所有预期行为都完好无损。

可以表示 HMI 行为的模型不仅可以比编写自然语言文档更快地完成，而且还可以描述几乎不可能在基于文本的文档中有效定义的图形行为。这些可执行规范可以作为需求模型作为基线，然后作为初始软件设计，然后针对嵌入式目标性能和限制进行改进。然后，使用 Altia DeepScreen 等产品，可以从这个完善的可执行模型中自动生成嵌入式实现。设计人员根据需求细化构建的模型，然后为其自动生成可嵌入代码，从而大大减少了开发工作量。

基于模型的开发，尤其是与图形代码生成器配合使用时，可以灵活地创建一次图形模型，然后为多个图形平台生成代码。这使设计人员可以在各种平台上试用它，直到找到适合应用程序的产品。在选择硬件时，无论是精灵还是 GPU，基于模型的开发为实现硬件和 HMI 的成功组合提供了可靠的方法。

作者：Peter Abowd ，Jim Mikola

审核编辑：郭婷