OSD (on screen display)

With the development of the automotive industry, vehicle navigation devices have been applied more. For example, an on-board navigation device integrates the DVD function (which imposes high requirements on video processing and requires a high-performance platform and a high-performance video processor) to implement volume visibility control and DVD control through the OSD technology. The advantage is that it is superimposed on the screen without affecting the DVD screen, reducing the workload of the main processor.

OSD is a screen display technology. Its core is to overlay text, mouse, and simple images on images so that the display screen can provide users with more additional information, it provides great convenience for users. Currently, cameras, televisions, monitors, and other image or video systems are widely used.

PXA270 has advanced features of high performance and low power consumption. The macro core t128d has powerful video processing functions and integrates two layers.OSDProcessing Engine, the two can greatly improve the multimedia processing function of the vehicle navigation device through the I2C bus connection, this article describes the implementation of the two based on the I2C bus connectionOSDDisplay Driver method.

1. Basic Principles

1.1OSDDisplay principle

　　OSD(On Screen Display) is a kind of Screen Display Technology, used to display characters, graphics and images on the display terminal. The implementation process is as follows: the content of the memory (usually a memory segment) corresponds to the pixels on the display terminal one by one.

Send the bitmap information of the character iconOSDThe corresponding location of the bitmap area.OSDThe bitmap area is defined by its header.OSDHeaders mainly includeOSDDisplay the starting position and size of the rectangle area, and two pointers pointing to the top field and bottom field image data respectively, and one pointing to the nextOSDThe pointer of the bitmap data header. This pointer-basedOSDData governance structure, theoreticallyOSDThe number of bitmap data blocks is unrestricted. In fact, bitmap data blocks are limited by the memory size. Terawinst128 provides 8 K * 16 B memory. The header not only defines the size, position, and color information of the bitmap area, but also provides functions such as updating the color table. Character Color settingsOSDThe color query table of the Processing Unit (LUT), also known as the color palette. As shown in 1, the 4-bit LUT means there are 16 colors available, and each pixel in the bitmap occupies four places in the storage unit. The four-bit low content in a byte corresponds to one pixel one by one, and its value is "3". The color represented by the number "3" is determined by the color palette, and then driven.OSDThe screen sets the pixel to a specific color.OSDThe two pixels correspond to 1 B, so the storage space occupied by a row of display content is 320/2 = 160 B, set posdbufferOSDThe first address of the bucket.OSDSet the pixel value of the preceding coordinate (x, y) To pixelvalue (the value range is 0x00 ~ 0x0f), that is, to change the color of the pixel, you must first determine the address of the byte storage space corresponding to the coordinate (x, y) pixel:

1.2 I2C bus communication principle

The I2C (Inter-Integrated Circuit) bus is a two-line serial bus developed by Philips to connect the microcontroller and its peripheral devices. The I2C bus is a serial bus consisting of the SDA data line and the clock SCL, which can send and receive data. Various controlled Circuits are connected in parallel to this bus, and each circuit and module has a unique address. The CPU sends an address code for site selection, that is, the circuit to be controlled is connected. Therefore, each control circuit is attached to the same bus, but is independent of each other and unrelated to each other.

The I2C bus defines strict transmission signals for one transmission. As shown in figure 2, SDA changes from high level to low level in high-power mode. This is the start signal and starts to transmit data. In low-power mode, SDA is switched from low-level to high-level, and data transmission ends.

 

Note: The data status on the SDA line can be changed only during the period when the SCL is low. When the SCL is high, the changes in the SDA status are identified as the start and stop conditions. After receiving 8 B data, the IC that receives the data sends a specific low-level pulse to the IC that sends the data, indicating that the data has been received. After the CPU sends a signal to the controlled unit, it waits for the controlled unit to send a response signal. After the CPU receives the response signal, it determines whether to continue to transmit the signal based on the actual situation. If no response signal is received, it is determined that the controlled unit has a fault.

2. Specific implementation

2.1 Interface Circuit

The PXA270 Chip sends an instruction to t128d through two cables (I2C), namely, the SCL and SDA, to notify the displayOSDOr eraseOSDImage. In the method used in this thesis, PXA270 writes the Register to t128d through I2COSDThe first address of the symbol is transmitted to t128d. The RGB or yprbr signals to be displayed in PXA270 are also connected to t128d, And the lvsync vertical synchronization signal and lysync Horizontal synchronization signal are used for synchronization. The yprbr signal of the DVD and the rgb565 signal of PXA270 are processed to simulate the RGB signal through the t128d processing, and then connected to the LCD screen, which is displayed on the LCD screen.

 

2.2 software implementation framework

TheOSDThe driver uses the stream interface driver,OSDThe stream interface-driven framework 4 is shown in. The driver is dynamically loaded by the device controller at system startup or at any time after startup. It exists as a DLL dynamic link library. After the system loads them, these drivers run as user roles. ThisOSDThe stream driver uses the file manipulation API to obtain commands from the device controller and applications. The stream interface driver has a set of standard interfaces, such as xxx_init, xxx_open, xxx_powerup, xxx_iocontrol, and xxx_write. It is very suitable for I/O devices, especially data stream devices. The operation interface is similar to the file system API, such as readfile and io_control. Applications can interact with the stream interface driver and manipulate the stream interface driver as a file.

 

The stream interface mentioned in this article isOSD_ Init,OSD_ Iocontrol,OSD_ Write.OSD_ Init notifies the device controller when loading the driver to allocate resources for device initialization.OSD_ Iocontrol is the interface for the file system to send I/O control commands. Osdwrite is the interface for the file system to write data to t128d. In this articleOSD_ Write does not perform specific write operations, but only presses the write command into the FIFO queue.

2.3 Specific operations

2.3.1 I2C bus communication process

Due to the large number of devices mounted on the I2C bus, the two devices may occupy the I2C bus at the same time. In order to avoid this situation, mutex lock is used for a read/write operation, considering its non-Interrupting nature to prevent data destruction. That is, only one read/write operation is allowed to occupy the I2C bus at a time. Wait for the mutex lock before a read/write operation starts. After the read/write operation is completed, the mutex lock is released. In this way, before a read/write operation is completed, other devices cannot occupy the I2C bus, but can only wait. See Figure 5.

2.3.2 initialization and uninstallation

The initialization of the t128 device is mainly to map gpio and t128 registers to the virtual address space first, then check whether the I2C bus driver has initialization, create a mutex, and create a write thread osdwriteproc (), createOSDWrite command non-empty event g_hevosdqueueempty so that when detecting non-empty events, you can callOSDWrite process. Call the device uninstallation function when the device fails to initialize or uninstalls the device. When uninstalling the device, open the space of the virtual gpio register, call the I2C uninstallation function, and close the mutex.

2.3.3OSDWrite Process

Written in practiceOSDYou need to stop the t128 MCU and resume its operation after writing it. OtherwiseOSDWill be confused. If you want to stop the t128mcu, It is switching the video, detecting the video signal, and the operation is stopped when the operation is not completed, the LCD screen will be disordered and the image will be divided into several parts. Write of upper-layer applicationsOSDThe request cannot be discarded. Otherwise, the upper layer may be disordered. The hidden state is not hidden, and the displayed state is not displayed. Therefore, a mechanism must be designed to ensure upper-layer writeOSDThe operation is not discarded and does not conflict with the t128 MCU.

5. Design a Buffer Queue to receive the uploadedOSDData is pushed to the queue.OSDThe write interface left by the driver to the upper layer. It is not responsible for actual write operations and immediately returns the data after it is pressed into the queue (non-empty events in the queue will be activated at this time. CreateOSDWrite thread. After the non-empty events in the buffer queue are activated, query the status of the t128 MCU. After idle, obtain the key code segment, perform write operations, and exit the key code segment, enter the next cycle.

3. Performance Analysis

T128 communicates with the CPU through three main lines, and t128 processes video signals from DVDs and PXA270.OSDThe signal of each source can be superimposed. Because t128 processes a large part of the video signal, it reduces the CPU burden and solves the problem successfully.OSDOverlapping questions on the DVD signal. Due to the multi-controller feature of I2C, the operation and performance of other peripherals mounted on I2C are not affected.

4. Main implementation methods and types of OSD

Currently, there are two main OSD Implementation Methods: overlay and synthesis between external OSD generators and video processors; OSD is supported inside the video processor, and OSD information is directly added inside the video cache.

(1) The principle of superposition and synthesis between the external OSD generator and video processor is: using a built-in character generator and display cache of MCU, fast-Blank) the signal switches between the TV screen and OSD display content, so that the OSD characters and other content are superimposed on the final display screen. During the OSD and display screen overlay process, by adjusting the ratio between the two, you can achieve the semi-transparent (blending) effect of OSD. At the same time, the red, green, and Blue signals in the OSD signal are re-encoded to obtain different OSD color effects.

(2) Another method is to enable the video processor to support OSD and directly overlay the OSD information in the video cache. This type of video processing usually has an external memory or a small amount of internal row cache, and An OSD generator. The synthesis and control of OSD are directly completed in the video cache, it also has the translucent and color control functions described above.

OSD has two types: memory type (font-based) and bitmap type (bit-map.

Balanced OSD: Memory OSD generators are used in early and low-cost solutions to save the display cache, the principle is to split the content displayed in OSD into blocks according to the specific format (12 × 18, 12 × 16, etc, for example, the numbers 0-9, letters A-Z, commonly used brightness, contrast symbols, and so on, and the content is solidified in ROM or flash, only the corresponding index number is stored in the display cache. Such a "Dictionary" structure can greatly reduce the need to display the cache. At the same time, in order to provide control over the color and other attributes of each character, it usually has an attribute cache of the same size as the display cache, its attributes (foreground color, background color, flashing, etc) valid for each pixel of the entire character. To make up for the disadvantage that this method cannot specify a color for each pixel, The OSD generator designer provides a solution that combines multiple display caches to present multi-color characters. The principle is that each display cache determines a color scheme. When two or more display caches are merged, you can "piece together" the multi-color characters in more than two colors.

The advantage of balanced OSD is that it can use a small number of internal display caches of OSD, And the MCU only needs to specify the index of the displayed content to display the corresponding OSD information, which can be achieved on a relatively low-speed MCU. However, the above display information and color encoding method are not intuitive enough, which may cause some trouble for Firmware Development of the fuse-type OSD. This type of OSD is usually used on LCD monitors, low-cost flat-panel TVs, and conventional CRT TVs, and is still dominant in the market.

Compared with balanced OSD, the processing principle of Bitmap OSD is more intuitive and simple: By changing each pixel in a specific area of the final display content, the OSD information is directly superimposed on the final display screen, the pixel-based control method ensures multi-color and sufficient performance. The bitmap OSD generator is usually built in the video processor and shared with its primary display cache. There are also professional OSD bitmap generators independent of video processors, such as Maxim's max4455. Generally, this type of chip requires external SDRAM as the display cache.

In theory, the display effect of Bitmap OSD can be very perfect. It can provide a variety of objects with a three-dimensional sense like Windows, such as shadow buttons, color-Rich graphics and text, its disadvantage is that it must have sufficient OSD display cache and the MCU speed requirements for pixel-based processing. This type of OSD is usually used on large-sized high-end flat panel TVs and professional displays. With the continuous development of technology and the ever-decreasing cost of storage, the future OSD should be Bitmap-type.

Basic UI elements and definitions of OSD

 

The purpose of displaying OSD is to express information to users. What information needs to be expressed? It usually includes prompts, warning information, and numerical display of control parameters. Although whatever the display shape, it is essentially a combination of characters or pixels, the classification and attribute definition of the information helps firmware developers to process the unified encoding and code. This article attempts to classify and analyze these elements and provides a unified solution for firmware processing.

1. Basic concepts of OSD

UI Language: The Language type used by the text part of the OSD content.

Ui mode: it refers to the environment in which OSD content is applicable, for example, the pattern changes caused by different signal sources (TVs, DVDs, and PCs). Its role is to differentiate the different performance of OSD in different environments.

Ui scenario: a specific page applicable to OSD in a specific language mode and when there are many information pages.

UI events: the operation commands provided by the user to the UI system by entering the device.

Ui action table: indicates the index table for UI input commands in a specific UI scenario.

OSD canvas: it refers to the entire OSD area, usually a rectangular area.

OSD position: usually refers to the relative position of the origin point in the upper left corner of the OSD canvas.

OSD object: a pixel combination that is displayed on the canvas and expresses specific information and has specific attributes.

2. Basic elements contained by OSD

OSD information mainly includes the following basic elements (this article may not be accurate, and readers may want to understand it ): area, label, icon, text, progress bar, animation, number, optional icon, navigation information, etc. The definitions, functions, attributes, and response events of these elements are given below.

A. Region

Definition: a rectangle or an area of any shape indicated by a specific attribute (color, blinking, size, etc.) in the OSD canvas.

Purpose: classify or mark OSD content, such as the title area and content area.

Attribute: location, color, and flicker.

B. Label)

Definition: fixed text information, which can be one or more lines.

Purpose: provide necessary text descriptions for OSD content.

Attributes: location, color, flicker, language type, Case sensitivity, alignment, etc.

RESPONSE event: as a fixed information content, it usually does not respond to the control of UI input.

C. icon)

Definition: A combination of specific characters or pixels to form identifiable information.

Purpose: perform image prompts on OSD content, such as playing or disabling specific symbols.

Attribute: location, color, and flicker.

RESPONSE event: as a fixed information content, it usually does not respond to the control of UI input.

D. Text)

Definition: Compared with labels, it is also text information, but can be changed with user operations.

Purpose: Provide text prompts about user selection based on the selected text content.

Attributes: location, color, language type, Case sensitivity, alignment, etc.

RESPONSE event: the user's choice, usually the previous or next one.

E. Progress bar)

Definition: an object in a rectangular bar changes its related characteristics as its values are different. In the future, there may be such objects in other shapes,

Such as the oil gauge, but they all have the same attributes.

Purpose: Give A Graphical description of a specific value on the graphic interface.

Attributes: location, color, upper and lower limits, current value, type, size, and whether to display values.

RESPONSE event: Numeric value change.

F. animation (movie)

Definition: A combination of icons that change over time.

Purpose: use activity graphs to make the OSD interface more vivid and improve the information expression effect.

Attribute: location, color, number of icons, change speed, etc.

RESPONSE event: as a fixed information content, it usually does not respond to the control of UI input.

G. Number

Definition: A combination of numbers that change with the relevant parameters or user selection. It can be in decimal or other hexadecimal notation, or in percent or other numerical form.

Purpose: intuitively give the numeric indicator about a parameter. It is usually used in conjunction with the progress bar to achieve both intuitive and visual effects.

Attributes: location, color, upper and lower limits, current value, and base selection.

RESPONSE event: changes the value of the corresponding parameter.

H. Option)

Definition: A combination of icons that change with the relevant parameters or user selection.

Purpose: graphical representation of user selection, such as selection, unselected, enabled, and disabled.

Attribute: location, color, blinking, and number of options.

RESPONSE event: changes the selection of corresponding parameters.

I. Navigation Information

Definition: displays the information prompted for user operations in the current UI scenario on the OSD canvas.

Purpose: Instruct the user to perform operations on related buttons and OSD content. Generally, there are indications of available buttons and necessary text instructions, which are usually used as a measure to improve the OSD prompt information and make the man-machine interface friendly.

Attribute: location, color, and flickering.

RESPONSE event: Ui scenario, button changes.

Use an object-based method to process OSD UI

The traditional processing method is to "Draw" OSD objects in specific scenarios one by one using the code. When a specific UI event occurs, use a bunch of if Else To identify specific scenarios and operation objects, and perform corresponding OSD processing. When OSD is relatively simple, it is a feasible method. However, when there are many OSD scenarios and modes, the IF else structure will become very large, and more importantly, it is easy to make mistakes and increase maintenance costs. As OSD becomes more complex and code workload increases, people realize that we need to spend too much time on these "superficial articles, the development time of the really important application layer and device driver layer will be affected, thus affecting the development progress of new products. Firmware engineers are also reluctant to repeatedly write the same code to meet the specific OSD needs of customers. I encountered the same troubles in the early days. In the face of the inefficiency of engineers in the department, I felt the importance of developing a unified OSD UI platform. Now, the analysis of the above osd ui allows us to develop an independent and unified development tool independent of the hardware environment of a specific Digital Video Processor platform and OSD mechanism. In fact, important providers of flat display chip solutions, such as genesis and pixelworks, have provided Windows-based Firmware Development Tools with such features to accelerate the development and application of their products. This article attempts to explore the operating principles of this type of tool. Perhaps readers can develop the tools they need based on this article. Of course, its application is more representative.