System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK

Freescale Semiconductor
Application Note
Document Number: AN4180
Rev. 0, 08/2010
System-80 Asynchronous Display on
the i.MX31 WINCE 6.0 PDK
by
Multimedia Applications Division
Freescale Semiconductor, Inc.
Austin, TX
This application note provides the necessary information,
considerations, and procedure to add or adapt a System-80
Type 2 (sampling with the read and write signals)
asynchronous panel to the WINCE600 Board Support
Package (BSP) for the i.MX31 Platform Development Kit
(PDK). This application note describes the smart panel
information and the generalities of the Asynchronous
Display Controller (ADC). In addition, this application note
also describes the development process to adapt a new panel
to the BSP, considering that the framework driver structure
is already provided by the operating system. This application
note assumes that the reader is familiar with the Microsoft®
Platform Builder packages and the WINCE Embedded 6.0
Device Driver concepts.
1
Overview of i.MX31 Display
As a multimedia processor, the i.MX31 supports several
types of displays. The display devices are handled by a
special module called the Image Processing Unit (IPU). The
IPU module also handles other graphic interfaces such as the
Camera interface and 2D graphics acceleration. All the IPU
submodules are connected by a private
© 2010 Freescale Semiconductor, Inc. All rights reserved.
1.
2.
3.
4.
5.
6.
Contents
Overview of i.MX31 Display . . . . . . . . . . . . . . . . . . . 1
LCD Generalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Asynchronous Display Interfaces . . . . . . . . . . . . . . . . 5
Display Configuration in WINCE 6.0 . . . . . . . . . . . 22
Modifying the BSP . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Overview of i.MX31 Display
Direct Memory Access (DMA) Interface that is used for the IPU to transfer data between the submodules
and also between the IPU and external memory.
Figure 1 shows the functional block diagram of the IPU module.
IPU
Sync &
Control
Pixel 3
Video
Sources
Camera
Interface
Camera
Processing
Memory
Interface
Image
Enhancement
& Conver sion
IDMA
MCU
Memory
Displays
Display
Interface
Display
Processing
Figure 1. IPU Functional Block Diagram
Selecting an appropriate Liquid Crystal Display (LCD) for a mobile device involves several conflicts with
respect to the requirements. Some of these conflicts are described as follows:
• Large amount of data, implying high rate of data transfer and processing, requiring significant
resources
• Flexibility to support a variety of use cases
• Small size, cost, and power consumption
Freescale provides reference designs for the i.MX family where the functionality of LCD is demonstrated.
However, according to the requirements, developers find many reasons to replace the display in their
products. Features such as screen size, resolution, weight, power consumption, and price are very
important in a commercial multimedia product. Another important fact about LCD panels is that many
displays become obsolete quickly. Therefore, it is hard to find the same LCD panel included in the
reference design while creating a product.
This application note is intended only for Smart Displays that include panels, which uses the System-80
Type 2 (sampling with the read and write signals) as display interface. However, this application note also
provides some information about dumb displays.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
2
Freescale Semiconductor
LCD Generalities
2
LCD Generalities
This section describes the generalities of the LCD devices.
2.1
LCD Basics
LCD is an electronic device, which consists of an array of pixels, which can be either color or monochrome
unit. Every element in the array is created with a special material that allows the LCD to change the
characteristics of the light that passes through them. These devices do not emit light and therefore, another
element named backlight is shipped along with the panel to create a fully functional display device.
2.1.1
Resolution
In this application note, the term resolution is used to refer to the number of pixels contained in an LCD
array. It has two dimensions—horizontal and vertical.
Table 1 lists the most common video resolution standards.
Table 1. Video Resolution Standards
Video Name
CGA
QVGA
VGA
NTSC
PAL
Description
Width
Height
Aspect Ratio
Color Graphics Adapter
320
200
8:5
Quarter VGA
320
240
4:3
Video Graphics Array
640
480
4:3
National Television System Committee
720
480
3:2
Phase Alternating Line (TV)
768
576
4:3
The maximum standard resolution that the i.MX31 supports is SVGA and hence, resolutions greater than
SVGA are not included in Table 1.
All resolutions mentioned in Table 1 show a landscape orientation of LCD panels, which means that there
are more pixels in the horizontal axis than in the vertical axis. However, there are also portrait LCD panels
available in the market with the same standard resolution but the horizontal and vertical size are inverted.
These portrait LCD panels have more vertical pixels when compared to the horizontal pixels.
Figure 2 shows the portrait and landscape orientation of an LCD panel.
Figure 2. Portrait and Landscape Orientation of an LCD Panel
It is important to select an appropriate orientation of the LCD panel because both the electronic and optical
features are optimized for applications that use the native orientation of the panel. Besides the optical
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
3
LCD Generalities
characteristics, the dumb displays include an embedded LCD controller to draw the pixels from left to right
and top to bottom. However, to show images or videos on the LCD panel using a non-native orientation,
the display content is pre-processed. Therefore, the image is stored in a buffer in a way (order) the LCD
controller expects the pixel information to be sent to it. This operation is called rotation and the i.MX31
includes hardware to perform this operation. It is recommended to select the LCD panel that mostly uses
its native orientation to avoid additional image processing.
Figure 3 shows the portrait and landscape LCD panels displaying images in the non-native orientation.
Figure 3. Rotated Frame on Portrait and Landscape Orientation of an LCD Panel
The frames can be rotated in 90°, 180°, or 270°. Every frame has to be rotated before sending to the display.
2.1.2
Size
The size of an LCD panel is measured diagonally in inches, from top left corner to bottom right corner.
Since the size directly impacts the pixel width, it is common to assume the size of a VGA (640 × 480) panel
to be larger than a QVGA (320 × 240) panel because the number of pixels in VGA is four times greater
when compared to QVGA. But, this is not true at all times. LCD manufacturing processes allow the size
and resolution to be independent variables. It is difficult to determine the size of a panel from its resolution.
Screens that are larger in size tend to consume more power than the smaller ones and also impact the size
and weight of the final product. On the other hand, higher resolutions on smaller LCD panels can
complicate the visibility for the final user. Based on the information available in the datasheet, it is difficult
to determine if a particular LCD panel fits the application. Instead, it is recommended to view the LCD in
other reference design or demo before making a final decision.
2.1.3
Color Spaces
A color space is a way to represent colors. There are two main color spaces—RGB (that is, RGB565,
RGB888, and RGBA8888) and YUV (that is, YUV 4:4:4, YUV 4:2:2, and YUV 4:2:0). The i.MX31
supports both the color spaces, but the display panels can receive data only by using the RGB interface.
2.2
LCD Types
The LCD panels are categorized as synchronous and asynchronous panels and their descriptions are
described in the following sections.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
4
Freescale Semiconductor
Asynchronous Display Interfaces
2.2.1
Synchronous Panel (Dumb Display)
Dumb displays or synchronous displays are panels which require the microprocessor to send all pixels in
the image every frame. In these panels, screen refresh is performed by driving the complete frame data
continuously. In general, smart displays are more expensive than dumb displays and due to this reason,
synchronous panels are more commonly used in the final product.
2.2.2
Asynchronous Panel (Smart Display)
The advantage of smart displays is that the i.MX31 has to send only the display data when the image has
changed, and most of the times it sends only the portion that has changed. Images can be sent at any time
and the screen refresh is handled by the embedded Smart Liquid Crystal Display Controller. Another
advantage of smart displays is that the i.MX31 can handle three asynchronous displays and synchronous
interface simultaneously. If an application requires two LCD panels, one of them must be an asynchronous
interfaces.
3
Asynchronous Display Interfaces
There are two types of asynchronous display interfaces—System-80 LCD interface and 68 K interface.
3.1
System-80 (Type 2) LCD Interface
The System-80 LCD interface is one of the widely used interfaces for smart displays. It is also known as
80-series system bus interface or Intel 80 interface. This interface is composed of four control lines—CS,
RS, WR, and RD, and the data bus whose width can vary. The i.MX31 can handle the Type 1 (sampling
with the chip select signal) and Type 2 (sampling with the read and write signals) interfaces, but this
application note focuses only on the Type 2 interface, which is the most commonly used interface.
Table 2 shows the System-80 (Type 2) interface signals.
.
Table 2. System-80 (Type 2) Interface Signals
Signal
IPU Signal
Description
CS0
IPP_DO_DISPB_D0_CS
Display 0 chip select
CS1
IPP_DO_DISPB_D1_CS
Display 1 chip select
CS2
IPP_DO_DISPB_D2_CS
Display 2 chip select
RS
IPP_DO_DISPB_PAR_RS
Data/command select for parallel interface
WR
IPP_DO_DISPB_WR
Write strobe signal
RD
IPP_DO_DISPB_RD
Read strobe signal
DB [15:0]
DISPB_DATA [15:0]
Data bus
The various signals that are available in the System-80 LCD interface are as follows:
• CS 0–2—Chip Select (CS) signal is used to communicate to the smart LCD panel that the
commands and data used in the System-80 interface belongs to LCD. The i.MX31 can handle up
to three asynchronous panels, and the method used to distinguish which LCD is addressed by the
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
5
Asynchronous Display Interfaces
•
•
•
•
microprocessor by using a CS per panel. Most of the times, the CS0 signal is active low and the tag
used for this line is nCS.
RS—Register Select (data/command) is a control signal for the System-80 interface of the
asynchronous display (0–2). Using the RS signal, the processor communicates to the LCD panel if
the information in the bus has to be interpreted either as a command or data. In general, command
mode is used to set the register address before sending the register’s value using the data mode.
WR—When the Write strobe signal is active, the processor is indicating that either the command
or data is on the data bus and it must be read by the LCD panel.
RD—The Read strobe signal is used by the i.MX31 to request the LCD panel to place the command
or data in the bus when the processor is ready to read the information and this information is related
with the previous command.
DI—The Display Interface (DI) is used to send/receive data and command to/from the LCD panel.
Depending on the LCD interface, the bus width can vary from 7 to 18 bits.
Figure 4 shows the LCD interface between the i.MX31 processor and the Giant plus GPM722A0 VGA
panel.
DIS PB_DATA[15:0]
System 80
DB0-DB15
IPP_DO_DISPB_D0_CS
CS
IPP_DO_DISPB_PAR_RS
RS
IPP_DO_DISPB_WR
/WR
IPP_DO_DISPB_RD
/RD
DIS PB_D1_CS (GPIO)
/RESET
240
System 80
GIANTPLUS
GPM722A0
320
MCIMX31
5V5_BOOST
Backlight
LED_A
LED_K
Touch Panel
YU
XR
YD
XL
LED_KP
CSPI
I2S
MC13783
A TLAS
Figure 4. LCD Interface Between the i.MX31 and GiantPlus GPM722A0 VGA Panel
Figure 4 shows how i.MX31 is interfaced with a smart LCD panel such as the GPM722A0 GiantPlus. The
System-80 (Type 2) interface is used for LCD initialization (command mode) and also for sending the
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
6
Freescale Semiconductor
Asynchronous Display Interfaces
display buffers (template data mode). Additionally, the LCD panel requires a reset signal, external
backlight power booster circuit, and touch screen support. In PDK (only), the touch screen support feature
is provided by PMIC ATLAS MC13783 by using the keypad LED circuit. Also, the PMIC settings are
configured by the i.MX31 using an SPI interface.
3.2
68 K Interface
The 68 K interface is from Motorola and it is one of the widely used interfaces for smart displays. This
interface is composed of four control lines—CS, RS, RW_WR, and E_RDB, and the data bus, whose width
can vary. The difference between this interface and the System-80 interface is the inclusion of an Enable
signal (E_RDB), which is used to indicate when the data needs to be latched for read and write operations.
Also, unlike System-80 interface, this interface combines the read or write selection in a single line
(RW_WR).
Table 3 shows the 68 K interface signals.
.
Table 3. 68 K Interface Signals
Signal
IPU Signal
Description
CS0
IPP_DO_DISPB_D0_CS
Display 0 chip select
CS1
IPP_DO_DISPB_D1_CS
Display 1 chip select
CS2
IPP_DO_DISPB_D2_CS
Display 2 chip select
RS
IPP_DO_DISPB_PAR_RS
Data/command select for parallel interface
RD_WR
IPP_DO_DISPB_RD_WR
Read/Write strobe signal
EN
IPP_DO_DISPB_EN
Enable
DB [15:0]
DISPB_DATA [15:0]
Data bus
The various signals that are available in the 68 K interface are as follows:
• CS 0–2—Chip Select (CS) signal is used to communicate to the smart LCD panel that the
commands and data used in the 68 K interface belongs to LCD. The i.MX31 can handle up to three
asynchronous panels, and the method used to distinguish which LCD is addressed by the
microprocessor is by using one CS per panel. Most of the times, the CS signal is active low and the
tag used for this line is nCS.
• RS—Register Select (data/command) is a control signal for the 68 K interface of the asynchronous
display (0–2). Using the RS signal, the processor communicates to the LCD panel if the
information in the bus has to be interpreted either as a command or data. In general, command
mode is used to set the register address before sending the register’s value using the data mode.
• RD_WR—Read/Write control signal is used to distinguish whether the information on the data bus
is being written to the LCD, or if the instruction is a reading request to the LCD.
• EN—Enable signal determines when the data in the bus is ready to perform both the read and write
operations.
• DI—Depending on the LCD interface, the bus width can vary from 7 to 18 bits. This application
note does not focus on the display interface. Therefore, there are no details available about this
interface.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
7
Asynchronous Display Interfaces
3.3
Asynchronous Serial Interfaces
Apart from the parallel interface, there are also serial interfaces that can be used to control the smart panels.
The i.MX31 IPU can handle the following types of asynchronous serial interfaces:
• 3-wire (with bidirectional data line)
• 4-wire (with separate data input and output lines)
• 5-wire type 1 (with sampling RS by the serial clock)
• 5-wire type 2 (with sampling RS by the chip select signal)
As this application note do not focus on the above interfaces, there are no details available about all these
interfaces.
3.4
System-80 (Type 2) Display Timing and Signals
This section focuses on the timing and signal waveforms and how to configure them in the LCD panel and
the i.MX31 display interface. The first step in selecting an LCD module is to refer to its datasheet. The
datasheet must contain the pin interface, system interface data format (that is, 16-bit or 18-bit interface,
1,2, or 3 transfer per pixel), initialization routine, and timing charts for the System-80 (Type 2) interface.
Many times a shorter version of the datasheet is only available with no sufficient information. In this case,
it is advisable to request for full documentation from the supplier. The document that is received contains
a message (in every sheet) indicating that the document is only a preliminary version. Though there is not
much difference between the preliminary and final versions, it is always better to have the final version.
3.4.1
Timing Charts
To understand the timing issues in a System-80 LCD interface, review the charts—CS, RS, RD, WR, and
Data bus in the datasheet.
These charts can be used to verify the logical value of every signal while performing any operation. Most
of the System-80 LCD datasheets contain diagrams to show how to read, write, and send commands to the
LCD controller.
For example, if the LCD is using the System-80 (Type 2) interface with 18/16 bit data system interface,
then the diagrams are similar to the following figures.
Figure 5 shows the write sequence of the System-80 (Type 2) 18/16 bit interface.
nCS
RS
nRD
nWR
DB[17:0],
DB[15:0]
Write register “index”
Write register “data”
Figure 5. Write Sequence of the System-80 (Type 2) 18/16 Bit Interface
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
8
Freescale Semiconductor
Asynchronous Display Interfaces
In this figure, the CS, RD, and WR signals are active low. These signals become active only when the
signal goes low. From Figure 5, it is verified to be a System-80 (Type 2) interface, because the data is
latched by using the RD and WR signals. When RS is the only signal used in conjunction with WR signal
and also when RS is low, the information on the data bus must be treated as a command (register). On the
other hand, when RS has a high value and WR is active, the information on the data bus is related with
some data, which is typically a straight RS polarity.
3.4.1.1
Read from Register
Figure 6 shows the read sequence of the System-80 (Type 2) 18/16 bit interface.
nCS
RS
nRD
nWR
DB[17:0],
DB[15:0]
Write register “index”
Read register “data”
Figure 6. Read Sequence of the System-80 (Type 2) 18/16 Bit Interface
Figure 6 shows that the RD signal is used to indicate when the data is going to be read and this signal is
used only after a command is issued.
It is observed that the data polarity is always straight for color LCDs and can be inverted for
monochromatic LCDs.
3.4.2
Timing Concepts
Though the previous figures are helpful in understanding the logical flow of the interface, more details
about the timing of each state (in ns) are required to configure the display interface.
Table 4 shows the timing concepts in the asynchronous System-80 (Type 2) LCD interface.
Table 4. Timing Concepts
Timing Concepts
Description
Write system cycle time Width of the write signal strobe cycle that is used to mark the writing of each data or command to the
(tCYCW)
LCD. It is the combination of the write low pulse width and the write high pulse width and the transition
between these states.
Read system cycle time Width of the read signal strobe cycle that is used to mark the reading of each data or command from
(tCYCR)
the LCD panel. It is the combination of the read low pulse width and the read high pulse width and the
transition between these states.
Write low pulse width
(tWL)
Time for which the WR signal must be low for a valid write system cycle time.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
9
Asynchronous Display Interfaces
Table 4. Timing Concepts (continued)
Write high pulse width
(tWH)
Time for which the WR signal must be high for a valid write system cycle time.
Read low pulse width
(tRL)
Time for which the RD signal must be low for a valid read system cycle time.
Read high pulse width
(tRH)
Time for which the RD signal must be high for a valid read system cycle time
Setup time for write
(tDCSW)
Time measured between the tCYCW initialization (RS) until the WR signal goes low.
Setup time for read
(tDCSR)
Time measured between the tCYCR initialization (RS) until the RD signal goes low.
Write signal fall time
(tWf)
Maximum acceptable time that the WR signal must spend in the transition from high-level to low-level
state. Most of the times, this value is ignored, and it is assumed that the i.MX LCD interface is able to
switch the signal at high speed.
Write signal rise time
(tWr)
Maximum acceptable time that the WR signal must spend in the transition from low-level to high-level
state. Most of the times, this value is ignored, and it is assumed that the i.MX LCD interface is able to
switch the signal at high speed.
Read signal fall time
(tRf)
Maximum acceptable time that the RD signal must spend in the transition from high-level to low-level
state. Most of the times, this value is ignored, and it is assumed that the i.MX LCD interface is able to
switch the signal at high speed.
Read signal rise time
(tRr)
Maximum acceptable time that the RD signal must spend in the transition from low-level to high-level
state. Most of the times, this value is ignored, and it is assumed that the i.MX LCD interface is able to
switch the signal at high speed.
Hold time for write
(tDCHW)
After the WR signal switches from low-level to high-level (write latch instruction), the address hold time
is the time that the RS signal needs to maintain in its current value (0 = command and 1 = Data).
Hold time for read
(tDCHR)
After the RD signal switches from low-level to high-level (write latch instruction), the address hold time
is the time that the RS signal needs to maintain in its current value (0 = command and 1 = Data).
Write data set up time
(tDS)
Time required to verify whether the data bus has the valid data before executing the write latch
instruction.
Write data hold time
(tDH)
Time required to verify whether the i.MX31 has the valid data on the bus after executing the write latch
instruction.
Read data delay time
(tRACC)
Time taken by the LCD to place the valid data on the bus after it receives the read start instruction (RD
transition from high-level to low-level).
Read data hold time
(tROH)
Time taken by the LCD to place the valid data on the bus after it receives the read latch instruction (RD
transition from low-level to high-level).
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
10
Freescale Semiconductor
Asynchronous Display Interfaces
Figure 7 shows the write cycle timing of the System-80 (Type 2) interface.
nCS
RS
nRD
nWR
DB[17:0],
DB[15:0]
Write register “index”
Read register “data”
Figure 7. Write Cycle Timing of the System-80 (Type 2) Interface
Figure 8 shows the read cycle timing of the System-80 (Type 2) interface.
RS
tDCSR
tDCHR
nCS
TRH
TRL
nRD
TRf
TRr
TRACC
Read Data
DB[17:0]
tCYCR
TROH
Valid Data
Figure 8. Read Cycle Timing of the System-80 (Type 2) Interface
3.4.3
Custom LCD Timing
This section describes the reset signal and its artifacts.
3.4.3.1
Reset
Many LCD panels include an LCD controller, which needs an external system reset. If the LCD uses the
reset signal, the timing regarding the pulse has to be found.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
11
Asynchronous Display Interfaces
Figure 9 shows the example of a reset signal.
T rRE S
VIH
T RE S
nRESET
V IL
Figure 9. Reset Signal Example
Table 5 provides the artifacts of the reset signal.
Table 5. Artifacts of Reset Signal
Parameter
Symbol
Minimum
Type
Maximum
Unit
Reset low-level width TRES
1
—
—
ms
Reset rise time
—
—
10
μs
TrRES
The important fact that can be observed is the reset signal is active low. This means that the reset signal
must be high while performing normal operations. The reset signal must be low for at least 15 ns to ensure
a valid reset. The reset pin is controlled by the i.MX31 General Purpose Input/Output (GPIO). It is
recommended not to use the RC circuit to generate the reset signal as it restricts the rising time of the signal
to 10 µs.
3.5
System Interface Data/Command Format
The data width is not the only characteristic of the data interface. Another important feature of the smart
panel is the Interface Data Format.
To explain this, the following example needs to be reviewed:
Consider that an RGB565 LCD is available and a 16-bit data bus width is used. The first step is to send all
the RGB data using one single transfer (16-bit data bus and one transfer per pixel) through the parallel data
bus and this approach is an appropriate way to do it.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
12
Freescale Semiconductor
Asynchronous Display Interfaces
Figure 10 shows the data format of the RGB565 LCD system interface.
Inter nal
DI RGB
data
R4
R3
R2
1s t Transfer
DB[15:0]
Pixel data on
LCD memory
R1
R0 D18 D17 D16 G5
G4 G3
G2
G1 G0 D9
D8 B4
B3
B2
R4
R3
R2
R1
R0
G5
G4 G3
G2
G1 G0
B4
B3
B2
B1
B0
R4
R3
R2
R1
R0
G5
G4 G3
G2
G1 G0
B4
B3
B2
B1
B0
B1
B0
D2 D1
D0
Figure 10. RGB565 16 Bit Data Bus, 1 Transfer Per Pixel System Interface Data Format
Now, suppose that this same LCD also supports RGB666 and an image is created based on this pixel depth.
It is evident that all the RGB data cannot be sent through the 16-bit data bus by using only one transfer
(i.MX31 data bus is 18-bit width maximum, but currently only 16 bits are used because LCD supports only
16-bit data transfer). For example, send all the red and green components in the first transfer and then send
the remaining two blue bits in the following transfer. Then, in the next transfer start over with the next
pixel.
Figure 11 shows the data format of the RGB666 LCD system interface.
Internal
DI RGB
data
R5
st
R4 R3
1 Transfer
DB[15:0]
Pixel data on
LCD memory
R2
R1 R0 D17 D16 G5 G4 G3 G2 G1 G0 D9
D8 B5 B4
R5
R4
R3 R2
R1
R0 G5 G4 G3 G2 G1 G0 B5
B4
B3 B2
R4
R5
R4
R3 R2
R1
R0 G5 G4 G3 G2 G1 G0 B5
B4
B3 B2
B3
B2 B1
D16
B1
B0
D2 B1
D1 D0
nd
B0 2 Transfer
DB[15:0]
B0
Figure 11. RGB666 16 Bit Data Bus, 2 Transfers Per Pixel System Interface Data Format
However, the LCD can request for a different system interface data format, where the dummy data has to
be sent in the first transfer and not in the second. Also, R5 and R4 must be placed in the most significant
bit (msb) of the data bus instead of the least significant bit (lsb).
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
13
Asynchronous Display Interfaces
Figure 12 shows the data format of the RGB666 LCD system interface.
Internal
DI RGB R5
data
st
1 Transfer
DB[15:0]
R4
R3 R2
R5 R4 D13
Pixel data on
LCD memory
D0
R4 R4
R5
R1
R0 D17 D16 G5 G4 G3 G2 G1 G0 D9 D8 B5
B4 B3
B2
R3
R2 R1
R0
G5 G4 G3 G2 G1 G0 B5 B4
B3
B2 B1
B0
R3
R2 R1
R0
G5 G4 G3 G2 G1 G0 B5 B4
B3
B2 B1
B0
B1 B0
D1 D0
nd
2 Transfer
DB[15:0]
Figure 12. RGB666 16 Bit Data Bus, 2 Transfers Per Pixel System Interface Data Format
Though Figure 11 and Figure 12 give the best performance regarding data transfers between the i.MX and
LCD, there are also other means to send this data. For example, each color component can be sent in a
single data transfer. First, send the six bits of the red component, then send the six green bits in the next
transfer, and then in the third transfer, send the remaining five bits of the blue component. After this
transfer, the process begins with the next pixel data.
Figure 13 shows the data format of the RGB666 LCD system interface.
Internal
DI RGB
data
1s t Transfer
DB[15:0]
D16
D8
R5
R5
R4
R3
R2
R1
R0 D17 D16 G5 G4
G3
G2 G1
G0 D9
2 nd Transfer
DB[15:0]
R4
R3
R2
R1
R0
Pixel data on
LCD memory
R4
R5
R4
R3
D16
R2
R1
D8
B5
B4
B3
B2
B1
B0
D1
D0
D8 B5
B4
B3
B2
B1
B0
B2
B0
3 rd Tra nsfer
DB[15:0]
D8
G5 G4
G3
G2 G1
G0
R0
G5 G4
G3
G2 G1
G0
D16
B5
B4
B3
B1
Figure 13. RGB666 16 Bit Data Bus, 3 Transfers Per Pixel System Interface Data Format
The same LCD supports more than one color depth (bits per pixel) and more than one system interface
data format. The system interface is selected using a specific pin or register configuration. If the system
interface is selected by a register, the question that arises is, how the data is sent before selecting the system
interface. This is possible because command and pixel data transfer system interface are not always the
same. The command interface can perform only one transfer per command, but the data transfer system
interface can perform two or three transfers per pixel.
3.6
LCD Panels Supported by the i.MX31
The i.MX31 can handle up to four displays at the same time.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
14
Freescale Semiconductor
Asynchronous Display Interfaces
Table 6 lists the various types of displays that are handled by the display controllers.
Table 6. Display Controllers and their Interfaces
Display
Display Type
Interface
DISP0
Asynchronous
Parallel interface only
DISP1
Asynchronous
Serial and parallel interface
DISP2
Asynchronous
Serial and parallel interface
DISP3
Synchronous
RGB interface (HSYNC, VSYNC, PIXCLK, upto RGB666)
3.6.1
Asynchronous Display Interface
The i.MX31 ADC can be configured to handle several types of devices and interfaces. The ADC is able
to support up to three smart displays simultaneously with time multiplexed access. The DISP1 and DISP2
provide parallel and serial display interfaces while DISP0 provides only the parallel interface.
The interfaces supported by the ADC are as follows:
• System-80 interface
— Type 1 (sampling with the chip select signal) with or without byte enable signals
— Type 2 (sampling with the read and write signals) with or without byte enable signals
• System 68 K interface
— Type 1 (sampling with the chip select signal) with or without byte enable signals
— Type 2 (sampling with the read and write signals) with or without byte enable signals
• Serial interfaces
— 3-wire (with bidirectional data line)
— 4-wire (with separate data input and output lines)
— 5-wire type 1 (with sampling RS by the serial clock)
— 5-wire type 2 (with sampling RS by the chip select signal)
For more details, refer to the Image Processing Unit chapter of the MCIMX31 and MCIMX31L Multimedia
Applications Processors Reference Manual (MCIMX31RM).
For parallel interfaces, the data bus is time multiplexed with DISP3 (synchronous interface) and with the
other parallel asynchronous interfaces. If there is a synchronous panel in the system, the asynchronous
displays can be accessed only when the i.MX31 does not send any data to the dumb display (implies back
and front porches). Based on this, it is observed that the bandwidth for parallel asynchronous LCDs are
limited by the synchronous panel frame rate, back porch, and front porch (both horizontal and vertical).
When the Synchronous Display Controller (SDC) or ADC communicates with one of the four displays
through the parallel interface, the Micro Controller Unit (MCU) is allowed to access another display
through the serial interface simultaneously.
The i.MX31 is able to support a wide variety of system data interfaces. In general, for System-80 type 2,
the i.MX31 supports data bus, whose width varies from 8 to 18 lines (DISPB_DATA [17:0]). The internal
Display Interface (DI) format for data and command is a 24-bit word which is divided into three byte
components (for a 16-bit word, eight zeros are added to the MSB from the ADC). Because of this, it is
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
15
Asynchronous Display Interfaces
always better to assume that the RGB888 is available internally and also assume that there are 24 bits
available for commands, even when the bits can be masked to 8 or 16 bits. This word can be either as an
output or input in one, two, or three of the display clock cycles. Due to this, the ADC is able to provide the
outputs—RGB565, RGB666, and RGB888 color depths and few other variations of color, which fits in the
24 bits. Another important feature of i.MX31 is that it has a separate system transfer configuration for both
commands and data.
It is important to mention the registers that are used to configure the system interface. For DISP0, the
registers used for data mapping are:
• DI_DISP0_DB0_MAP
• DI_DISP0_DB1_MAP
• DI_DISP0_DB2_MAP
• DI_DISP_ACC_CC
For command mapping, the registers used are:
•
•
•
•
DI_DISP0_CB0_MAP
DI_DISP0_CB1_MAP
DI_DISP0_CB2_MAP
DI_DISP_ACC_CC
For more details, refer to the Image Processing Unit chapter of the MCIMX31 and MCIMX31L Multimedia
Applications Processors Reference Manual (MCIMX31RM).
The examples available in Figure 10 to Figure 13 can be reviewed using proper values to gain more clarity.
Table 7 shows the i.MX31 register values for a RGB565 transfer per pixel system interface.
Table 7. i.MX31 Register Values for 16 Bit Data Interface RGB565 1 Transfer Per Pixel
OFFS0
OFFS1
OFFS2
M7
M6
M5
M4
M3
M2
M1
M0
Byte2 Red
15
0
0
3
3
3
0
0
0
0
0
Byte1 Green
10
0
0
3
3
0
0
0
0
0
0
Byte0 Blue
4
0
0
3
3
3
0
0
0
0
0
DISPX_IF_CLK_CNT_Y 0
The OFFS1 and OFFS2 columns are set to 0 because the data is packed and sent in a single transfer and
therefore, no data is sent in the second or third transfer. The OFFS0 determines how the color components
are ordered in the first transfer (clock cycle). Here, the MSB of blue component is located in D4 (five bits),
MSB of green component is located in D10 (6 bits) and MSB of red component is located in D15 (five
bits). Since RGB565 is used, masking can reflect the color depth by specifying which is the MSB (not
masked). The M5-M7 columns are always masked (3 implies masked) for red and blue components (five
bits) and for the green component, only the M7 and M6 columns are masked (six bits). The M0-M4
columns in the red and blue components and the M0-M5 columns in the green component are filled with
zeros because the data has to be enabled in the first clock cycle. The DISPX_IF_CLK_CNT_Y row is set
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
16
Freescale Semiconductor
Asynchronous Display Interfaces
to 0 (display clock cycles - 1) because only one transfer per pixel is used and therefore, only one clock
cycle is required.
NOTE
X in DISPX_IF_CLK_CNT_Y can be 0, 1, or 2 depending on which display
is selected, and Y can be C (command mapping) and D (data mapping).
Table 8 shows the i.MX31 register values for the RGB666 two transfer per pixel system interface.
Table 8. i.MX31 Register Values for 16 Bit Data Interface RGB666 2 Transfers Per Pixel
OFFS0
OFFS1
OFFS2
M7
M6
M5
M4
M3
M2
M1
M0
Byte2 Red
15
0
0
3
3
0
0
0
0
0
0
Byte1 Green
9
0
0
3
3
0
0
0
0
0
0
Byte0 Blue
3
5
0
3
3
0
0
0
0
1
1
DISPX_IF_CLK_CNT_Y 1
In this example, two transfers are required and so DISPX_IF_CLK_CNT_Y is set to one (number of clock
cycles - 1). Using OFFS0, the first cycle is set up, where the red (six bits) and green (six bits) components
are sent and hence, the red MSB is on D15 and the green MSB is on D9. Also, part of the blue component
is sent in the first transfer (four MSB bits) and hence, the blue MSB is on D3. In the second transfer, only
the remaining bits of the blue component is sent. Therefore, OFFS1 column contains only the blue offset,
which is placed on D5, so that B0 and B1 are placed in the LSB. The M6 and M7 columns are masked for
all colors (bytes), which imply that all color components are of six bits width. Using 0 or 1 in masks is
used to specify whether the bits are in the first cycle (0 = first transfer) or second cycle (1 = second
transfer).
Table 9 shows the i.MX31 register values for the RGB666 two transfer per pixel system interface.
Table 9. RGB666 16 Bit Data Bus, 2 Transfers Per Pixel System Interface Data Format
OFFS0
OFFS1
OFFS2
M7
M6
M5
M4
M3
M2
M1
M0
Byte2 Red
15
17
0
3
3
0
0
1
1
1
1
Byte1 Green
0
11
0
3
3
1
1
1
1
1
1
Byte0 Blue
0
5
0
3
3
1
1
1
1
1
1
DISPX_IF_CLK_CNT_Y 1
This example also requires two transfers and therefore, DISPX_IF_CLK_CNT_Y is set to one. Since
RGB666 is used, M6 and M7 columns must be masked (3) to indicate the color depth. In the first transfer,
only the two MSB of the red component are sent and so, red OFFS0 is 15. For the second transfer (OFFS1),
the blue component starts at D5 and the green component at D11, but the remaining red information has
an offset of 17 because the four least significant bits of the red component are sent using the lines,
D12-D15. The masks determine that only R5 and R4 have to be sent in the first transfer and all the other
bits are sent in the second cycle.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
17
Asynchronous Display Interfaces
Table 10 shows the i.MX31 register values for the RGB666 three transfer per pixel system interface.
Table 10. RGB666 16 Bit Data Bus, 3 Transfers Per Pixel System Interface Data Format
OFFS0
OFFS1
OFFS2
M7
M6
M5
M4
M3
M2
M1
M0
Byte2 Red
5
0
0
3
3
0
0
0
0
0
0
Byte1 Green
0
5
0
3
3
1
1
1
1
1
1
Byte0 Blue
0
0
5
3
3
2
2
2
2
2
2
DISPX_IF_CLK_CNT_Y 2
The DISPX_IF_CLK_CNT_Y row indicates that three transfer per pixel are required and masks determine
that the RGB666 is used. Here, the red component is sent in the first transfer (0), green component in the
second transfer (1), and blue component in the third transfer (2). The MSB’s of all the components are
placed on D5, and this is reflected in the offsets. (OFFS0 for red, OFFS1 for green, and OFSS2 for blue)
The same concept can be applied to the command interface by considering the byte0, byte1, and byte2
store command information instead of color information. For more details, refer to the Bus Mapping Unit
section in the MCIMX31 and MCIMX31L Multimedia Applications Processors Reference Manual
(MCIMX31RM).
3.7
Command and Template Mode
For asynchronous panels, the two types of display accesses for registers and data are—the command and
template mode. The command mode is used for initialization process and the template mode is used for
the frame buffer update. Once the interfaces have been configured, both modes generate all the signals to
write data or send commands to the smart panel.
3.7.1
Command Mode
The command mode is used for the initialization routine. In this mode, the asynchronous command
interface is set up with the desired characteristics by using the DI_DISP_LLA_CONF register:
• Display Interface (DISP0, DISP1, or DISP2)
• Data or command (RS polarity)
Write the command or data to be sent to the smart panel in the DI_DISP_LLA_DATA register. With these
two actions, the ADC sends the data or command from the DI_DISP_LLA_DATA register to the LCD in
one, two, or three transfers according to the system command configuration that is described in the
DI_DISP0_CB0_MAP, DI_DISP0_CB1_MAP, DI_DISP0_CB2_MAP, and DI_DISP_ACC_CC registers
(offsets and masks). If another command or data with the same configuration needs to be sent, write the
command or data again on the DI_DISP_LLA_DATA register.
The WINCE600 BSP provides a function where the low-level aspects such as DI_DISP_LLA_CONF and
DI_DISP_LLA_DATA are encapsulated in the ADCWriteCommand() function. It is important to mention that
the offsets and masks for the command system interface must be configured before using the
ADCWriteCommand() function. See the following example:
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
18
Freescale Semiconductor
Asynchronous Display Interfaces
Consider an interface where either the data (RS = 1) or command (RS = 0) is of 16-bit width. While using
an interface, first send the register address (command) and then the register contents (data) in order to
configure the register. Also, assume that the DISP0 16-bit width command is used with only one transfer
per command.
Figure 14 shows the 16 bit command one transfer per command system interface data format.
D23
D31
DI_DI SP_LLA_DATA
R0
Unused
Dummy data
1s t Transfer
DI_DISPB[15:0]
C15 C14 C13 C12 C11 C10 C9
C8
C7
C6
C5
C4
C3
C2
C1
C0
D15 D14 D13 D12 D11 D10 D9
D8
D7
D6
D5
D4
D3
D2
D1
D0
Figure 14. 16 Bit Command 1 Transfer Per Command System Interface Data Format
The following configuration shows that the DI_DISP_LLA_DATA byte0 and byte1 are sent to the display
during the first clock cycle. Byte2 is ignored because there is only one transfer per command
(DISP0_IF_CLK_CNT_C=0). Configure the interface before writing data to DI_DISP_LLA_DATA.
For more details, refer to the Memory Map and Register Definition section in the MCIMX31 and
MCIMX31L Multimedia Applications Processors Reference Manual (MCIMX31RM).
Table 11 shows the data format of the 16 bit command one transfer per command system interface.
Table 11. 16 Bit Command one Transfer Per Command System Interface (Refer Figure
OFFS0
OFFS1
OFFS2
M7
M6
M5
M4
M3
M2
14)
M1
M0
Byte2
0
0
0
3
3
3
3
3
3
3
3
Byte1
15
0
0
0
0
0
0
0
0
0
0
Byte0
7
0
0
0
0
0
0
0
0
0
0
DISP0_IF_CLK_CNT_C 0
3.7.2
Template Mode
The template mode is used for sending pixels to the LCD. Once the LCD is initialized, the display data on
the smart panel memory can be considered as an external memory where the i.MX31 display driver
modifies either some part of the content or the complete frame buffer. In this way, the driver attempts to
access only that memory and the ADC sets up all the signals in order to write those pixels in the smart
panel memory.
A template is a micro program that is executed every time when a data burst has to be written to or read
from a smart display. A typical structure of the template includes the following parts:
• Sending a pre-command sequence to the display.
• Sending an address to the display.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
19
Asynchronous Display Interfaces
•
•
•
•
Waiting for acknowledgement from the display or for the given number of display clocks and
waiting is required only for the read access.
Sending a data sequence to the display or receiving a data sequence from the display. This step is
repeated when addressing is sequential (refer to the Sequential Addressing Access section of the
MCIMX31 and MCIMX31L Multimedia Applications Processors Reference Manual
(MCIMX31RM).
Sending a post-command sequence to the display.
Depending on the access type (read or write) and access, the template structure can be varied. For
the sequential access (refer to the Sequential Addressing Access section of the MCIMX31 and
MCIMX31L Multimedia Applications Processors Reference Manual (MCIMX31RM), both
commands and addresses are not sent to the display. Therefore, templates are not used for the
sequential access. Two templates—read and write exists for each of the three displays and the
maximal template length is 32 commands.
There is no standard that specifies how this transfer is going to happen. For example, in the GiantPlus
GPM722A0 if the frame buffer contents has to be modified, send the X (pixel offset) and Y (line) position
of the pixel to the smart panel, by writing the addresses in the Graphics RAM (GRAM) horizontal (R20h)
and GRAM vertical address (R21h) registers, and then write the pixel contents in the R22h register (write
data to GRAM). After this operation, if the display interface writes again on the R22h register, the smart
panel stores the RGB data in the next pixel location and so on.
Even when the addresses of X and Y are set every time a pixel is referenced, the i.MX31 is able to
distinguish the continuous access and run only the address set up (R20h, R21h, and R22h). When a nonsequential access is referenced, the functionality needs to be configured in the i.MX31 IPU’s ADC_CONF
register. This helps to reduce the transfer per pixel in the display interface. For more details, refer to the
MCIMX31 and MCIMX31L Multimedia Applications Processors Reference Manual (MCIMX31RM).
3.7.2.1
Sending Pre-Command Sequence to the Display
There is no pre-command sequence for GiantPlus GPM722A0.
3.7.2.2
Sending an Address to the Display
The addresses to the GRAM horizontal/vertical address Set (R20h, R21h) registers need to be sent and the
template command for this is as follows:
1. Send the GRAM horizontal address set command to the register (R20h).
Figure 15 shows the GRAM horizontal address set command (R20h).
nCS0
RS
0
Flow
control
Step-bystep
Opcode
WR_CMND
Data
0x20 (HOR_GRAM_ADDR_SET)
RS
nWR
DB[15:0]
0x20
Figure 15. Horizontal Address Set Command
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
20
Freescale Semiconductor
Asynchronous Display Interfaces
2. Send the contents of the GRAM horizontal address to the register.
Figure 16 shows the contents of the GRAM horizontal address.
nCS0
RS
1
Flow
control
Opcode
Step-bystep
WR_XADDR
Data
RS
0x01 (send address bits [7:0])
nWR
DB[15:0]
Pixel X Addr
Because this LCD is 240 pixels width we need 8 bits
for X Addresses.
Figure 16. Contents of the GRAM Horizontal Address
3. Send the GRAM vertical address set command to the register (R21h).
Figure 17 shows the GRAM vertical address set command.
nCS0
RS
0
Flow
control
Opcode
Step-bystep
WR_CMND
Data
RS
0x21 ( VER_GRAM_ADDR_SET)
nWR
DB[ 15:0]
0x21
Figure 17. Vertical Address Set Command
4. Send the contents of the GRAM vertical address to the register.
Figure 18 shows the contents of the GRAM vertical address.
nCS0
RS
1
Flow
control
Step-bystep
Opcode
WR_YADDR
Data
RS
0x01 (send address bits [22:8])
nWR
DB[15:0]
Pixel Y Addr
Because this LCD is 240 pixels width we need 8 bits
for X Addresses. So Y address LSB is bit 8
Figure 18. Contents of the GRAM Vertical Address
5. Send the write data to the GRAM command (R22h).
Figure 19 shows sending of the write data to the GRAM command.
nCS0
RS
0
Flow
control
Step-bystep
Opcode
WR_CMND
Data
0x22 ( WR_DATA_TO_GRAM)
RS
nWR
DB[ 15:0]
0x22
Figure 19. Send Write Data to the GRAM Command
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
21
Display Configuration in WINCE 6.0
3.7.2.3
Sending a Data Sequence to the Display
Finally, send the pixel information to the panel.
Figure 20 shows sending of the pixel information to the panel.
nCS0
RS
Flow
control
1
Opcode
STOP
WR_DATA
Data
Not used
RS
nWR
DB[15:0]
Stop must be included in last
template command
Pixel data is taken from the
buffer memory
Pixel X,Y
Pixel X+1,Y
Pixel X+2,Y
After pixel 239, the index jumps to the
first pixel in the next line.
Figure 20. Sending Pixel Information to the Panel
3.7.2.4
Sending a Post-Command Sequence to the Display
There is no post-command sequence for GiantPlus GPM722A0.
It is observed that nearly six transfers are required for loading the initial pixel data, but if the sequential
access is used correctly, the total number of transfers can be reduced to one transfer per pixel.
4
Display Configuration in WINCE 6.0
LCD support is one of the most important features for any multimedia device. Display support enables the
device to have a Graphical user interface (GUI) and the possibility to become an entertainment artifact.
The graphic context is composed of several layers where the i.MX31 display interface is the final part in
the abstraction. All the ADC and display interface characteristics that are reviewed in previous sections
describe only how the i.MX31 sends the frame buffer to the panel. However, it is important to know who
is going to create the frames that need to be sent to the panel. If the screen is refreshed 60 times per second
(60 Hz), every line and every single pixel has to be created to maintain the coherence of the graphic
context.
The i.MX31 PDK BSP bases its display driver on the Display Driver Interface (DDI) defined by
Microsoft® for all WINCE600 devices. Implementing a driver using this model ensures the compatibility
of the hardware with the operating system. In other words, once WINCE is loaded and if the driver is
created using the MS model, the operating system handles the graphic context, providing all frames.
4.1
WINCE600 Display Driver Development Concepts
Display drivers are loaded and called directly by the graphics, windowing, and event subsystem, called
Gwes.exe. Drivers are most commonly written using a layered architecture because of the number of
hardware-independent operations.
The Graphics Primitive Engine (GPE) library handles the default drawing, acting as the display driver's
Model Device Driver (MDD) upper layer.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
22
Freescale Semiconductor
Display Configuration in WINCE 6.0
The user develops the hardware-specific code that corresponds to the display drivers lower layer, called
the Platform-Dependent Driver (PDD).
Table 12 shows the elements that constitute the Windows CE graphics pipeline.
Table 12. Elements of Windows CE Graphics Pipeline
Element
Description
Application
The application can be simple such as a Hello World application or complex such as a three-dimensional
engineering application.
Whichever it is, the application calls GDI functions. Coredll.dll exposes these functions.
Coredll.dll
The major set of functions is exposed through a single DLL, called Coredll.dll.
In most cases, this library does not perform the work. Instead, the library packages the parameters for the
function call and then triggers a Local Procedure Call (LPC) to another process.
The specific process depends on the function call. All drawing and windowing calls are sent to Gwes.exe.
Gwes.exe
The Graphics, Windowing, and Events Subsystem (GWES) is responsible for all graphical output and all
interactions with the user.
The drivers that reside in the GWES address space include display drivers, printer drivers, keyboard drivers,
mouse drivers, and touch screen drivers.
Ddi.dll
The default name for the display driver is Ddi.dll. As with most DLLs, Ddi.dll communicates through exported
functions.
Ddi.dll exports only the DrvEnableDriver function, which returns a pointer to an array of 27 function pointers
to the caller. When GWES requires a display driver, it calls one of the 27 functions.
Writing a device driver involves writing the code for the 27 functions.
Three of these functions are specific to printer drivers, which leaves 24 for the display driver developer.
Hardware
The graphic pipeline ends at the hardware. The display driver communicates to the hardware using the
mechanism required by the hardware.
This process typically involves a combination of memory-mapped video buffers and I/O registers.
Figure 21 shows the Windows CE graphics architecture.
Figure 21. Windows CE Graphics Architecture
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
23
Display Configuration in WINCE 6.0
More details can be found under Display Drivers (Developing a Device Driver > Windows CE Drivers >
Display Drivers) topic of Platform Builder for Microsoft® Windows CE 5.0 help.
It is important to mention that developing a WINCE Display driver from scratch implies a considerable
effort and knowledge, specially the WINCE architecture. Freescale provides the i.MX31 display driver for
asynchronous displays in the WINCE600 BSP. The i.MX31 Windows CE 6.0 BSP display driver is based
on the Microsoft® DirectDraw Graphics Primitive Engine (DDGPE) classes and supports the Microsoft®
DirectDraw interface. This driver combines the functionality of a standard LCD display with DirectDraw
support and the display driver interfaces with IPU. This driver supports more than one panel which can be
selected by using the Windows Register. The support for a new asynchronous panel can be added using
the procedure described in the following section.
4.2
Adding Support for a New LCD Panel
The following sections describes the procedure used to add the support for a new asynchronous panel.
4.2.1
Identify LCD Characteristics and Timing
To add the support for a new System-80 smart panel for the i.MX31 BSP, ensure that this panel is
compatible with the i.MX31. The panel must have the following interface characteristics:
— Asynchronous display (smart display)
— System-80 Type 2 (sampling with the read and write signals) interface
— Resolution not greater than SVGA
Once a compatible LCD panel is selected, it is important to find the timing and system data interface
characteristics of the display. Following tables are related to the GPM722A0 display.
Table 13 shows the artifacts of the GPM722A0 display.
Table 13. Artifacts of the GPM722A0 Display
Parameter
Symbol
Value
Display Interface
DI
System-80 Type 2 (sampling with the read and write signals)
Burst Mode
BRSTM
Parallel interface burst mode
Data Polarity
DEP
Straight
Chip Select Polarity
CSPOL
Active low
Register Select (PAR_RS) Polarity
RSPOL
Straight polarity
Write Signal Polarity
WRPOL
Active low
Read Signal Polarity
RDPOL
Active low
Color Depth (bits per pixel)
BPP
16(RGB565)/18(RGB666) bits (configurable)
System interface data format
DFMT
One or two transfer per pixel depending on color depth, one transfer per
command
LCD width
HDISP
240 pixels
LCD height
VDISP
320 lines
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
24
Freescale Semiconductor
Display Configuration in WINCE 6.0
Table 14 also shows the artifacts of the GPM722A0 display.
Table 14. Artifacts of the GPM722A0 Display
Parameter
Symbol
Minimum
Type
Maximum
Unit
Write Cycle Time
tCYCW
100
—
—
ns
Read Cycle Time
tCYCR
300
—
—
ns
Write Low Pulse Width
tWL
50
—
500
ns
Write High Pulse Width
tWH
50
—
—
ns
Read Low Pulse Width
TRL
150
—
—
ns
Read High Pulse Width
TRH
150
—
—
ns
Setup Time for Write
TDCSW
10
—
—
ns
Setup Time for Read
TDCSR
5
—
—
ns
Write Signal Fall Time
TWF
—
—
25
ns
Write Signal Rise Time
TWR
—
—
25
ns
Read Signal Fall Time
TRF
—
—
25
ns
Read Signal Rise Time
TRF
—
—
25
ns
Hold Time for Write
TDCHW
15
—
—
ns
Hold Time for Read
TDCHR
5
—
—
ns
Write Data set up Time
TDS
10
—
—
ns
Write Data Hold Time
TDH
15
—
—
ns
Read Data Delay Time
TRACC
—
—
100
ns
Read Data Hold Time
TROH
5
—
—
ns
Note: Check if these values are same as the PANEL_INFO structure.
More details on how to deduce these values from the LCD data sheet can be found in the Section 1,
“Overview of i.MX31 Display,” to Section 3, “Asynchronous Display Interfaces,” of this application note.
4.2.2
i.MX31 WINCE600 PDK LCD Driver Initialization Flow
The following snippet represents the WINCE600 PDK LCD driver initialization flow:
DDIPU::DDIPU()
+ DDIPU::Init()
+ DDIPU::SetupVideoMemory()
+ Set up the memory for video.
+ video memory size comes from a constant in image_cfg.h
+ IMAGE_WINCE_IPU_RAM_PA_START
+ InitHardware()
+ DDKClockSetpointRequest() - HSP_CLK = 132 MHz
+ BSPInitializeLCD(eIPU_ADC) - GiantPlusInitializeLCD()
+ Configure Reset pin as GPIO: LCS1, MCU3_24
+ LCD_RESET_GPIO_PIN=1
+ InitializeADC()
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
25
Display Configuration in WINCE 6.0
+ Configure ADC and DI: IPU_CONF, IPU_CHA_DB_MODE_SEL, IPU_CHA_CUR_BUF,
DI_DISPx_DB0_MAP, DI_HSP_CLK_PER, ADC_CONF
+ _init_dma()
+ CreateTemplate()
+ ReadTemplateMemory()
+ ADCSetSrcBuffer()
+ BSPEnableLCD(eIPU_ADC) - GiantPlusEnableLCD()
+ PmicVoltageRegulatorOn(VMMC1); VMMC1 = 2.8 V
+ PmicVoltageRegulatorOn(VGEN); VGEN = 2.8 V
+ BSPDisplayIOMUXEnable() - GiantPlusDisplayIOMUXEnable()
+ Configure LCD pins: LD0-17, LCS0, PAR_RS, WRITE, READ, etc)
+ BSPResetLCD(eIPU_ADC) - GiantPlusResetLCD()
+ LCD_RESET_GPIO_PIN=0
+ Sleep(3000)
+ LCD_RESET_GPIO_PIN=1
+ ADCEnableModules()
+ Enable DI
+ Enable ADC
+ Startup Command Sequence
ADCWriteCommand() - GiantPlusWriteRegister(
+ EnableADC()
+ Enable DI
+ Enable ADC
+ DDIPU::AdvertisePowerInterface()
The LCD driver is initialized in the DDIPU_SDC::DDIPU_SDC() function. The video memory size is not taken
from the registry, because this value is a constant (IMAGE_WINCE_IPU_RAM_SIZE) declared in the
image_cfg.hc file. Panel type, rotation parameters, pixel depth, and TV modes supported by the platform
are extracted from the registry (platform.reg file). Based on the selected panel, the driver notifies the
WINCE display properties such as width, height, bits per pixel, and so on. The GPEMode data is
automatically set by using the PANEL_INFO structure of the current panel. With this information, WINCE
graphic context creates the frame buffers in the width, height, and format required by the LCD, which is
to be displayed on the screen. The information regarding the GPEMode must also be modified to complete
the support for the new LCD. The width and height must be provided in the natural orientation of the LCD.
The next step is the hardware initialization. Here, the IPU registers are configured to enable the ADC and
DI for working with the selected panel. The LCD timing features are not stored in registers, but are located
in the array PANEL_INFO g_ADCPanelArray[numPanel] placed in the
WINCE600\PLATFORM\iMX313DS\SRC\DRIVERS\IPU\ADC\adc.c file. So, to add the support for a new panel, this
array must be updated by adding another PANEL_INFO structure with the panel timing information. The
IDMAC ADC channels are configured, and the IOMUX is also configured to enable the LCD pin interface
(LD0-LD17, LCS0, PAR_RS, WRITE, READ, and so on). Then using bspdisplay.cpp, the driver
configures the specific LCD panel pins for initialization which includes reset and other enable pins that
are required. At the end of the process, the power levels for LCD are enabled, the panel is reset and all
initialization commands are sent to the LCD panel.
4.2.3
i.MX31 WINCE600 PDK LCD Display Interface Related Files
The files related to the i.MX31 WINCE600 PDK LCD display are contained in the following locations:
WINCE600\PLATFORM\iMX313DS\SRC\INC\adc.h
WINCE600\PLATFORM\iMX313DS\SRC\DRIVERS\IPU\ADC\adc.c
WINCE600\PLATFORM\iMX313DS\SRC\DRIVERS\IPU\DISPLAY\COMMON\ddipu.cpp
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
26
Freescale Semiconductor
Display Configuration in WINCE 6.0
WINCE600\PLATFORM\iMX313DS\SRC\DRIVERS\IPU\DISPLAY\COMMON\ddipu_cursor.cpp
WINCE600\PLATFORM\COMMON\SRC\SOC\FREESCALE\MXARM11_FSL_V1\IPU\INC\ipu.h
WINCE600\PLATFORM\iMX313DS\SRC\DRIVERS\IPU\DISPLAY\DLL\bspdisplay.cpp
WINCE600\PLATFORM\iMX313DS\FILES\platform.reg
WINCE600\PLATFORM\COMMON\SRC\SOC\FREESCALE\PMIC\MC13783_FSL_V1\INC\pmic_regulator.h
WINCE600\PLATFORM\iMX313DS\SRC\INC\bsp_cfg.h
4.2.4
i.MX31 PDK LCD Structures
It is important to understand how and where the information related to the LCD panel settings (see
Section 4.2, “Adding Support for a New LCD Panel,”) are stored because the communication channel is
used to inform the Asynchronous LCD driver about the settings for the new LCD display. PANEL_INFO,
which contains ADC_IPU_DI_SIGNAL_CFG and SDC_IPU_DI_SIGNAL_CFG is the structure that needs to be
changed in order to add the support for a new panel. The g_ADCPanelArray[] array in adc.c file is the
global array that stores the PANEL_INFO for all supported smart displays (Toshiba, Epson, and so on). To
modify the driver, it is recommended to add a new entry at the end of the structure with the new
PANEL_INFO structure.
4.2.4.1
PANEL_INFO
is the main structure for the LCD timing and features. It also contains two structures related to
the signal polarity. The ADC_IPU_DI_SIGNAL_CFG is used for asynchronous displays. Alternatively, the
SDC_IPU_DI_SIGNAL_CFG describes the polarities and characteristics of the RGB interface.
PANEL_INFO
struct PANEL_INFO_ST {
PUCHAR NAME;
IPU_PANEL_TYPE TYPE;
IPU_PIXEL_FORMAT PIXEL_FMT;
INT MODEID;
INT WIDTH;
INT HEIGHT;
INT FREQUENCY;
INT VSYNCWIDTH;
INT VSTARTWIDTH;
INT VENDWIDTH;
INT HSYNCWIDTH;
INT HSTARTWIDTH;
INT HENDWIDTH;
INT RD_CYCLE_PER; // in ns
INT RD_UP_POS; // in ns
INT RD_DOWN_POS; // in ns
INT WR_CYCLE_PER; // in ns
INT WR_UP_POS; // in ns
INT WR_DOWN_POS; // in ns
INT PIX_CLK_FREQ; // in Hz
INT PIX_DATA_POS; // in ns
ADC_IPU_DI_SIGNAL_CFG ADC_SIG_POL;
SDC_IPU_DI_SIGNAL_CFG SDC_SIG_POL;
};
typedef struct PANEL_INFO_ST PANEL_INFO;
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
27
Display Configuration in WINCE 6.0
Table 15 provides the description of each element in the PANEL_INFO structure.
Table 15. PANEL_INFO Structure Elements
Data Type
Variable Name
Description
Symbol
Unit
PUCHAR
NAME
Name of the panel
—
—
IPU_PANEL_TYPE
TYPE
Index of the panel type 1
—
—
IPU_PIXEL_FORMAT PIXEL_FMT
Pixel format 2
BPP
bit
INT
MODEID
Mode ID 3
—
ns
INT
WIDTH
Active frame width
VDISP
pixel
INT
HEIGHT
Active frame height
HDISP
line
INT
FREQUENCY
Refresh rate
FV
Hz
INT
VSYNCWIDTH
Not used by smart panels
—
—
INT
VSTARTWIDTH
Not used by smart panels
—
—
INT
VENDWIDTH
Not used by smart panels
—
—
INT
HSYNCWIDTH
Not used by smart panels
—
—
INT
HSTARTWIDTH
Not used by smart panels
—
—
INT
HENDWIDTH
Not used by smart panels
—
—
INT
RD_CYCLE_PER
Read cycle period
tCYCR
ns
INT
RD_UP_POS
Read up position
TRH
ns
INT
RD_DOWN_POS
Read down position
TRL
ns
INT
WR_CYCLE_PER
Write cycle period
tCYCW
ns
INT
WR_UP_POS
Write up position
tWH
ns
INT
WR_DOWN_POS Write down position
tWL
ns
INT
PIX_CLK_FREQ
Pixel clock frequency [4]
—
—
INT
PIX_DATA_POS
Pixel data position [5]
—
—
1
The enum on this data field is used by adc.c file to distinguish the proper timing settings between the supported displays
(LCD, NTSC TV, and PAL TV) when the selected display is being loaded. The ipu.h header file contains IPU_PANEL_TYPE.
2 There are three different RGB pixel formats, RGB565, RGB666, and RGB888. By selecting one of these formats, the ADC’s
interpretation of the frame buffer data can be specified.
3
For LCD panels, use DISPLAY_MODE_DEVICE as MODEID. Two other supported modes are also available, but those values
belong to the TV out functionality.
4.2.4.2
ADC_IPU_DI_SIGNAL_CFG
The following snippet represents the bit fields of the ADC display interface signal polarities:
// Bitfield of ADC Display Interface signal polarities
typedef struct {
UINT32 DISP_NUM :2;
UINT32 DISP_IF_MODE:2;
UINT32 DISP_PAR_BURST_MODE:2;
UINT32 DATA_POL :1;
// true = inverted
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
28
Freescale Semiconductor
Display Configuration in WINCE 6.0
UINT32 CS_POL :1;
UINT32 PAR_RS_POL
:1;
UINT32 WR_POL
:1;
UINT32 RD_POL :1;
UINT32 VSYNC_POL :1;
UINT32 SD_D_POL :1;
UINT32 SD_CLK_POL :1;
UINT32 SER_RS_POL :1;
UINT32 BCLK_POL :1;
UINT32 Dummy
:16;
} ADC_IPU_DI_SIGNAL_CFG;
//
//
//
//
//
//
//
//
//
//
true = active high
true = inverse
true = active high
true = active high
true = active high
true = inverse
true = inverse
true = inverse
true = inverted
Dummy variable for alignment.
Table 16 provides the name and description of the ADC display interface bit fields.
Table 16. ADC Display Interface Bit Fields
Offset
Bit-Field Name
Description
0
DISP_NUM
Display number1
2
DISP_IF_MODE
Display interface mode 2
Symbol
—
4
DISP_PAR_BURST_MODE
Bust mode for parallel interfaces
5
DATA_POL
Data polarity 4
—
3
—
DEP
5
6
CS_POL
Chip select polarity
7
PAR_RS_POL
Parallel register strobe (REG/Data) polarity 6
CSPOL
7
8
WR_POL
Write signal polarity
9
RD_POL
Read signal polarity 8
RSPOL
WRPOL
RDPOL
9
10
VSYNC_POL
VSYNC polarity (not used in GPM722A0)
11
SD_D_POL
Data polarity for serial interface (not used in parallel)
—
12
SD_CLK_POL
Clock polarity for serial interface (not used in parallel)
—
13
SER_RS_POL
Register polarity for serial interface (not used in parallel)
—
14
BCLK_POL
Burst clock polarity [10]
—
15
Dummy
Dummy data for memory alignment
—
1
2
3
4
5
6
7
—
Display number refers to the i.MX31 display that is used for this interface. For parallel interfaces (System-80 Type 2), DISP0,
DISP1, or DISP3 can be used. Since this option is available, DISP0 (IPU_ADC_DISPLAY_0) can be selected.
There are seven different types of interfaces supported by the i.MX31, but this application note uses only the
IPU_DI_DISP_IF_CONF_IF_MODE_SYSTEM80_TYPE2 (0x01) interface, which is defined in the mxarm11_ipu.h file.
The burst access mode must be IPU_DI_DISP_IF_CONF_PAR_BURST_MODE_BURST_CS for the GiantPlus GPM722A0.
Data polarity must be straight (IPU_DI_DISP_SIG_POL_DATA_POL_STRAIGHT). If required, invert the signals in the data
bus (used only for B/W displays).
When the CS signal goes low to indicate it is active, the polarity of the CS_POL must be
IPU_DI_DISP_SIG_POL_CS_POL_ACTIVE_LOW. Active low is the most common configuration for this signal. However, the
CS_POL can also be IPU_DI_DISP_SIG_POL_CS_POL_ACTIVE_HIGH at times.
Setting PAR_RS_POL to IPU_DI_DISP_SIG_POL_PAR_RS_POL_STRAIGHT implies low for commands and high for data in
most common configuration. Additionally, IPU_DI_DISP_SIG_POL_PAR_RS_POL_INVERSE can be used if the interface
requires a configuration, which is HIGH for commands and LOW for data.
Write signal polarity is IPU_DI_DISP_SIG_POL_CS_POL_ACTIVE_LOW, which implies that the signal is active when it goes
low. If the LCD requires, the IPU_DI_DISP_SIG_POL_CS_POL_ACTIVE_HIGH can also be used.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
29
Display Configuration in WINCE 6.0
8
Read signal polarity is IPU_DI_DISP_SIG_POL_WR_POL_ACTIVE_LOW, which implies that the signal is active when it goes
low. Active Low is the most common configuration for this signal, similar to the Chip select and Write signal. The
IPU_DI_DISP_SIG_POL_WR_POL_ACTIVE_HIGH configuration is also available for rest of the cases.
9
VSYNC_POL refers to the polarity of VSYNC signal, which is used in some of the smart panels to synchronize the writings.
But, in the case of GPM722A0, the module does not provide this signal and therefore, this polarity can be ignored in this driver.
Additionally, if this signal is not available, the driver must be configured in order to ignore this synchronization. This is done by
setting an environmental variable (BSP_ADC_ENABLE_TEARING_PREVENTION) in the bsp_cfg.h header file to false.
4.2.4.3
SDC_IPU_DI_SIGNAL_CFG
The following snippet represents the bit fields of the SDC display interface signal polarities:
// Bitfield of SDC Display Interface
typedef struct {
UINT32 DATAMASK_EN:1;
UINT32 CLKIDLE_EN :1;
UINT32 CLKSEL_EN :1;
UINT32 VSYNC_POL :1;
UINT32 ENABLE_POL :1;
UINT32 DATA_POL
:1;
UINT32 CLK_POL
:1;
UINT32 HSYNC_POL :1;
UINT32 Dummy
:24;
} SDC_IPU_DI_SIGNAL_CFG;
signal polarities.
//
//
//
//
true = inverted
true = rising edge
true = active high
Dummy variable for alignment.
This structure is not used for asynchronous display panels and therefore, all these bitfields can be set to
zero.
4.2.4.4
GPEMode
The following code snippet provides the GPEMode structure:
// STRUCT GPEMode
//
// This structure describes a display mode.
struct GPEMode
{
int
modeId;
int
width;
int
height;
int
Bpp;
int
frequency;
EGPEFormat
format;
};
The GPEMode structure is used to communicate to the WINCE graphics engine, the size and format of the
screen. Using this information, the OS creates the frame in an appropriate size (required by the i.MX31),
which is to be processed and sent to the panel using the display interface.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
30
Freescale Semiconductor
Modifying the BSP
Table 17 provides the description of each element in the GPEMode structure.
Table 17. GPEMode Structure Elements
Data Type
Variable Name
Description
Symbol
Unit
int
modeId
Display or TV modes 1
—
—
int
Width
Active frame width
VDISP
pixel
int
Height
Active frame height
HDISP
line
int
Bpp
Bits per pixel 2
BPP
bit
int
Frequency
Screen refresh rate
FV
Hz
int
Format
EGPEFormat enum 3
—
—
1
Display mode can be either DISPLAY_MODE_DEVICE or DISPLAY_MODE_NTSC.
The mode must be set to DISP_BPP, whose value is 16.
3 This field represents the bits per pixel of the GPE frames and it takes any of the following values.
2
It is important to mention that the i.MX31 supports maximum of 18 bits as the display interface width. If
more than 18 bits are used as BPP, the less significant bits are discarded when they are sent to the LCD.
Due to this reason, the recommended values for this field are gpe16Bpp and gpe24Bpp.
enum EGPEFormat
{
gpe1Bpp,
gpe2Bpp,
gpe4Bpp,
gpe8Bpp,
gpe16Bpp,
gpe24Bpp,
gpe32Bpp,
gpe16YCrCb,
gpeDeviceCompatible,
gpeUndefined
};
In WINCE600, GPEMode is automatically set by the ADC driver.
5
Modifying the BSP
To add support for the i.MX31 PDK WINCE600 BSP, perform the following steps:
1. Modify the catalog
2. Modify the platform.reg file
3. Modify the platform.bib file
4. Set up the power LCD voltages
5. Set up the reset signal
6. Set up the backlight
7. Configure wait for VSYNC signal
8. Add a panel type enum for the new LCD
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
31
Modifying the BSP
9. Create the PANEL_INFO entry for the new LCD
10. Configure data and command system interface
11. Write initialization command routine
12. Create a template for the frame buffer write access
13. Add the mouse support for asynchronous displays
14. Rebuild the project
For example, consider the Giantplus GPM722A0 LCD panel. This smart panel is a multi-color depth
RGB565/RGB666, which uses the System-80 interface with 16-bit width transfers. But, choose RGB565
one transfer per pixel for the final implementation. Figure 5 and Figure 6 show how to read and write
from/to the LCD memory/registers. Also, Figure 10 and Figure 14 show the data and command system
interface transfers.
5.1
Modifying the WINCE600 Catalog
The WINCE600 catalog is changed by using the Microsoft® Visual Studio. The procedure to modify the
WINCE600 catalog using the Microsoft® Visual Studio is as follows:
1. If the i.MX313dsmobility project is open, click File > Close Solution to close the project.
2. Click File > Open > File to open the catalog file under
WINCE600\PLATFORM\iMX313DS\CATALOG folder.
Figure 22 shows the catalog file.
Figure 22. Opening the Catalog File
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
32
Freescale Semiconductor
Modifying the BSP
3. Create a new entry for the GiantPlus display under Catalog > Third Party > BSP > Freescale
i.MX31 3DS: ARMV4I > Device Drivers > Display folder. Right click the Display folder and
select Add Catalog Item as shown in Figure 23.
Figure 23. Adding a New Catalog Item
4. Modify the properties of the catalog item as listed in Table 18.
Table 18 shows the modification of the properties of the newly added catalog item.
Table 18. Modifying the Catalog Item Properties
Properties
Value
Description
IPU ADC display driver GIANTPLUS GPM722A0
Title
GIANTPLUS GPM722A0(QVGA)
Additional Variables
BSP_DISPLAY_GIANTPLUS_GPM722A0
BSP_PP
Modules
ddraw_ipu.dll
Choose One Group
True
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
33
Modifying the BSP
As shown in Figure 24, all the other properties must have the default value.
Figure 24. Catalog Item Properties
5. Click OK on variables collection message box. Save and close the file. Open the
i.MX313dsmobility project, and then refresh the catalog by using the button on the top of the
catalog items view.
When the i.MX313dsmobility project in the Visual Studio is opened again, it is observed that the catalog
is changed as the GiantPlus display entry is also available in the catalog. Since the platform.bib and
platform.reg files has to be modified, the GPM722A0 entry is excluded from the build.
Also, comment out the BSP_DISPLAY_EPSON_L4F00242T03 = 1 entry in the imx313ds.bat file under
the \WINCE\PLATFORM\iMX313DS folder because this flag includes the Epson display unconditionally.
@REM For Display and Smart backlight support.
@REM set BSP_DISPLAY_EPSON_L4F00242T03=1
5.2
Platform.reg
Open the platform.reg file and add the register configuration settings for the new panel. Search all the
BSP_DISPLAY_EPSON_L4F00242T03 entries and add another OR condition for the GiantPlus display.
HKEY_LOCAL_MACHINE\Drivers\Display\DDIPU must be unique for each display.
;-----------------------------------------------------------------------------; IPU Display Driver
;
#if (defined BSP_CAMERA || defined BSP_PP || defined BSP_DISPLAY_EPSON_L4F00242T03 || defined
BSP_DISPLAY_GIANTPLUS_GPM722A0 || defined BSP_MBX)
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IPU_BASE]
"Prefix"="IPU"
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
34
Freescale Semiconductor
Modifying the BSP
"Dll"="ipu_base.dll"
"Order"=dword:1
"Index"=dword:1
#endif // (defined BSP_CAMERA || defined BSP_PP || defined BSP_DISPLAY_EPSON_L4F00242T03 ||
defined BSP_DISPLAY_GIANTPLUS_GPM722A0 || defined BSP_DISPLAY_SHARP_LQ035Q7DB02 || defined
BSP_MBX)
#if (defined BSP_DISPLAY_EPSON_L4F00242T03 || defined BSP_DISPLAY_GIANTPLUS_GPM722A0 || defined
BSP_DISPLAY_SHARP_LQ035Q7DB02)
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
"Display"="ddraw_ipu.dll"
"Order"=dword:10
...
IF BSP_DISPLAY_GIANTPLUS_GPM722A0
[HKEY_LOCAL_MACHINE\Drivers\Display\DDIPU]
"Bpp"=dword:10
"VideoBpp"=dword:10
"PanelType"=dword:7
; 16bpp
; RGB565
; GiantPlus QVGA smart panel
ENDIF
...
#endif // (defined BSP_DISPLAY_EPSON_L4F00242T03 || defined BSP_DISPLAY_GIANTPLUS_GPM722A0 ||
defined BSP_DISPLAY_SHARP_LQ035Q7DB02)
5.3
Platform.bib
The platform.bib file determines the files that are to be included in the image. For the display driver, the
ddraw_ipu.dll and ipu_base.dll files has to be included and the platform.bib entries must be updated.
Also, the BSP_DISPLAY_GIANTPLUS_GPM722A0 variable must be set.
IF BSP_NODISPLAY !
#if (defined BSP_DISPLAY_EPSON_L4F00242T03 || defined BSP_DISPLAY_GIANTPLUS_GPM722A0 || defined
BSP_DISPLAY_SHARP_LQ035Q7DB02)
ddraw_ipu.dll $(_FLATRELEASEDIR)\ddraw_ipu.dll
NK SHK
#endif
ENDIF ; BSP_NODISPLAY !
; ----------------------------------------------------------------------------; IPU Common Driver
;
#if ( defined BSP_CAMERA || defined BSP_PP || defined BSP_DISPLAY_EPSON_L4F00242T03 || defined
BSP_DISPLAY_GIANTPLUS_GPM722A0 || defined BSP_DISPLAY_SHARP_LQ035Q7DB02 || defined BSP_MBX )
ipu_base.dll
$(_FLATRELEASEDIR)\ipu_base.dll
NK SHK
#endif
; -----------------------------------------------------------------------------
After the platform.reg and platform.bib files are modified, perform a build using the current BSP and
subprojects.
5.4
Setting Up the Power LCD Voltages
Before connecting any LCD panel to the i.MX31 PDK, it is important to verify if the LCD can be powered
with the proper supply voltages and also if the display data interface has the correct value. Power settings
are handled by the ATLAS PMIC and during its initialization, the display driver must configure the PMIC
settings in order to set up the power voltage configuration. Unlike EPSON display (L4F00242T03), which
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
35
Modifying the BSP
uses 1.8 V, the GiantPlus display uses 2.8 V (LCD_VIO) for connection. The voltage settings can be
modified using the BSPEnableLCD() function in the bspdisplay.cpp file. The PMIC settings can also be
modified using the pmic_regulator.h file because the 2.8 V enumeration for VGEN has not been declared.
pmic_regulator.h
typedef enum _MC13783_REGULATOR_VREG_VOLTAGE_VGEN{
VGEN_1_20V = 0,
//output 1.20V,
VGEN_1_30V,
//output
1.30V,
VGEN_1_50V,
//output
1.50V,
VGEN_1_80V,
//output
1.80V,
VGEN_1_10V,
//output
1.10V,
VGEN_2_00V,
//output
2.00V
VGEN_2_80V,
//output
2.775V
VGEN_2_40V,
//output
2.40V,
} MC13783_REGULATOR_VREG_VOLTAGE_VGEN;
bspdisplay.cpp
BOOL BSPEnableLCD(IPU_DRIVE_TYPE dispType)
{
....
switch (dispType)
{
case eIPU_SDC:
...
break;
case eIPU_ADC:
{
PMIC_REGULATOR_VREG_VOLTAGE voltage;
PmicVoltageRegulatorOn(VMMC1);
PmicVoltageRegulatorOn(VGEN);
voltage.vmmc = VMMC_6; //2.8V
PmicVoltageRegulatorSetVoltageLevel(VMMC1, voltage);
voltage.vgen = VGEN_2_80V;
PmicVoltageRegulatorSetVoltageLevel(VGEN, voltage);
Sleep(100);
}
.....
break;
}
}
5.5
Setting Up the Reset Signal
Many synchronous and asynchronous displays require a reset signal and it is recommended that this signal
must be controlled by the microprocessor. For GPM722A0, the reset signal is controlled by the i.MX31
GPIO MCU3_24 (LCS1). Due to this reason, during initialization, this pin needs to be configured as GPIO.
The reset pin is configured using the BSPInitializeLCD() function in the bspdisplay.cpp file:
BOOL BSPInitializeLCD(IPU_DRIVE_TYPE dispType)
{
...
switch (dispType)
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
36
Freescale Semiconductor
Modifying the BSP
{
case eIPU_ADC:
// Reset pin:LCS1, MCU3_24
DDKIomuxSetPinMux(DDK_IOMUX_PIN_LCS1, DDK_IOMUX_OUT_GPIO,
DDK_IOMUX_IN_GPIO);
DDKIomuxSetPadConfig(DDK_IOMUX_PAD_LCS1, DDK_IOMUX_PAD_SLEW_SLOW,
DDK_IOMUX_PAD_DRIVE_NORMAL, DDK_IOMUX_PAD_MODE_CMOS, DDK_IOMUX_PAD_TRIG_SCHMITT,
DDK_IOMUX_PAD_PULL_UP_100K);
DDKGpioSetConfig(DDK_GPIO_PORT3, LCD_RESET_GPIO_PIN, DDK_GPIO_DIR_OUT,
DDK_GPIO_INTR_NONE);
DDKGpioWriteDataPin(DDK_GPIO_PORT3, LCD_RESET_GPIO_PIN, 1);
break;
case eIPU_SDC:
...
break;
}
The reset pulse is active low and it is created by setting the LCD_RESET_GPIO_PIN variable in the
BSPEnableLCD() function:
BOOL BSPEnableLCD(IPU_DRIVE_TYPE dispType)
{
....
switch (dispType)
{
case eIPU_SDC:
...
break;
case eIPU_ADC:
.....
//Reset LCD module, MCU3_24, LOW active
DDKGpioWriteDataPin(DDK_GPIO_PORT3, LCD_RESET_GPIO_PIN, 0);
Sleep(100);
DDKGpioWriteDataPin(DDK_GPIO_PORT3, LCD_RESET_GPIO_PIN, 1);
Sleep(100);
.....
break;
}
}
5.6
Setting Up the Backlight
The backlight must be turned ON because the contents on the LCD panel can be viewed only when the
backlight is ON. Also, the backlight must be turned ON before continuing with the display driver
development.
In this example, initialize the keypad backlight, which is the ATLAS line that handles the GiantPlus
backlight in the PDK by using the BSPEnableLCD() function:
BOOL BSPEnableLCD(IPU_DRIVE_TYPE dispType)
{
....
switch (dispType)
{
case eIPU_SDC:
...
break;
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
37
Modifying the BSP
case eIPU_ADC:
.....
// Turn-on GPM722A0 backlight through ATLAS KEYPAD LED
PmicBacklightSetMode(BACKLIGHT_KEYPAD, BACKLIGHT_CURRENT_CTRL_MODE);
// set to the minimum period
PmicBacklightSetCycleTime(MC13783_LED_MIN_BACKLIGHT_PERIOD);
// set the current level for Display
PmicBacklightSetCurrentLevel(BACKLIGHT_KEYPAD,
MC13783_LED_MAX_BACKLIGHT_CURRENT_LEVEL);
// set the PWM dutycycle
PmicBacklightSetDutyCycle(BACKLIGHT_KEYPAD,MC13783_LED_MAX_BACKLIGHT_DUTY_CYCLE);
// turn on Master enable
PmicBacklightMasterEnable();
.....
break;
}
}
5.7
Configuring Wait for the VSYNC Signal
There are some panels, which send a VSYNC signal to synchronize the writing to the panel and avoid
tearing. Since this is not applicable for GPM722A0, the panel can be removed from the driver. If the panel
is not removed, then the driver waits for the VSYNC signal (that does not appear), after every write
operation. If the tearing prevention flag is not removed, the timeout for this signal appears and the refresh
rate is extremely slow and limited for the VSYNC timeout (less than one write per second).
The panel is disabled by setting the BSP_ADC_ENABLE_TEARING_PREVENTION option in the bsp_cfg.h header
file to FALSE.
#define BSP_ADC_ENABLE_TEARING_PREVENTION FALSE
5.8
Adding a Panel Type enum for the New LCD
A new IPU_PANEL_TYPE enumeration must be created for this new panel if another LCD panel support is to
be added. This enumeration can be found in the ipu.h header file. Here, all the asynchronous panel entries
must be placed after ADCPanelOffset, and the offset after this entry represents the position of the new
asynchronous PANEL_INFO structure in the g_ADCPanelArray[] array in the adc.c file.
ipu.h
typedef enum {
IPU_PANEL_SHARP_TFT,
IPU_PANEL_NEC_TFT,
IPU_TV_NTSC,
IPU_TV_PAL,
ADCPanelOffset,
IPU_PANEL_TOSHIBA,
IPU_PANEL_EPSON,
IPU_PANEL_GIANTPLUS,
// New panel goes here ,
// New panel goes here ,
numPanel,
} IPU_PANEL_TYPE;
//
//
//
//
Registry
Registry
Registry
Registry
value
value
value
value
is
is
is
is
0
1
2
3
//
//
//
//
//
Registry
Registry
Registry
Registry
Registry
value
value
value
value
value
is
is
is
is
is
5
6
7
8
9
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
38
Freescale Semiconductor
Modifying the BSP
5.9
Create the PANEL_INFO Entry for the New LCD
Based on the information described in Section 4.2.4.1, “PANEL_INFO,” fill the PANEL_INFO structure for
the new asynchronous panel and add it to the g_ADCPanelArray[] array in the adc.c file. The position of
the array for the new LCD panel is determined by the IPU_PANEL_TYPE enumeration.
The following code snippet describes the GiantPlus GPM722A0 smart panel:
PANEL_INFO g_ADCPanelArray[numPanel] =
{
// Toshiba Smart Panel Definitions
{
...
},
//Epson Smart Panel definitions
{
...
},
// GiantPlus GPM76722A0 QVGA Smart Panel Definitions
{
(PUCHAR) "GiantPlus QVGA Panel",// Name
IPU_PANEL_GIANTPLUS,
// type
IPU_PIX_FMT_RGB565,
// Pixel Format
DISPLAY_MODE_DEVICE,
// Mode ID
240,
// width
320,
// height
60,
// frequency (refresh rate)
0,
// Vertical Sync width
0,
// Vertical Start Width 34
0,
// Vertical End Width
0,
// Horizontal Sync Width
0,
// Horizontal Start Width 144
0,
// Horizontal End Width
600,
// Read Cycle Period (600)
150,
// Read Up Position (100)
150,
// Read Down Position (130)
300,
// Write Cycle Period (100)
10,
// Write Up Position (10)
80,
// Write Down Position (45)
8000000,
// Pixel Clock Cyle Frequency (8000000)
200,
// Pixel Data Offset Position (200)
{
// ADC Display Interface signal polarities
IPU_ADC_DISPLAY_0,
// Display Number
IPU_DI_DISP_IF_CONF_IF_MODE_SYSTEM80_TYPE2, // Interface mode
IPU_DI_DISP_IF_CONF_PAR_BURST_MODE_BURST_CS,//Parallel interface single
IPU_DI_DISP_SIG_POL_DATA_POL_STRAIGHT,
// Data Pol
IPU_DI_DISP_SIG_POL_CS_POL_ACTIVE_LOW,
// Clock Select Pol
IPU_DI_DISP_SIG_POL_PAR_RS_POL_STRAIGHT,
// Parallel RS Pol
IPU_DI_DISP_SIG_POL_WR_POL_ACTIVE_LOW,
// Write Pol
IPU_DI_DISP_SIG_POL_RD_POL_ACTIVE_LOW,
// Read Pol
IPU_DI_DISP_SIG_POL_VSYNC_POL_ACTIVE_LOW,
// VSync Pol
IPU_DI_DISP_SIG_POL_SD_D_POL_STRAIGHT,
// Serial Data Pol
IPU_DI_DISP_SIG_POL_SD_CLK_POL_STRAIGHT,
// Serial Interface Clk Pol
IPU_DI_DISP_SIG_POL_SER_RS_POL_STRAIGHT,
// Serial Infc Addr bit Pol
IPU_DI_DISP_SIG_POL_BCLK_POL_STRAIGHT,
// Burst clock Pol
},
{
// SDC Display Interface signal polarities
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
39
Modifying the BSP
0,
0,
0,
0,
0,
0,
0,
0,
}
},
}
5.10
Configuring the Data and Command System Interface
After reviewing the LCD datasheet, and based on the information in Section 3.5, “System Interface
Data/Command Format,” and Section 3.6, “LCD Panels Supported by the i.MX31,” configure the system
interface by modifying the DISP0 properties.
For data, the registers used to modify are:
• DI_DISP0_DB0_MAP
• DI_DISP0_DB1_MAP
• DI_DISP0_DB2_MAP
• DI_DISP_ACC_CC
Modify the following registers in the InitializeADC() function in the adc.c file:
•
•
•
•
DI_DISP0_CB0_MAP
DI_DISP0_CB1_MAP
DI_DISP0_CB2_MAP
DI_DISP_ACC_CC
UINT32 InitializeADC(PANEL_INFO *currentPanel, int bpp)
{
...
switch (m_SignalPol.DISP_NUM)
{
case IPU_ADC_DISPLAY_0:
// Data Mapping
//... DI_DISP0_B0_MAP
OUTREG32(&g_pIPU->DI_DISP0_DB0_MAP,
// data offset (BYTE0 - BLUE)
// MSB of blue component is located on bit D4
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_OFFS0, 4)|
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_OFFS1, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_OFFS2, 0)|
// data mapping (BYTE0 - BLUE)
// mask 3 bits, since blue component is 5 bits width
// M3-M7 are enabled on first clock cycle (0)
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_M0, 3)|
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_M1, 3)|
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_M2, 3)|
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_M3, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_M4, 0)|
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
40
Freescale Semiconductor
Modifying the BSP
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_M5, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_M6, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB0_MAP_MD00_M7, 0));
//... DI_DISP0_B1_MAP
OUTREG32(&g_pIPU->DI_DISP0_DB1_MAP,
// data offset (BYTE1 - GREEN)
// MSB of green component is located on bit D10
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_OFFS0, 10)|
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_OFFS1, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_OFFS2, 0)|
// data mapping (BYTE1 - GREEN)
// mask 2 bits, since green component is 6 bits width
// M2-M7 are enabled on first clock cycle (0)
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_M0, 3)|
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_M1, 3)|
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_M2, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_M3, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_M4, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_M5, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_M6, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB1_MAP_MD01_M7, 0));
//... DI_DISP0_B2_MA
OUTREG32(&g_pIPU->DI_DISP0_DB2_MAP,
// data offset (BYTE2 - RED)
// MSB of red component is located on bit D15
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_OFFS0, 15)|
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_OFFS1, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_OFFS2, 0)|
// data mapping (BYTE2 - RED)
// mask 3 bits, since red component is 5 bits width
// M3-M7 are enabled on first clock cycle (0)
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_M0, 3)|
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_M1, 3)|
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_M2, 3)|
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_M3, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_M4, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_M5, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_M6, 0)|
CSP_BITFVAL( IPU_DI_DISP0_DB2_MAP_MD02_M7, 0));
// Data System Interface is 1 transfer/pixel
INSREG32BF(&g_pIPU->DI_DISP_ACC_CC,
IPU_DI_DISP_ACC_CC_DISP0_IF_CLK_CNT_D,
IPU_DI_DISP_ACC_CC_CLOCK_1_CYCLE);
// Command Mapping
// Enable byte during first clock cycle
OUTREG32(&g_pIPU->DI_DISP0_CB0_MAP,
// command offset first byte DB7-DB0
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_OFFS0, 0x7)|
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_OFFS1, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_OFFS2, 0)|
// command mapping, enable complete Byte0 in first cycle
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_M0, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_M1, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_M2, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_M3, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_M4, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_M5, 0)|
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
41
Modifying the BSP
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_M6, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB0_MAP_MC00_M7, 0));
//... DI_DISP0_CB1_MAP
OUTREG32(&g_pIPU->DI_DISP0_CB1_MAP,
// command offset, Byte1 DB15-DB8
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_OFFS0, 0xF)|
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_OFFS1, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_OFFS2, 0)|
// command mapping
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_M0, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_M1, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_M2, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_M3, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_M4, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_M5, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_M6, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB1_MAP_MC01_M7, 0));
//... DI_DISP0_CB2_MAP
OUTREG32(&g_pIPU->DI_DISP0_CB2_MAP,
// command offset
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_OFFS0, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_OFFS1, 0)|
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_OFFS2, 0)|
// command mapping mask BYTE2, ignore third byte
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_M0, 3)|
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_M1, 3)|
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_M2, 3)|
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_M3, 3)|
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_M4, 3)|
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_M5, 3)|
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_M6, 3)|
CSP_BITFVAL( IPU_DI_DISP0_CB2_MAP_MC02_M7, 3));
// 1 clk cycle per command
INSREG32BF(&g_pIPU->DI_DISP_ACC_CC,
IPU_DI_DISP_ACC_CC_DISP0_IF_CLK_CNT_C,
IPU_DI_DISP_ACC_CC_CLOCK_1_CYCLE);
break;
case IPU_ADC_DISPLAY_1:
break;
case IPU_ADC_DISPLAY_2:
break;
}
...
}
5.11
Write Initialization Command Routine
After configuring the command interface, the initialization routine must be included in the BSPEnableLCD()
function. Since all the write registers have the same endianness, send the 16-bit address first and then the
16-bit data value. A new low-level routine can be created to avoid the usage of the cmd_data[] array. The
BSPEnableLCD() function must be declared in the adc.h header file and also in the adc.c header file.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
42
Freescale Semiconductor
Modifying the BSP
adc.h
void ADCWriteCommandRegister(UINT32 dispNum, BOOL b_cmd_data, UINT32 regNum, UINT32 regData);
adc.c
void ADCWriteCommandRegister(UINT32 dispNum, BOOL b_cmd_data, UINT32 regNum, UINT32 regData)
{
// Write low-level access configuration register
OUTREG32(&g_pIPU->DI_DISP_LLA_CONF,
CSP_BITFVAL(IPU_DI_DISP_LLA_CONF_DRCT_BE_MODE, 0) |
CSP_BITFVAL(IPU_DI_DISP_LLA_CONF_DRCT_MAP_DC, 1) |
CSP_BITFVAL(IPU_DI_DISP_LLA_CONF_DRCT_LOCK, 0) |
CSP_BITFVAL(IPU_DI_DISP_LLA_CONF_DRCT_DISP_NUM, dispNum) |
CSP_BITFVAL(IPU_DI_DISP_LLA_CONF_DRCT_RS, b_cmd_data ? 0 : 1));
// Write low-level access data (send address first)
OUTREG32(&g_pIPU->DI_DISP_LLA_DATA, regNum);
// Write low-level access configuration register
OUTREG32(&g_pIPU->DI_DISP_LLA_CONF,
CSP_BITFVAL(IPU_DI_DISP_LLA_CONF_DRCT_BE_MODE, 0) |
CSP_BITFVAL(IPU_DI_DISP_LLA_CONF_DRCT_MAP_DC, 1) |
CSP_BITFVAL(IPU_DI_DISP_LLA_CONF_DRCT_LOCK, 0) |
CSP_BITFVAL(IPU_DI_DISP_LLA_CONF_DRCT_DISP_NUM, dispNum) |
CSP_BITFVAL(IPU_DI_DISP_LLA_CONF_DRCT_RS, 1));
// Write low-level access data (send register address first)
OUTREG32(&g_pIPU->DI_DISP_LLA_DATA, regData);
}
In the following example, the initialization routine is provided by the LCD vendor.
bspdisplay.cpp
BOOL BSPEnableLCD(IPU_DRIVE_TYPE dispType)
{
....
switch (dispType)
{
case eIPU_SDC:
...
break;
case eIPU_ADC:
.....
UINT32 dispNum = 0; // We are
ADCWriteCommandRegister(dispNum, TRUE,
ADCWriteCommandRegister(dispNum, TRUE,
Sleep(10);
ADCWriteCommandRegister(dispNum, TRUE,
ADCWriteCommandRegister(dispNum, TRUE,
ADCWriteCommandRegister(dispNum, TRUE,
ADCWriteCommandRegister(dispNum, TRUE,
ADCWriteCommandRegister(dispNum, TRUE,
ADCWriteCommandRegister(dispNum, TRUE,
ADCWriteCommandRegister(dispNum, TRUE,
ADCWriteCommandRegister(dispNum, TRUE,
ADCWriteCommandRegister(dispNum, TRUE,
ADCWriteCommandRegister(dispNum, TRUE,
using Display 0
0x00E5, 0x8000);//????
0x0000, 0x0001);// start oscilation
0x0001,
0x0002,
0x0003,
0x0004,
0x0008,
0x0009,
0x000A,
0x000C,
0x000D,
0x000F,
0x0100);//driver S1->S720
0x0700); //linear control
0x1030);
0x0000);//no resizing
0x0303); //display control2
0x0000); //display control3
0x0000); //display control4
0x0000);//RGB ifc-18bit
0x0000);//frame mark line0
0x0000);
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
43
Modifying the BSP
//power on sequence
ADCWriteCommandRegister(dispNum, TRUE, 0x0010,
ADCWriteCommandRegister(dispNum, TRUE, 0x0011,
ADCWriteCommandRegister(dispNum, TRUE, 0x0012,
ADCWriteCommandRegister(dispNum, TRUE, 0x0013,
Sleep(50);
ADCWriteCommandRegister(dispNum, TRUE, 0x0010,
ADCWriteCommandRegister(dispNum, TRUE, 0x0011,
Sleep(50);
// If we are using the suggested 2.8V supply,
// we can use the Giantplus-suggested voltage
// amplification settings.
ADCWriteCommandRegister(dispNum, TRUE, 0x0012,
Sleep(50);
ADCWriteCommandRegister(dispNum, TRUE, 0x0013,
Sleep(50);
ADCWriteCommandRegister(dispNum, TRUE, 0x0029,
ADCWriteCommandRegister(dispNum, TRUE, 0x0020,
ADCWriteCommandRegister(dispNum, TRUE, 0x0021,
ADCWriteCommandRegister(dispNum, TRUE, 0x0030,
ADCWriteCommandRegister(dispNum, TRUE, 0x0031,
ADCWriteCommandRegister(dispNum, TRUE, 0x0032,
ADCWriteCommandRegister(dispNum, TRUE, 0x0035,
ADCWriteCommandRegister(dispNum, TRUE, 0x0036,
ADCWriteCommandRegister(dispNum, TRUE, 0x0037,
ADCWriteCommandRegister(dispNum, TRUE, 0x0038,
ADCWriteCommandRegister(dispNum, TRUE, 0x0039,
ADCWriteCommandRegister(dispNum, TRUE, 0x003C,
ADCWriteCommandRegister(dispNum, TRUE, 0x003D,
ADCWriteCommandRegister(dispNum, TRUE, 0x0050,
ADCWriteCommandRegister(dispNum, TRUE, 0x0051,
ADCWriteCommandRegister(dispNum, TRUE, 0x0052,
ADCWriteCommandRegister(dispNum, TRUE, 0x0053,
ADCWriteCommandRegister(dispNum, TRUE, 0x0060,
ADCWriteCommandRegister(dispNum, TRUE, 0x0061,
ADCWriteCommandRegister(dispNum, TRUE, 0x006A,
ADCWriteCommandRegister(dispNum, TRUE, 0x0080,
ADCWriteCommandRegister(dispNum, TRUE, 0x0081,
ADCWriteCommandRegister(dispNum, TRUE, 0x0082,
ADCWriteCommandRegister(dispNum, TRUE, 0x0083,
ADCWriteCommandRegister(dispNum, TRUE, 0x0084,
ADCWriteCommandRegister(dispNum, TRUE, 0x0085,
ADCWriteCommandRegister(dispNum, TRUE, 0x0090,
ADCWriteCommandRegister(dispNum, TRUE, 0x0092,
ADCWriteCommandRegister(dispNum, TRUE, 0x0093,
ADCWriteCommandRegister(dispNum, TRUE, 0x0095,
ADCWriteCommandRegister(dispNum, TRUE, 0x0097,
ADCWriteCommandRegister(dispNum, TRUE, 0x0098,
ADCWriteCommandRegister(dispNum, TRUE, 0x0007,
// Write test pattern to display
ADCWriteCommandRegister(dispNum, TRUE, 0x0020,
ADCWriteCommandRegister(dispNum, TRUE, 0x0021,
Sleep(1);
int i;
//blue and green strips
for(i=0; i<(240*320/8-1); i++)
{
0x0000);
0x0007);
0x0000);
0x0000);
//power1
//power2
//power3
//power4
0x1590); //power1
0x0007); //power2
0x0118); //power3
0x1700); //power4
0x000E); //power control
0x0000); //GRAM address set
0x0000); //GRAM address set
0x0000); //Gamma control
0x0404); //Gamma control
0x0305); //Gamma control
0x0000); //Gamma control
0x1F00); //Gamma control
0x0505); //Gamma control
0x0203); //Gamma control
0x0707); //Gamma control
0x0400); //Gamma control
0x0012); //Gamma control
0x0000);//hor/ver addr pos
0x00EF);//hor/ver addr pos
0x0000); //hor/ver addr pos
0x013F); //hor/ver addr pos
0x2700);//gate scan control
0x0001);//gate scan control
0x0000);//gate scan control
0x0000); //Partial image
0x0000); //Partial image
0x0000); //Partial image
0x0000); //Partial image
0x0000); //Partial image
0x0000); //Partial image
0x0014); //panel ifc 20 clk
0x0000);
0x0000);
0x0110);
0x0000);
0x0000);
0x0133); //display control1
0x0000); //GRAM address set
0x0000); //GRAM address set
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
44
Freescale Semiconductor
Modifying the BSP
ADCWriteCommandRegister(dispNum,
ADCWriteCommandRegister(dispNum,
ADCWriteCommandRegister(dispNum,
ADCWriteCommandRegister(dispNum,
ADCWriteCommandRegister(dispNum,
ADCWriteCommandRegister(dispNum,
ADCWriteCommandRegister(dispNum,
ADCWriteCommandRegister(dispNum,
TRUE,
TRUE,
TRUE,
TRUE,
TRUE,
TRUE,
TRUE,
TRUE,
0x0022,
0x0022,
0x0022,
0x0022,
0x0022,
0x0022,
0x0022,
0x0022,
0x001F);
0x001F);
0x001F);
0x001F);
0x07E0);
0x07E0);
0x07E0);
0x07E0);
//Write
//Write
//Write
//Write
//Write
//Write
//Write
//Write
pixel
pixel
pixel
pixel
pixel
pixel
pixel
pixel
}
Sleep(2000);
.....
break;
}
}
5.12
Creating the Frame Buffer Template for Write Access
Green and blue strips can be found on the screen, if all the steps are executed. With the help of this image,
ensure that the panel is initialized correctly and also the backlight is enabled. As mentioned in
Section 3.7.2, “Template Mode,” create a template to enable the display driver in order to write on the
frame buffer. This template is defined in the CreateTemplate() function of the adc.c file.
//
Register name
Reg No.
R/W RS Description
//----- --------------------- --------- --- -------------------#define HOR_GRAM_ADDR_SET
0x20
// W
1 Horizontal GRAM Address Set
#define VER_GRAM_ADDR_SET
0x21
// W
1 Vertical GRAM Address Set
#define WR_DATA_TO_GRAM
0x22
// W
1 Write Data to GRAM
void CreateTemplate(TEMPLATE_CMD_REG *pCmd, unsigned int width, unsigned int height)
{
unsigned int i = 0;
UNREFERENCED_PARAMETER(width);
UNREFERENCED_PARAMETER(height);
// Create the template for GiantPlus LCD GPM722A0
pCmd[i].reg.Data = HOR_GRAM_ADDR_SET; // X coordinate command
pCmd[i].reg.Opcode = WR_CMND;
pCmd[i].reg.RS = 0;
pCmd[i++].reg.FlowControl = SINGLE_STEP;
pCmd[i].reg.Data = 0x01;
// send address bits [7:0]
pCmd[i].reg.Opcode = WR_XADDR;
pCmd[i].reg.RS = 1;
pCmd[i++].reg.FlowControl = SINGLE_STEP;
pCmd[i].reg.Data = VER_GRAM_ADDR_SET; // Y coordinate command
pCmd[i].reg.Opcode = WR_CMND;
pCmd[i].reg.RS = 0;
pCmd[i++].reg.FlowControl = SINGLE_STEP;
pCmd[i].reg.Data = 0x01;
// send address bits [22:8]
pCmd[i].reg.Opcode = WR_YADDR;
pCmd[i].reg.RS = 1;
pCmd[i++].reg.FlowControl = SINGLE_STEP;
pCmd[i].reg.Data = WR_DATA_TO_GRAM;
// Write Data to GRAM
pCmd[i].reg.Opcode = WR_CMND;
pCmd[i].reg.RS = 0;
pCmd[i++].reg.FlowControl = SINGLE_STEP;
pCmd[i].reg.Data = 0;
pCmd[i].reg.Opcode = WR_DATA;
pCmd[i].reg.RS = 1;
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
45
Modifying the BSP
pCmd[i++].reg.FlowControl = STOP;
}
UNREFERENCED_PARAMETER
tag is used to describe the following error:
error C2220: warning treated as error - no 'object' file generated
warning C4100: 'height' : unreferenced formal parameter
warning C4100: 'width' : unreferenced formal parameter
5.13
Adding the Mouse Support for the Asynchronous Displays
In some cases where the mouse is moving, it is necessary to inform the asynchronous thread to update the
region where the cursor is changing. For this reason, it is necessary to add the mouse support feature to the
ddipu_cursor.cpp file.
ddipu_cursor.cpp
SCODE DDIPU::MovePointer(int x, int y)
{
...
CursorOff();
if (x != -1 || y != -1)
{
...
// handle the TV mode case for updates
if(m_bTVModeActive)
{
...
}
// handle ADC (Smart Panels) updates
if(m_bADCActive)
{
// Now, calculate the dirty-rect to refresh to the actual hardware
bounds.left
= m_CursorRect.left;
bounds.top
= m_CursorRect.top;
bounds.right
= m_CursorRect.right;
bounds.bottom
= m_CursorRect.bottom;
EnterCriticalSection(&m_csDirtyRect);
DEBUGCHK(m_pTVDirtyRect != NULL);
if(m_pADCDirtyRect)
{
m_pADCDirtyRect->SetDirtyRegion((LPRECT)&oldBounds);
m_pADCDirtyRect->SetDirtyRegion((LPRECT)&bounds);
}
// Signal to ADC thread to udpate the screen.
SetEvent(m_hADCUpdateRequest);
LeaveCriticalSection(&m_csDirtyRect);
}
}
return
S_OK;
}
5.14
Rebuilding the Project
In the end, rebuild the project by using the Build current BSP and subprojects.
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
46
Freescale Semiconductor
Revision History
Go to Menu Build > Advanced Build Commands > Build Current BSP and Subprojects to rebuild the
project.
6
Revision History
Table 19 provides the revision history for this application note.
Table 19. Document Revision History
Rev. Number
Date
0
08/2010
Substantive Change(s)
Initial release
System-80 Asynchronous Display on the i.MX31 WINCE 6.0 PDK, Rev. 0
Freescale Semiconductor
47
How to Reach Us:
Home Page:
www.freescale.com
Web Support:
http://www.freescale.com/support
USA/Europe or Locations Not Listed:
Freescale Semiconductor, Inc.
Technical Information Center, EL516
2100 East Elliot Road
Tempe, Arizona 85284
1-800-521-6274 or
+1-480-768-2130
www.freescale.com/support
Europe, Middle East, and Africa:
Freescale Halbleiter Deutschland GmbH
Technical Information Center
Schatzbogen 7
81829 Muenchen, Germany
+44 1296 380 456 (English)
+46 8 52200080 (English)
+49 89 92103 559 (German)
+33 1 69 35 48 48 (French)
www.freescale.com/support
Information in this document is provided solely to enable system and software
implementers to use Freescale Semiconductor products. There are no express or
implied copyright licenses granted hereunder to design or fabricate any integrated
circuits or integrated circuits based on the information in this document.
Freescale Semiconductor reserves the right to make changes without further notice to
any products herein. Freescale Semiconductor makes no warranty, representation or
guarantee regarding the suitability of its products for any particular purpose, nor does
Freescale Semiconductor assume any liability arising out of the application or use of
any product or circuit, and specifically disclaims any and all liability, including without
limitation consequential or incidental damages. “Typical” parameters which may be
provided in Freescale Semiconductor data sheets and/or specifications can and do
vary in different applications and actual performance may vary over time. All operating
parameters, including “Typicals” must be validated for each customer application by
customer’s technical experts. Freescale Semiconductor does not convey any license
Japan:
Freescale Semiconductor Japan Ltd.
Headquarters
ARCO Tower 15F
1-8-1, Shimo-Meguro, Meguro-ku
Tokyo 153-0064
Japan
0120 191014 or
+81 3 5437 9125
[email protected]
under its patent rights nor the rights of others. Freescale Semiconductor products are
Asia/Pacific:
Freescale Semiconductor China Ltd.
Exchange Building 23F
No. 118 Jianguo Road
Chaoyang District
Beijing 100022
China
+86 10 5879 8000
[email protected]
claims, costs, damages, and expenses, and reasonable attorney fees arising out of,
For Literature Requests Only:
Freescale Semiconductor
Literature Distribution Center
1-800 441-2447 or
+1-303-675-2140
Fax: +1-303-675-2150
LDCForFreescaleSemiconductor
@hibbertgroup.com
Document Number: AN4180
Rev. 0
08/2010
not designed, intended, or authorized for use as components in systems intended for
surgical implant into the body, or other applications intended to support or sustain life,
or for any other application in which the failure of the Freescale Semiconductor product
could create a situation where personal injury or death may occur. Should Buyer
purchase or use Freescale Semiconductor products for any such unintended or
unauthorized application, Buyer shall indemnify and hold Freescale Semiconductor
and its officers, employees, subsidiaries, affiliates, and distributors harmless against all
directly or indirectly, any claim of personal injury or death associated with such
unintended or unauthorized use, even if such claim alleges that Freescale
Semiconductor was negligent regarding the design or manufacture of the part.
Freescale, the Freescale logo, CodeWarrior, ColdFire, PowerQUICC,
StarCore, and Symphony are trademarks of Freescale Semiconductor, Inc.
Reg. U.S. Pat. & Tm. Off. CoreNet, QorIQ, QUICC Engine, and VortiQa are
trademarks of Freescale Semiconductor, Inc. All other product or service
names are the property of their respective owners. ARM is the registered
trademark of ARM Limited.
© 2010 Freescale Semiconductor, Inc.