MiniGUI在HDTV SoC平臺上的移植

1．引言：
嵌入式系統功能的日益強大使得在嵌入式產(chǎn)品中包含圖形界面功能成為一種趨勢。但是嵌入式系統有著(zhù)面向特定應用、實(shí)時(shí)、高效等特點(diǎn)，對系統資源的利用受自身條件的限制，對GUI有著(zhù)輕型，高可靠性，高穩定性等要求。

高清數字電視解碼平臺HDTV SoC是由上海交通大學(xué)自行研究開(kāi)發(fā)的，以數字電視機頂盒為應用背景的嵌入式單片系統。在硬件平臺構建和操作系統移植的基礎上，系統對友好的界面提出了更高的要求。在有限的系統資源和高效的實(shí)時(shí)性能等條件約束下，如何為該平臺提供GUI的支持成為了一個(gè)難點(diǎn)。

MiniGUI是一種面向實(shí)時(shí)嵌入式系統的輕量級圖形界面支持系統，具有小巧，高效，可移植性好等特點(diǎn)。針對HDTV SoC平臺的硬件特點(diǎn)和MiniGUI體系結構的特性，本文提出了移植MiniGUI來(lái)建立圖形界面的方法，并且通過(guò)實(shí)踐驗證了該方法的可行性。

2．HDTV SoC平臺和MiniGUI:

HDTV SoC 是用于高清數字電視信號接收端的解碼平臺。如圖1所示：該平臺包含以下功能模塊：傳輸流解復用(TSD)，系統控制,音頻解碼、視頻解碼，視頻處理，顯示后處理(OSD)，以及串口等外圍設備。視頻支持MPEG－II高清和標清解碼，音頻支持AAC、AC3、MP3、MP2格式。該系統內嵌兩顆MIPS CPU分別用作系統控制和音頻解碼, 設計時(shí)鐘為108MHz，含有32M SDRAM，8M FLASH。

在HDTV SoC平臺上建立圖形界面，需要分別利用串口模塊（UART）和顯示后處理模塊（OSD）作為輸入和輸出設備。充分而高效地將顯示后處理模塊(OSD)的功能與上層軟件有機結合是有效建立圖形界面的關(guān)鍵。

MiniGUI是一種針對嵌入式設備的，跨操作系統的輕量級圖形界面支持系統。作為操作系統和應用程序之間的中間件，MiniGUI隱藏了底層操作系統與硬件平臺的差別，為上層應用程序提供了一致的功能特性。

MiniGUI具有良好的軟件架構，通過(guò)可移植層（Portable Layer）將MiniGUI上層和底層操作系統隔離開(kāi)來(lái)；可移植層可將特定操作系統及底層硬件的細節隱藏起來(lái)，而上層應用程序無(wú)需關(guān)心底層硬件平臺的輸入和輸出。作為國內廣泛應用的嵌入式圖形界面中間件產(chǎn)品，相對與其它嵌入式GUI系統，MiniGUI有以下優(yōu)勢：1.輕型，占用資源少。2.高性能，高可靠性。3.可配置。4.可伸縮性強。5.跨操作系統支持

3．移植MiniGUI:
MiniGUI的體系結構可表示如下圖：

圖2 MiniGUI的體系結構

如圖3所示，MiniGUI從上到下包括應用程序，核心層，可移植層（圖形與輸入設備抽象層）以及輸入輸出設備層。其中，圖形引擎（GAL）和輸入引擎（IAL）一起構成可移植層?？梢浦矊訛樯蠈犹峁┝私y一的輸入輸出的抽象接口，從而增強了MiniGUI的可移植性。移植MiniGUI主要是根據具體的硬件平臺對可移植層及以下各層作相應的修改，大致包括三方面工作。

首先，定制圖形引擎。MiniGUI可以支持包括SVGALib 和 LibGGI在內的多種圖形引擎，另外還自帶了基于framebuffer設備的私有圖形引擎。相對于其他圖形引擎，私有引擎專(zhuān)為L(cháng)inux平臺上的MiniGUI而設計，有更好的性能和顯示效果，因此在Linux平臺上被廣泛采用。但是該引擎需要Linux內核中包含對顯示設備的framebuffer驅動(dòng)的支持。針對HDTV SoC平臺，如果我們采用MiniGUI的私有圖形引擎，就需要在Linux內核中添加基于OSD硬件的framebuffer驅動(dòng)程序。

其次，定制輸入引擎。不同的平臺在輸入引擎上差別較大。HDTV SoC平臺采用UART作為輸入設備，所以輸入引擎要基于UART，將UART得到的外部信息轉換為上層應用程序能夠理解和識別的信息格式。

最后，需要根據平臺特性和應用需求對MiniGUI進(jìn)行功能配置。

我們將圖3中的圖形設備（Graphic Device）和輸入設備(Input Device)替換為具體的驅動(dòng)程序及相應的硬件設備可得出MiniGUI在HDTV SoC平臺上實(shí)現的具體框圖如圖4所示：

經(jīng)過(guò)以上分析之后，我們更加明確了移植所要做的工作，并且可進(jìn)一步將整個(gè)移植過(guò)程分為三階段：第一，開(kāi)發(fā)和調試基于OSD硬件的framebuffer驅動(dòng)程序，并且調試圖形引擎，這是整個(gè)移植過(guò)程中最為關(guān)鍵的一步；第二，定制和調試基于UART設備的輸入引擎；第三，開(kāi)發(fā)自己的應用程序，并且交叉編譯和配置整個(gè)MiniGUI。

首先，我們需要開(kāi)發(fā)針對HDTV SoC 平臺上OSD硬件設備的framebuffer驅動(dòng)程序。framebuffer機制定義了一組與顯示設備相關(guān)的數據結構和操作，對顯示設備的幀緩存進(jìn)行了軟件抽象，為上層提供了統一的訪(fǎng)問(wèn)接口，屏蔽了底層硬件的細節。應用程序對該組數據結構和操作進(jìn)行訪(fǎng)問(wèn)，就可以實(shí)現對不同顯卡硬件的訪(fǎng)問(wèn)操作。減少依賴(lài)于顯卡的代碼量，同時(shí)增加了這部分代碼的可移植性。另外，framebuffer機制將顯存從內核空間映射到進(jìn)程空間，實(shí)現進(jìn)程空間對顯存的直接訪(fǎng)問(wèn)，提高了顯示效率。

如果MiniGUI采用基于framebuffer設備的私有圖形引擎，首先需要在內核中添加framebuffer設備驅動(dòng)。framebuffer設備的實(shí)現主要依賴(lài)于四個(gè)數據結構：

fb_fix_screeninfo用來(lái)表示與顯示設備無(wú)關(guān)的常值信息，這些信息在設備初始化時(shí)指定，應用程序可以通過(guò)借口函數來(lái)訪(fǎng)問(wèn)這些信息，但是不允許改變它們。

fb_var_screeninfo用來(lái)表示與顯示設備無(wú)關(guān)的變量信息與特定顯示模式。應用程序可以調用相應的借口來(lái)訪(fǎng)問(wèn)和修改這些信息。

fb_ops是供上層調用的一組函數接口。全部的framebuffer操作最后都要通過(guò)該接口來(lái)完成。

fb_info 是常規信息，API以及幀緩沖設備的底層信息。該結構只能被用于內核中，前面三個(gè)結構均可通過(guò)外部接口查看。

在驅動(dòng)程序中實(shí)現了上述四個(gè)結構之后，一個(gè)簡(jiǎn)單得framebuffer驅動(dòng)程序即宣告完成。將該驅動(dòng)程序作為模塊加載之后，就可以進(jìn)行調試，直到輸出正常。

在framebuffer驅動(dòng)程序完成之后，接下來(lái)需要定制輸入引擎。MiniGUI通過(guò)INPUT數據結構來(lái)表示輸入引擎。MiniGUI維護著(zhù)一個(gè)由所有輸入引擎組成的輸入引擎數組，每個(gè)數組項對應著(zhù)一個(gè)輸入引擎。如果該數組中沒(méi)有與該平臺對應的項，就需要在其中添加對應的輸入引擎。由于SoC平臺只能通過(guò)UART和用戶(hù)進(jìn)行交互，所以輸入引擎以UART為基礎。通過(guò)把UART的消息轉換為鍵盤(pán)上相應的按鍵，再送給MiniGUI應用程序。

在圖形引擎和輸入引擎的定制完成之后，最后需要對MiniGUI的源代碼進(jìn)行交叉編譯和安裝。到這里，整個(gè)移植工作基本結束。在此基礎上，我們還可以在MiniGUI平臺上開(kāi)發(fā)自己的應用程序。

4．總結：
本文作者創(chuàng )新觀(guān)點(diǎn)：在SoC平臺上建立GUI界面需要充分考慮系統性能，資源以及GUI系統本身的資源消耗，移植開(kāi)源軟件通常是最經(jīng)濟，最簡(jiǎn)便的辦法。移植工作主要是建立GUI系統與輸入輸出硬件的映射，在必要的時(shí)候需要根據GUI系統要求為底層硬件開(kāi)發(fā)專(zhuān)用的驅動(dòng)程序。由于MiniGUI在SoC芯片上的應用還比較少，所以本次移植工作不僅驗證了移植方法的可行性，對于如何為MiniGUI在機頂盒中的應用,以及對于如何在受到資源和性能約束的嵌入式系統中建立圖形界面，均具有一定的借鑒意義