日益华丽的车载电视OSD开发占据了固件工程师大量的时间，采用结构化的OSD设计可以缩短开发时间，提高代码质量。现在介绍OSD的实现方法、OSD类型、OSD的UI基本元素及定义基础上，详细分析了使用结构化的OSD UI处理机制实现OSD开发的方法和思路。

　　随着具有各种丰富功能的车载影音产品不断上市，日益华丽的OSD界面设计占据了固件开发工程师大量的开发时间。不少的固件工程师不断地重复着同样的工作：为每一个机种编写着同样的OSD文字、图形及人机交互的界面(UI)互动代码。在UI及OSD较复杂的系统里，该部分的代码量高达30-60%，同时，调试不健壮的UI代码也将占用大量的系统调试时间。

　　车载电视的UI主要具有建立在机器上的按键和红外遥控器等输入以及OSD、蜂鸣器等输出，OSD的主要作用是提供一个直观的图形界面，帮助用户完成各种对机器的控制和信息获知等任务。随着系统处理能力的提高，现在的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(属于字符型)：为了节约显示缓存，早期及低成本的解决方案中使用字符型OSD发生器，其原理是将OSD中显示内容按照特定的格式(12×18、12×16等)进行分割成块，例如数字0-9、字母a-z、常用的亮度、对比度符号等，并把这些内容固化在ROM或Flash中，在显示缓存中仅存放对应的索引号，这样的“字典”结构可以大幅度减少显示缓存的需求。同时，为了提供对每个字符的颜色等属性的控制，通常还具有一个与显示缓存一样大小的属性缓存，其属性(前景颜色、背景颜色、闪烁等)对整个字符中的每个像素有效。为了弥补这种方式不能为每个像素指定颜色的缺点，OSD发生器的设计者提供了采用多个显示缓存合并的方式呈现多色字符的方案。其原理是每个显示缓存确定一种颜色方案，当两个甚至更多个显示缓存合并以后就可以“拼凑”出超过两种颜色的多色字符。字符型OSD优点是可以使用OSD内部较少的显示缓存，并且MCU只需要指定显示内容的索引即可显示对应OSD信息，可以在比较低速的MCU上实现。但正是由于上述的显示信息和颜色编码方式不够直观，会给字符型OSD的固件开发带来一些麻烦。通常液晶显示器、低成本的车载电视和家用CRT传统电视上均使用这一类OSD，目前仍占据着市场主流地位。

[NextPage]

　　相较字符型OSD，位图OSD(属于位图型)的处理原理较直观和简单：通过对最终显示内容上特定区域的每个像素点进行改变，直接将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内容进行必要的文字说明。
  属性：位置、颜色、闪烁特性、语言类别、大小写、对齐方式等。
  响应事件：作为固定的信息内容，通常对UI输入的控制无响应。

c. 图标(Icon)
  定义：以特定的字符或像素组合构成形状，以表达可识别的信息。
  作用：对OSD内容进行形象的提示，如播放、禁止等特定符号。
  属性：位置、颜色、闪烁特性等。
  响应事件：作为固定的信息内容，通常对UI输入的控制无响应。

d. 文字(Text)
  定义：相较标签，其同样为文字信息，但是可以随用户的操作而改变。
  作用：以随选择而改变的文字内容，提供关于用户选择的文字提示。
  属性：位置、颜色、语言类别、大小写、对齐方式等。
  响应事件：用户的选择，通常为上一个或下一个选择。

e. 进度条(Bar)
  定义：矩形条状的物件，随其数值的不同而改变相关特性，未来也许会有其它形状的此类物件，如油量表状等，但它们都具有同样的属性。
  作用：以形象的图形界面，给出关于某项数值的图形说明。
  属性：位置、颜色、上下限、当前值、类型、大小、是否显示数值等。
  响应事件：数值的改变。

[NextPage]

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需要。我们可以设计一个直观的Windows应用程序来完成诸如图形-->字符元件生成器、OSD图形界面设计，以及最终的资源文件和UI资料数组的生成，并与底层的“解释”平台进行联接编译，得到最后的MCU代码。

　　这样的OSD界面开发环境会摆脱抽象、枯燥和低效率，变得直观、有趣，甚至可以由客户自己设计相关的OSD的界面，而完全不需要编程经验和对OSD底层驱动的了解。 需要指出的是，相较传统的if else，结构化的OSD UI处理机制会带来最终程序体积的增加和运行速度的变慢，但是这些缺点在MCU内部程序空间不断增加和支持的时钟频率不断提高的情况下是微不足道的。所以，如果读者面对的案例是对MCU处理速度和程序存储器受限的情况下，可能并不适用这样的方案。以笔者开发的液晶电视项目为例，在支持所有电视功能、图文、丽音及游戏、日历等附加功能的情况下，基于MCS51的多任务系统的总程序小于32KB，而基于Myson MTV230的OSD+MCU处理器的运行速度非常快，并不会感到任何延迟。而通常支持位图OSD的开发环境使用的是X86或更快速的ARM等处理器，并具有大于2MB的程序存储空间。

　　最后的结果你也知是往哪方面发展进取,相当以问你一个这样的问题:你喜欢DOS的界面还是WINDOWS界面呢?我想你的答案肯定就和我一样是选择WINDOWS了。