日益華麗的平板電視OSD開發占據了固件工程師大量的時間，采用結構化的OSD設計可以縮短開發時間，提高代碼質量。本文在介紹OSD的實現方法、OSD類型、OSD的UI基本元素及定義基礎上，詳細分析了使用結構化的OSD UI處理機制實現OSD開發的方法和思路。

圖1：字符型OSD。

       隨著具有各種豐富功能的平板電視不斷上市，日益華麗的OSD界面設計占據了固件開發工程師大量的開發時間。不少的固件工程師不斷地重復著同樣的工作：為每一個機種編寫著同樣的OSD文字、圖形及人機交互的界面(UI)互動代碼。在UI及OSD較復雜的系統里，該部分的代碼量高達30-60%，同時，調試不健壯的UI代碼也將占用大量的系統調試時間。

        平板電視的UI主要具有建立在機器上的按鍵和紅外遙控器等輸入以及OSD、蜂鳴器等輸出，OSD的主要作用是提供一個直觀的圖形界面，幫助用戶完成各種對機器的控制和信息獲知等任務。圖1、2呈現了用戶可能經?？吹降腛SD外觀。隨著系統處理能力的提高，現在的OSD甚至可以提供內建游戲、記事本和萬年歷等各種附件功能。本文主要討論的是OSD固件的設計及與之相關的UI控制，并試圖提供一個關于平板電視中UI的定義和解決方案，縮短固件工程師在UI OSD界面構造上的時間。本文中的概念及方案同樣適用于其它具有點陣顯示控制任務的場合。

OSD的主要實現方法和類型

        目前有兩種主要的OSD實現方法：外部OSD發生器與視頻處理器間的疊加合成；視頻處理器內部支持OSD，直接在視頻緩存內部疊加OSD信息。

        外部OSD發生器與視頻處理器間的疊加合成的實現原理是：由一個MCU內建的字符發生器及顯示緩存，利用快速消隱(Fast-Blank)信號切換電視的畫面和OSD顯示內容，使OSD的字符等內容疊加在最終的顯示畫面上，在OSD和顯示畫面疊加處理過程中，通過調整兩者之間的比例可以實現OSD的半透明(Blending)效果。同時，對OSD信號中的紅綠藍信號進行重新編碼，可以得到不同的OSD顏色效果。

        另外一種實現方法是視頻處理器內部支持OSD，直接在視頻緩存內部疊加OSD信息。這一類視頻處理通常具有外部存儲器或內部少量的行緩存，同時具有OSD發生器，OSD的合成和控制直接在視頻緩存內完成，同樣具有上述的半透明和顏色控制功能。

        OSD具有字符型(Font-Based)和位圖型(Bit-Map)兩種類型。

        字符型OSD(圖1屬于字符型)：為了節約顯示緩存，早期及低成本的解決方案中使用字符型OSD發生器，其原理是將OSD中顯示內容按照特定的格式(12×18、12×16等)進行分割成塊，例如數字0-9、字母a-z、常用的亮度、對比度符號等，并把這些內容固化在ROM或Flash中，在顯示緩存中僅存放對應的索引號，這樣的“字典”結構可以大幅度減少顯示緩存的需求。

        同時，為了提供對每個字符的顏色等屬性的控制，通常還具有一個與顯示緩存一樣大小的屬性緩存，其屬性(前景顏色、背景顏色、閃爍等)對整個字符中的每個像素有效。為了彌補這種方式不能為每個像素指定顏色的缺點，OSD發生器的設計者提供了采用多個顯示緩存合并的方式呈現多色字符的方案。其原理是每個顯示緩存確定一種顏色方案，當兩個甚至更多個顯示緩存合并以后就可以“拼湊”出超過兩種顏色的多色字符。

圖2：位圖型OSD。

         字符型OSD優點是可以使用OSD內部較少的顯示緩存，并且MCU只需要指定顯示內容的索引即可顯示對應OSD信息，可以在比較低速的MCU上實現。但正是由于上述的顯示信息和顏色編碼方式不夠直觀，會給字符型OSD的固件開發帶來一些麻煩。通常液晶顯示器、低成本的平板電視和CRT傳統電視上均使用這一類OSD，目前仍占據著市場主流地位。

        相較字符型OSD，位圖OSD(圖2屬于位圖型)的處理原理較直觀和簡單：通過對最終顯示內容上特定區域的每個像素點進行改變，直接將OSD信息疊加到最終的顯示畫面上，其按像素進行控制的方式可以保證具有多色及足夠的表現能力。位圖OSD發生器通常內建在視頻處理器內部，并共享使用其主顯示緩存。也有獨立在視頻處理器之外的專業OSD位圖發生器，如美信的MAX4455，通常這一類芯片需要外部SDRAM作為顯示緩存。

        位圖OSD的顯示效果理論上可以做到非常完美的程度，可以提供類似Windows中具有立體感的各種物件，如具有陰影的按鈕、顏色豐富的圖形和文字等，其缺點是必須具有足夠的OSD顯示緩存，以及按像素進行處理而對MCU帶來的速度要求。通常在大尺寸的高端平板電視和專業顯示器上會使用這一類OSD。隨著技術的不斷發展和存儲器的成本的不斷下降，未來的OSD應該都是位圖型的。

OSD的UI基本元素及定義

        顯示OSD的目的是需要向用戶表達信息，那么哪些信息需要表達呢？通常包括提示、警告信息、控制參數的數值顯示等。盡管無論其顯示形狀是什么，其本質都是一些字符或像素點的組合，但是對于這些信息的分類和屬性定義有助于固件開發人員的統一編碼和代碼處理。本文嘗試分類，分析這些元素并在下面給出統一的固件處理方法。

1. OSD基本概念

UI語言：指OSD內容中的文字部分使用的語言類型。
UI模式：指OSD內容適用的環境，例如不同的信號源(電視、DVD、PC)帶來的模式變化，其作用主要區分不同的環境下OSD的不同表現。
UI場景：特定語言模式下及較多信息頁面情況下，當前OSD適用的特定頁面。
UI事件：用戶利用輸入設備向UI系統提供的操作命令。
UI動作表：指在特定UI場景中，對于UI輸入的命令進行對應處理的索引表。
OSD畫布：指整個OSD呈現的區域，通常為一個矩形區域。
OSD位置：通常指在OSD畫布中，相較左上角原點的相對位置。
OSD物件：呈現在畫布上，表達特定信息，具有特定屬性的像素組合。

2. OSD包含的基本元素

        OSD信息中主要包括以下一些基本元素(可能本文的提法未必準確，希望讀者可以體會到其意思)：區域、標簽、圖標、文字、進度條、動畫、數字、可選圖標、導航信息等。下面分別給出這些元素的定義、作用、屬性和響應事件。

a. 區域
定義：在OSD畫布中，以特定的屬性(顏色、閃爍、大小等)標示出的矩形或任意形狀的區域。
作用：對OSD內容進行分類或標示，例如標題區域，內容區域等。
屬性：位置、顏色、閃爍特性等。
響應事件：作為固定的信息內容，通常對UI輸入的控制無響應。

b. 標簽(Label)
定義：固定不變的文字信息，可以是一行或多行。
作用：對OSD內容進行必要的文字說明。

圖3：字符型OSD結構。

屬性：位置、顏色、閃爍特性、語言類別、大小寫、對齊方式等。
響應事件：作為固定的信息內容，通常對UI輸入的控制無響應。

c. 圖標(Icon)
定義：以特定的字符或像素組合構成形狀，以表達可識別的信息。
作用：對OSD內容進行形象的提示，如播放、禁止等特定符號。
屬性：位置、顏色、閃爍特性等。
響應事件：作為固定的信息內容，通常對UI輸入的控制無響應。

d. 文字(Text)
定義：相較標簽，其同樣為文字信息，但是可以隨用戶的操作而改變。
作用：以隨選擇而改變的文字內容，提供關于用戶選擇的文字提示。
屬性：位置、顏色、語言類別、大小寫、對齊方式等。
響應事件：用戶的選擇，通常為上一個或下一個選擇。

e. 進度條(Bar)
定義：矩形條狀的物件，隨其數值的不同而改變相關特性，未來也許會有其它形狀的此類物件，如油量表狀等，但它們都具有同樣的屬性。
作用：以形象的圖形界面，給出關于某項數值的圖形說明。
屬性：位置、顏色、上下限、當前值、類型、大小、是否顯示數值等。
響應事件：數值的改變。

f. 動畫(Movie)
定義：隨時間而改變的圖標組合。
作用：以活動的圖形使OSD界面更生動，提高信息的表達效果。
屬性：位置、顏色、具有的圖標數目、變化速度等。
響應事件：作為固定的信息內容，通常對UI輸入的控制無響應。

g. 數字
定義：隨有關參數或用戶選擇改變而改變的數字組合，可以為十進制或其它進制，亦可以是百分比或其它數值形式。
作用：直觀地給出關于某項參數的數值量化指示，通常與進度條聯合使用，以達到直觀與形象的雙重效果。
屬性：位置、顏色、上下限、當前值、進制選擇等。
響應事件：對應參數的數值的改變。

h. 可選圖標(Option)
定義：隨有關參數或用戶選擇改變而改變的圖標組合。
作用：用戶選擇的圖形化表達，例如選擇、未選擇、開啟、關閉等信息的圖形化表達。
屬性：位置、顏色、閃爍、選擇數目等。
響應事件：對應參數的選擇改變。

i. 導航信息
定義：呈現在OSD畫布上，對當前UI場景中的用戶操作進行提示的信息。
作用：指引用戶操作相關按鍵，進行OSD內容操作。通常具有可用按鍵的指示以及必要的文字說明，通常作為OSD提示信息的完善和人機界面友好化的措施。
屬性：位置、顏色、閃爍等。
響應事件：UI場景、按鍵的改變。

        需要說明的是，上述的物件并不能涵蓋現在和將來所有的OSD中可能出現的內容，但卻是OSD的基本的和主要的內容，通過對它們進行分類和進行統一的處理，可以幫我們完成通常意義上的OSD的80-90%的工作。

使用基于對象的方法處理OSD UI

        傳統的處理手法是將特定場景下的OSD物件逐一用代碼“畫”出來，在遇到特定的UI事件時，再利用一堆if else判斷出特定場景和操作對象，并做相應的OSD處理。在OSD較簡單的情況下，其不失為一個可行的方法。但在遇到OSD場景和模式較多的情況下，這個if else的結構會變得很大，而且更為重要的是極易出錯以及維護成本提高。

        隨著OSD越來越復雜以及代碼工作量的不斷提高，人們意識到我們需要花費太多時間在這些“表面文章”上，而真正重要的應用層和設備驅動層的開發時間會受到影響，進而影響新產品的開發進度。固件工程師也不愿不斷重復編寫同樣代碼來滿足不斷改變客戶的特定OSD需要。

        筆者早期也曾遭遇同樣的困擾，面對部門里工程師毫無效率地做著同樣的事情，感覺到開發一個統一的OSD UI平臺的重要性。現在對于上述OSD UI進行的分析，可以讓我們開發出獨立于特定數字視頻處理器平臺和OSD發生機制的硬件環境的獨立統一開發工具。

        事實上，平板顯示芯片方案的重要提供者如Genesis、Pixelworks等為了加速其產品的開發和應用速度，已經提供了具有這樣功能的基于Windows的固件開發工具。本文試圖探討這一類工具的運作原理，或許讀者基于本文可以開發出自己所需要的工具，當然其應用具有更廣泛的代表性。

筆者在最近的液晶電視開發案例中使用了這樣一個結構：

typedef struct
{
byte mode；//UI場景適用的模式
byte lan; // UI語言
byte scene; // UI場景
byte last; // UI上個場景
byte next; // UI下個場景
byte sel; //UI 當前場景對物件的選擇
byte sel_total; //UI當前場景中選擇項的總數
byte *info; // UI的物件指針
byte pos_v; // 物件垂直方向位置
byte pos_h; // 物件水平方向的位置
byte col_f; // 物件的前景顏色
byte col_b; // 物件的背景顏色
byte att; // 物件的其它顯示屬性
ACT_Struct (*act)[]; // 該物件的響應動作表指針
byte *note; // 導航說明信息
}UI_Struct;

圖4：Pixelworks的GUI Builder OSD UI開發工具界面。

        這樣的結構是為了描述一個OSD物件的基本屬性及規定其對于動作的相應表現。利用這樣的結構將場景中的每個物件描述清楚，則一個特定UI場景的OSD內容就可以被確定，而同時被確定的還有其上一個場景、下一個場景及動作響應特性等所有UI特性。這樣的信息構成一個數組，由一個統一的“解釋平臺”對其進行翻譯和描述，從而將整個UI構造完成。

        這有點類似解釋語言，而我們所需要做的就是編寫這些“腳本”，對物件進行OSD“繪制”的工作由“解釋”平臺去調用外部的OSD發生器的驅動代碼來完成。當需要改變OSD發生器或基于不同平面顯示控制器平臺時，只需要更新少量OSD部分驅動代碼，從而實現UI系統“平臺無關化”。

        我們需要構造相關物件的數據結構，以便“解釋”平臺識別物件類型并進行正確的繪制。例如下面的結構完成了一個語言選項(文字物件)的描述：

void UI_ChangeLan()
{
UI_Lan=VAL_Lan;
ReDraw();
}
code byte *STR_LAN_CHN[]=
{
“中文”,
“英文”,
“法文”,
“西班牙文”,
};
code word TXT_LAN_CHN[]=
{
//文字物件的標志 對應的文字資源 對應的變量 具有的可選項目總數 當該物件被改變時的執行動作
RES_TXT,STR_LAN_CHN,VAL_LAN,sizeof(STR_LAN_CHN)/sizeof(byte *),UI_ChangeLan
};

        第一個數據RES_TXT向“解釋”平臺表明這個物件是文字，具有文字的數據結構。“解釋”平臺依據這一點，按照事先約定的結構讀取后繼數據，第二個數據表明其文字內容的來源是STR_LAN_CHN，第三個數據表明需要根據哪個變量來決定獲取文字資源中第幾個數據，而第四個數據表明，該物件具有多少個可供選擇的文字內容，最后一個數據規定了當該物件發生改變時需要做什么。這樣，“解釋”平臺獲得了足夠的信息去“繪制”這樣一個語言選項，并可以在發生改變時去自動執行UI_ChangeLan()這個函數，幫助程序員去完成語言改變所需要進行的操作。

        事實上，所有這些結構完全可以進行定制，只要與“解釋”平臺保持一致就可以了。

        利用這樣一個OSD驅動結構，一旦“解釋”平臺構建完成，OSD開發人員需要做的就變成利用平臺支持的各種物件積木，進行擺放、堆積來構造OSD圖形表現，而不必要重復編寫實現代碼和關心與特定硬件平臺相關的驅動代碼細節。

        更進一步，甚至連這些積木的擺放和設計，我們可以設計一個直觀的Windows應用程序來完成諸如圖形-->字符元件生成器、OSD圖形界面設計，以及最終的資源文件和UI資料數組的生成，并與底層的“解釋”平臺進行聯接編譯，得到最后的MCU代碼。

         這樣的OSD界面開發環境會擺脫抽象、枯燥和低效率，變得直觀、有趣，甚至可以由客戶自己設計相關的OSD的界面，而完全不需要編程經驗和對OSD底層驅動的了解。

        需要指出的是，相較傳統的if else，結構化的OSD UI處理機制會帶來最終程序體積的增加和運行速度的變慢，但是這些缺點在MCU內部程序空間不斷增加和支持的時鐘頻率不斷提高的情況下是微不足道的。所以，如果讀者面對的案例是對MCU處理速度和程序存儲器受限的情況下，可能并不適用這樣的方案。以筆者開發的液晶電視項目為例，在支持所有電視功能、圖文、麗音及游戲、日歷等附加功能的情況下，基于MCS51的多任務系統的總程序小于32KB，而基于Myson MTV230的OSD+MCU處理器的運行速度非?？欤⒉粫械饺魏窝舆t。而通常支持位圖OSD的開發環境使用的是X86或更快速的ARM等處理器，并具有大于2MB的程序存儲空間。

本文小結

        當固件開發工程師面對越來越復雜的應用時，面向對象、結構化的編程方式會變得越來越重要，其直接的好處是編程效率的提高和維護成本的下降，同時對于程序的健壯性也有幫助。本文提供的方法的優越性已經在實際的開發案例中得到檢驗，這樣完成同樣的OSD界面，筆者可以縮短到原來的1/4的時間，并提高了代碼的質量。