OSD的主要實現方法和型別

2021-09-08 05:33:17 字數 4888 閱讀 5169

osd具有字元型(font-based)和位圖型(bit-map)兩種型別。

字元型osd:為了節約顯示快取,早期及低成本的解決方案中使用字元型osd發生器,其原理是將osd中顯示內容按照特定的格式(12×18、12×16等)進行分割成塊,例如數字0-9、字母a-z、常用的亮度、對比度符號等,並把這些內容固化在rom或flash中,在顯示快取中僅存放對應的索引號,這樣的「字典」結構可以大幅度減少顯示快取的需求。同時,為了提供對每個字元的顏色等屬性的控制,通常還具有乙個與顯示快取一樣大小的屬性快取,其屬性(前景顏色、背景顏色、閃爍等)對整個字元中的每個畫素有效。為了彌補這種方式不能為每個畫素指定顏色的缺點,osd發生器的設計者提供了採用多個顯示快取合併的方式呈現多色字元的方案。其原理是每個顯示快取確定一種顏色方案,當兩個甚至更多個顯示快取合併以後就可以「拼湊」出超過兩種顏色的多色字元。

字元型osd優點是可以使用osd內部較少的顯示快取,並且mcu只需要指定顯示內容的索引即可顯示對應osd資訊,可以在比較低速的mcu上實現。但正是由於上述的顯示資訊和顏色編碼方式不夠直觀,會給字元型osd的韌體開發帶來一些麻煩。通常液晶顯示器、低成本的平板電視和crt傳統電視上均使用這一類osd,目前仍佔據著市場主流地位。

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

osd的ui基本元素及定義

顯示osd的目的是需要向使用者表達資訊,那麼哪些資訊需要表達呢?通常包括提示、警告資訊、控制引數的數值顯示等。儘管無論其顯示形狀是什麼,其本質都是一些字元或畫素點的組合,但是對於這些資訊的分類和屬性定義有助於韌體開發人員的統一編碼和**處理。本文嘗試分類,分析這些元素並在下面給出統一的韌體處理方法。

1. osd基本概念

ui語言:指osd內容中的文字部分使用的語言型別。

ui模式:指osd內容適用的環境,例如不同的訊號源(電視、***、pc)帶來的模式變化,其作用主要區分不同的環境下osd的不同表現。

ui場景:特定語言模式下及較多資訊頁面情況下,當前osd適用的特定頁面。

ui事件:使用者利用輸入裝置向ui系統提供的操作命令。

ui動作表:指在特定ui場景中,對於ui輸入的命令進行對應處理的索引表。

osd畫布:指整個osd呈現的區域,通常為乙個矩形區域。

osd位置:通常指在osd畫布中,相較左上角原點的相對位置。

osd物件:呈現在畫布上,表達特定資訊,具有特定屬性的畫素組合。

2. osd包含的基本元素

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

a. 區域

定義:在osd畫布中,以特定的屬性(顏色、閃爍、大小等)標示出的矩形或任意形狀的區域。

作用:對osd內容進行分類或標示,例如標題區域,內容區域等。

屬性:位置、顏色、閃爍特性等。

響應事件:作為固定的資訊內容,通常對ui輸入的控制無響應。

b. 標籤(label)

定義:固定不變的文字資訊,可以是一行或多行。

作用:對osd內容進行必要的文字說明。

屬性:位置、顏色、閃爍特性、語言類別、大小寫、對齊方式等。

響應事件:作為固定的資訊內容,通常對ui輸入的控制無響應。

c. 圖示(icon)

定義:以特定的字元或畫素組合構成形狀,以表達可識別的資訊。

屬性:位置、顏色、閃爍特性等。

響應事件:作為固定的資訊內容,通常對ui輸入的控制無響應。

d. 文字(text)

定義:相較標籤,其同樣為文字資訊,但是可以隨使用者的操作而改變。

作用:以隨選擇而改變的文字內容,提供關於使用者選擇的文字提示。

屬性:位置、顏色、語言類別、大小寫、對齊方式等。

e. 進度條(bar)

如油量錶狀等,但它們都具有同樣的屬性。

作用:以形象的圖形介面,給出關於某項數值的圖形說明。

屬性:位置、顏色、上下限、當前值、型別、大小、是否顯示數值等。

響應事件:數值的改變。

f. 動畫(movie)

定義:隨時間而改變的圖示組合。

作用:以活動的圖形使osd介面更生動,提高資訊的表達效果。

屬性:位置、顏色、具有的圖示數目、變化速度等。

響應事件:作為固定的資訊內容,通常對ui輸入的控制無響應。

g. 數字

定義:隨有關引數或使用者選擇改變而改變的數字組合,可以為十進位制或其它進製,亦可以是百分比或其它數值形式。

作用:直觀地給出關於某項引數的數值量化指示,通常與進度條聯合使用,以達到直觀與形象的雙重效果。

屬性:位置、顏色、上下限、當前值、進製選擇等。

響應事件:對應引數的數值的改變。

h. 可選圖示(option)

定義:隨有關引數或使用者選擇改變而改變的圖示組合。

作用:使用者選擇的圖形化表達,例如選擇、未選擇、開啟、關閉等資訊的圖形化表達。

屬性:位置、顏色、閃爍、選擇數目等。

響應事件:對應引數的選擇改變。

i. 導航資訊

定義:呈現在osd畫布上,對當前ui場景中的使用者操作進行提示的資訊。

屬性:位置、顏色、閃爍等。

響應事件:ui場景、按鍵的改變。

使用基於物件的方法處理osd ui

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

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;

這樣的結構是為了描述乙個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處理器的執行速度非常快,並不會感到任何延遲。而通常支援點陣圖osd的開發環境使用的是x86或更快速的arm等處理器,並具有大於2mb的程式儲存空間。

OSD的主要實現方法和型別

osd具有字元型 font based 和位圖型 bit map 兩種型別。字元型osd 為了節約顯示快取,早期及低成本的解決方案中使用字元型osd發生器,其原理是將osd中顯示內容按照特定的格式 12 18 12 16等 進行分割成塊,例如數字0 9 字母a z 常用的亮度 對比度符號等,並把這些...

DataFrame型別資料的主要處理方法

其他 資料處理的主要操作,包括 排序 排名 索引重置 缺失值處理 去重。會用到的包 import pandas import numpy import datetime 排序 方法1.a data.sort 將data中的值按生序排列可用於series,不可用於dataframe dataframe...

ASP操作XML檔案的主要方法和實現

asp通過xmldom在伺服器端操作xml檔案的主要方法和實現 對於小資料量,xml檔案在檢索更新上於access有很多優勢。我曾經測試過不用資料庫,把 的會員資訊,商品資料資訊,交易資訊,定製資訊全部存放在三個xml檔案中,執行結果十分正常,感覺上比資料庫快多了,不過沒有作測試,不能確定。下面說一...