創(chuàng)建新的小型嵌入式顯示器的嵌入式開發(fā)人員在圖形處理單元 （GPU） 之外還可以考慮另一種選擇?；?Sprite 的芯片已在汽車應用中占據(jù)一席之地。這些顯示控制器以類似于幻燈片放映的方式提供圖形圖像的無渲染操作。為了幫助尋求解決這一設(shè)計困境的工程師，Altia 提供了一套指南，可以幫助他們在這兩個選項之間做出明智的決定。

重要的是要澄清 Altia 沒有義務或議程來支持這兩種機制。該公司與任何半導體公司或技術(shù)無關(guān)，其工具也不受限于一種操作系統(tǒng)。這些工具在每種解決方案中都得到了驗證，因為公司正在將 Altia 生成的圖形代碼用于基于 sprite 的芯片和 GPU 上的生產(chǎn)。因此，本次討論的目的是幫助設(shè)計人員在他們的產(chǎn)品中運行最佳人機界面 （HMI），并為其應用程序提供最佳機制。

讓我們從一張圖表開始——圖 1 中精靈與 GPU 的圖形對比——并進一步探索細節(jié)。

圖 1：在為小型嵌入式顯示器制定硬件決策時，設(shè)計人員必須考慮整個系統(tǒng)的特性——屏幕分辨率、圖形復雜性、字體靈活性和顏色深度——以及 BOM 成本和規(guī)范穩(wěn)定性等項目限制。

Sprites：更簡單，但需要規(guī)劃

sprite 選項適用于低端顯示產(chǎn)品，并迅速成為 GPU 的替代品。那么基于 sprite 的顯示控制器何時能成功適配 HMI？

當 HMI 由明確指定的靜態(tài)圖像組成時，Sprite 是一個很好的解決方案。規(guī)范應提前定義，以便設(shè)計人員在開發(fā)開始之前了解在 HMI 中以圖形方式實現(xiàn)的內(nèi)容。視覺和文本信息的 Z 排序不應該有很大的復雜性。Sprite 芯片在分辨率較低的顯示器上表現(xiàn)最佳。這些顯示控制器不能方便地處理文本，通常會施加限制，例如每個精靈一個字符或每個精靈一個單一顏色的文本。如果設(shè)計使用受限的物料清單 （BOM），那么 sprite 芯片是一個不錯的選擇。它們并不總是需要額外的支持芯片，如外部 RAM 或閃存，并且可以在最少使用內(nèi)部資源的情況下運行。

這種新的硬件選項并非沒有挑戰(zhàn)。在這一點上，精靈芯片不能輕易地支持高分辨率顯示器或低分辨率顯示器上的高色深。隨著精靈功能集成到顯示控制器單元 （DCU） 中，內(nèi)存帶寬成為精靈芯片的限制因素。每次一幀輸出到顯示器時，DCU 都會不斷地訪問所有可見精靈的圖形內(nèi)存。必須注意確保 HMI 不會因重疊過多圖形對象而違反帶寬限制，否則會出現(xiàn)顯示故障。

復雜的層次

目前，如果在項目開始時對 HMI 設(shè)計不夠了解，那么 sprite 芯片是一個冒險的選擇。這是因為一旦在芯片上實現(xiàn) HMI 圖形設(shè)計，就需要改變其相關(guān)的高成本?；?Sprite 的芯片使用層的概念來表示單個圖像（或 sprite）。在 HMI 中構(gòu)建任何屏幕都需要將所有圖像和文本放入這些層中，并按照設(shè)計者希望它們出現(xiàn)在顯示器上的方式定位這些層。圖形的 Z 順序由圖層的 Z 順序決定。這是特定于設(shè)備的，通常在分配層后無法更改。因此，第 1 層將始終出現(xiàn)在第 2 層之上，依此類推。這僅在兩層相交時才重要。交點由 （x，

使圖層內(nèi)容的布局和組織按需要顯示需要深思熟慮。在層數(shù)有限的零件上，可以想象定義層內(nèi)容和排序以使圖像以某種方式出現(xiàn)的復雜性。圖層排列的后期更改可能會對所有圖層的內(nèi)容產(chǎn)生嚴重影響，甚至是不相關(guān)屏幕上的圖層。因此，精靈芯片的成功需要前期設(shè)計。圖片和文字必須經(jīng)過精心策劃和安排。如果 HMI 設(shè)計需要靈活性，那么返工時間和成本就會變得昂貴。

應該注意的是，盡管 sprite 芯片是無渲染的，但可能需要一些渲染才能在芯片施加的約束內(nèi)工作。一個例子是精靈芯片允許的精靈（層）的數(shù)量。當顯示每個文本字符占用單個精靈的文本時，總精靈計數(shù)較低的芯片將受到限制。這樣的芯片需要將單個文本字符組合或渲染到單個內(nèi)存塊中，該內(nèi)存塊可以顯示為單個精靈。如果設(shè)備允許，渲染操作可以使用硬件資源（如 DMA 引擎）來完成。

GPU：靈活且強大，但更復雜

sprite 芯片的替代方案是 GPU，這是一種經(jīng)過驗證的解決方案，在生產(chǎn)中運行了廣泛的樣本。這種成熟且得到良好支持的技術(shù)在開發(fā)過程中提供了巨大的靈活性。

GPU 具有重要的優(yōu)勢，使其成為特定應用程序的明顯選擇。與 sprite 芯片不同，內(nèi)存帶寬限制不會導致顯示失敗，因為 GPU 與 DCU 是分開的。與精靈芯片相比，這允許更高的顯示分辨率和顏色深度。關(guān)于圖層組合和混合的限制很少。設(shè)計師可以更加靈活地處理文本，并可以在 GPU 上渲染更復雜的動畫。當 HMI 規(guī)范不穩(wěn)定時，這是一個很好的解決方案。GPU 的層數(shù)更少，從而降低了構(gòu)建 HMI 時的復雜性。

更多關(guān)于引擎的資源

GPU 需要 BOM 具有一定的靈活性，因為這種解決方案顯然比 sprite 更昂貴，尤其是考慮到它可能需要額外的外部 RAM 和閃存時。GPU 通常與系統(tǒng)級芯片 （SoC） 耦合，其主機處理器比通常使用基于 sprite 的顯示解決方案更強大。When opting for a separate GPU and host processor， increased complexity is introduced in the board layout.

GPU 提出了一系列獨特的挑戰(zhàn)。首先，總成本是一個明確的考慮因素，尤其是在計算多個芯片、電路板空間和 PCB 布局復雜性時。由于 GPU 可以通過更大的文本和字體控制圖像支持更深的顏色深度，因此內(nèi)存消耗有爆炸式增長的趨勢。一旦圖像內(nèi)存量變得太大，圖像壓縮就開始成為一種約束。設(shè)計人員需要處理圖像壓縮、解壓縮以及相關(guān)的成本和性能問題，這意味著更多的復雜性和權(quán)衡。最后，GPU 編程的可變性仍然是一個問題。

盡管討論了“開放”——OpenGL 和 OpenVG——標準在整個行業(yè)中的實施方式并不相同。驅(qū)動因素差異很大，不同的半導體公司優(yōu)化方式也不同。因此，為特定平臺獲得優(yōu)化的性能仍然需要一些定制。

建模和生成代碼得到回報

考慮到底層圖形引擎和手頭編程任務的權(quán)衡，問題仍然存在：設(shè)計師如何獲得成功的 HMI 設(shè)計？基于模型的開發(fā)是通往最高效和最有效的 HMI 的途徑。

基于模型的開發(fā)在哪些方面影響了日常工程工作？傳統(tǒng)的開發(fā)過程包括花費時間定義自然語言需求，然后是痛苦且昂貴的手動翻譯步驟，以根據(jù)這種自然語言需求創(chuàng)建軟件設(shè)計和實現(xiàn)。當引入基于模型的工程環(huán)境時，需求過程會更加高效，因為創(chuàng)建了復雜 HMI 行為的可執(zhí)行模型。圖 2 顯示了基于模型的環(huán)境的概述。

圖 2：通過基于模型的開發(fā)流程，團隊可以圍繞所需系統(tǒng)的詳細表示進行更有效的協(xié)作，并且其所有預期行為都完好無損。

可以表示 HMI 行為的模型不僅可以比編寫自然語言文檔更快地完成，而且還可以描述幾乎不可能在基于文本的文檔中有效定義的圖形行為。這些可執(zhí)行規(guī)范可以作為需求模型作為基線，然后作為初始軟件設(shè)計，然后針對嵌入式目標性能和限制進行改進。然后，使用 Altia DeepScreen 等產(chǎn)品，可以從這個完善的可執(zhí)行模型中自動生成嵌入式實現(xiàn)。設(shè)計人員根據(jù)需求細化構(gòu)建的模型，然后為其自動生成可嵌入代碼，從而大大減少了開發(fā)工作量。

基于模型的開發(fā)，尤其是與圖形代碼生成器配合使用時，可以靈活地創(chuàng)建一次圖形模型，然后為多個圖形平臺生成代碼。這使設(shè)計人員可以在各種平臺上試用它，直到找到適合應用程序的產(chǎn)品。在選擇硬件時，無論是精靈還是 GPU，基于模型的開發(fā)為實現(xiàn)硬件和 HMI 的成功組合提供了可靠的方法。

作者：Peter Abowd ，Jim Mikola

審核編輯：郭婷