06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 1/13

Blog Bulletin Discussions Resources Contact Support

website content

You are here: Home Projects Series 1 - Display Driver Boards Series 1: Part 8 - Writing A Skeleton TFT-LCD Display

Device Driver

Tweet 2 0 Share

Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

Created on Saturday, 28 April 2012 12:19 Last Updated on Saturday, 28 April 2012 20:04

Abstract

In this part of the series a method of using symbolic logic to represent HDL,

when designing the architecture of a hardware algorithm, is introduced. The

method is used to develop a modular, skeleton, device driver for TFT-LCD

displays in general and the LQ043T3DX02 display (used in the Sony PSP) in

particular. The design method introduced is used to generate a display’s

horizontal and vertical synchronisation timing signals, by using its (the

display's) timing characteristic parameters provided in its datasheet. Finally, by

using a color look-up table a method of displaying images on the display is demonstrated.

1.8.1 Introduction

In the last part of the series the prototype display and driver board has been discussed. However, since then a

lot has been going on in the background here and a need has arisen to pursue a slightly different approach.

Hence, the series will continue with the development of display specific driver boards and display independent

graphic processor boards.

The newly derived system design, which should allow us to support more display types, should work like this.

Typically, each display type requires specific driver board functionality, but similar display graphics. Hence, the

FPGA used to provide the display's graphics, including drawing routines, could be developed independently.

Therefore, the new design philosophy is to develop display driver boards and a separate FPGA graphics

processor board. Also, the newly developed system will allow the user to configure the FPGA using their own

microcontroller. The conceptual diagram can be seen, in Figure 1:8-1, below.

Like 0 Send Share

Series 1 - Display DriverBoards

Series 1: Part 8 - Writing ASkeleton TFT-LCD DisplayDevice Driver

Series 1: Part 7 - The UbiquitousPrototype (LQ043T3DX02)

Series 1: Part 6 - TowardsCreating a Universal DisplayDriver Board (LQ043T3DX02)

Series 1: Update - Assembly andTesting (LQ043T3DX02)

Series 1: Part 5 - PCB DesignSchematics and Artwork(LQ043T3DX02)

Series 1: Part 4 - An ImprovedBacklight Circuit (LQ043T3DX02)

Series 1: Part 3 - ComponentSelection and Analysis(LQ043T3DX02)

Series 1: Part 2 - The DataInterface (LQ043T3DX02)

Series 1: Part 1 - The Mechanicaland Electrical Interfaces(LQ043T3DX02)

HOME A2DGL PROJECTS TUTORIALS THE SCIENG NOTES REVIEWS DOWNLOADS

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 2/13

Figure 1:8-1: The newly designed system will consist of display specific driver boards (1) and a display

independent graphics processor board (2). Also, configuration of the FPGA will be be provided by a user

provided micro-controller (3).

More information, on this revised concept, will be provided from the next part of the series onwards with the

introduction of a new display! For now the aim of this part of the series is to tackle one of the most fundamental

parts of any display system, developing the display's device drivers, used to display images on the display.

This article has been republished from Ben's former blog and appropriately slotted in here, as part 8 of series

1.

The aim of developing a skeleton device driver so early on in the series, before finalising the hardware design

concept, has some of the many disadvantages stressed repeatedly in system design text. However, in this

particular case there could be some advantages too:

1. Having a skeleton display system could allow us to experiment with computer graphics algorithms in real-

time as the series develops.

2. It should provide some much needed experience for readers that are either rusty with their digital design

(and need a practical project to encourage them to dust off that old FPGA development kit bought out of

enthusiasm but rarely used) or for those that are just starting out and want to see how it is done.

3. It also provides an opportunity for the more advanced user to smile knowingly when a recognisable design

feature unravels during the design process.

If you fall into the second category then enjoy the trip! The system requirements of the project will be "matured''

anyway as other parts in the series are developed.

Figure 1:8-2: To illustrate the pronciples of hardware design a skelton device driver is developed.

Whilst it is probably more efficient to implement digital logic by writing code in a text editor using a Hardware

Description Language (HDL) like VHDL or Verilog, it is sometimes much easier to explain a concept or idea by

using diagrams, after all a picture is regarded as being worth a thousand words (although maybe not a

thousand lines of well thought out and well written code!).

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 3/13

Hence, in this series, or this part at least, an attempt should be made to show and explain the architecture of an

algorithm or concept rather than simply "hand'' readers the code. Taking this approach is probably the one that

would be favoured by most readers anyway, as they are likely to be abhorred by the thought of not being

allowed to think and work things out for themselves.

An added benefit of doing things this way is that the series should remain hardware language independent,

which allows users of "higher-level of abstraction" type hardware description languages, like System-C, to follow

along and contribute too, if they so wish. It also presents the opportunity, in the future, to consider OpenCL for

FPGAs [1] too.

1.8.2 Notation

Standard schematic notation, if there is such a thing, is not used in this document. However, if a reader sees

the symbol in Figure 2 below it would not be unreasonable to expect the reader to interpret it in the following

way.

The symbol in Figure 1.8-3 could be that of an entity (VHDL) or module (Verilog) known as Register32 (1). It

has a 32-bit input signal known as DIN (2) and a 1-bit input signal known as Enable (3), which is asserted when

set to a logic level of '1'. The value on the input, DIN, is transferred to the 32-bit output signal DOUT (5), on the

rising edge of the Clock (4) signal.

Figure 1.8:3 : A demonstration of a schematic symbol that has two 32-bit ports (2), (5). The name of the symbol

is Register32 (1) and it has an Enable (3) signal. Register32 transfers its input data DIN(2) to its output DOUT

(5) on the rising edge of the Clock (4) signal.

If instead of transferring data on the rising edge of the clock it is transferred on the clock's falling edge, then

the clock symbol would be changed from that labelled (4) to the one labelled (6). Likewise, if the Register32

transfers data from its input to its output when the Enabled signal is asserted low then symbol (7) would replace

symbol (3).

Right, with all that housekeeping taken care of, lets not hold back and jump in at the deep end, as usual!

1.8.3 Horizontal Synchronisation Signal, Hsync.

To begin with lets assume that we have a counter that is driven by a clock, say with the same timing

characteristics as a clock used to drive a TFT-LCD display, like the one shown in Figure 1.8-4.

Figure 1.8-4 : Display timing characteristics of the clock parameter for the LQ043T3DX02 display, used in the

Sony PSP displays.

When this counter is enabled, it increments its value every 1/(9 MHz) or 111.11 ns.

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 4/13

Figure 1:8-5 : Schematic symbol of a 10-bit counter with an asynchronous reset signal. When the Enable

signal is asserted (logic level = '1') the counter outputs a sequence of numbers that increment by 1 on the

rising edge of the Clock signal.

Now, a counter that can increment its value up to at least 524 must have a data width of at least 10-bits since

524 = 1000001100 . The symbolic representation of such a counter could be similar to the one shown in

Figure 1:8-5.

If this counter is enabled permanently it would output a sequence of numbers repeatedly from 0 to 1023, in

increments of 1, on the rising edge of the clock. If the signal, nAclr, is asserted (low) the counter could be set to

its reset value asynchronously. If nAclr is never asserted the counter would return to 0 on the next clock cycle

after 1023 and repeat the same sequence of numbers unfailingly. The counter can, of course, only increment

its value when it is enabled.

Now, supposing that we require a counter that repeats itself after every 525 clock cycles. If the duration or time

period of a clock cycle is 111.11 ns, then the period T of the repeated sequence is 111.11 ns x 525 or

58.363 us and the frequency fh of this time period can then be determined to be

1/(58.363 x 10-9) = 17.13 KHz

Figure 1:8-6 : The horizontal period of the LQ043T3DX02 display is 525 clock cycles in duration and has a

typical horizontal scanning frequency of 17.13 KHz.

Given our counter, defined in the schematic symbol in Figure 1:8-5, how can we use it to repeatedly count from

0 to 524 as shown in Figure 1:8-6? Well, one way could be to use an equality comparator to assert the

counter's reset signal, asynchronously, each time its comparative value is true. [We could also create a coutner

that we could clear synchronously, if we wanted to. - B.P]

10 2

h

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 5/13

Figure 1:8-7 : Horizontal Synchronisation Timing Generator: When the counter's output is equal to 525, then it

is comparatively equal to the constant, 525 and the inverted output of the comparator is asserted low.

So what have we just done? Well, If you refer to the timing characteristics diagram, in section 7-1 of the

LQ043T3DX02 data manual and repeated in Figure 1:8-8, then you would have noticed that the number 525

corresponds to the length of the horizontal synchronisation period, in clock cycles.

Figure 1:8-8 : The horizontal synchronisation parameter's timing characteristics.

Thus, we have created the first meaningful component of our skeleton device driver, a horizontal

synchronisation timing generator, or counter, that could be used to generate all of our horizontal

synchronisation and timing data, shown in Figure 1:8-8.

Now supposing that we have constructed this horizontal synchronisation module using our favourite HDL or

schematic entry package, how do we know if it will always work as expected? Well, one way of ensuring that it

should always work as expected is to test it by writing a test infrastructure or testbench. It is generally

considered to be good practise to write a testbench and simulate every module after its completion and before

moving on to designing the next module in the design.

If our testbench is rigorous and our horizontal synchronisation timing generator passes all of its tests, then it

should mean, in principal at least, that we would never have to write this module again and we could file it safely

away!

In practise however there could be a bug in our code, which would require us to modify it and hence make what

is generally regarded as a revision or version change. To facilitate tracking all of our version changes we could

make use of the numerous revision and version control tools that are available non-commercially, as well as

commercially, on the various computing platforms.

We could also decide that we wish to keep a log of all of the bugs that we have come across in our design, by

using some form of bug tracking software. No doubt such software packages exist too and using one could

enhance your chances of success considerably, on major as well as small projects.

Before we deposit this part of our code's design into our archive, for use later on in this and other projects, we

might also like to provide a header at the top of the code to describe what this chunk of code does, when it

was written and by whom. Recording the version number and any known issues could help too. A summary of

some housekeeping tasks that could be done after each module is written is shown in Figure 1:8-9.

After all that has been done we can bank this module and move on to the next part of the design exercise.

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 6/13

Figure 1:8-9 : Writing a testbench, recording version changes and keeping documentation for all of the

modules in a design should be habitual rather than occasional. Keeping track of bugs in the whole of the

design should help too!

Now according to Figure 1:8-8, which is a snap shot of the horizontal synchronisation timing characteristics

(taken from section 7-1 of the LQ043T3DX02 data manual), the horizontal synchronisation period is typically

525 clock cycles in duration. This horizontal synchronisation region consists of four horizontal sub-regions of

varying durations. They are the (1) horizontal pulse width, (2) horizontal back porch, (3) horizontal period and

(4) the horizontal front porch as can be seen in Figure 1:8-10. Each region has a column in the table that

defines the typical duration of the region in clock cycles.

Figure 1:8-10 : The horizontal synchronisation timing parameters are the pulse width, back porch, horizontal

period and the front porch. The ordering of these parameters is typical of most displays and maintains

backward compatibility with analog displays.

Consider the sub-regions of the horizontal synchronisation period described above. Then, each sub-region

could be considered to have a start value that coincides with a horizontal timing counter value a and ends at a

horizontal timing counter value of b In other words the width, x, of each horizontal synchronisation parameter

or sub-region, in clock cycles, is bounded by the region given by:

a <= x >= b

where x, as noted previously, is the translated duration of the region in clock cycles. Thus, if we wish to

determine which region the horizontal synchronisation timing counter is in at any particular time, we could

design an algorithm that allows us to detect when the value of the counter's output, Q[9:0], is within the region

between the boundary points a and b at any instance as can be seen in Figure 1:8-11.

Figure 1:8-11: The instantaneous value of the horizontal synchronisation timing counter determines the

current region that the count value coincides with.

If we decide to use logic to implement a region detect algorithm, then one method that could be used would

i

i.

i i

i i

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 7/13

require two magnitude comparators and an AND gate as can be seen in Figure 1:8-12.

Figure 1:8-12 : Region Detect: A region detect algorithm could be used to determine the horizontal sub-region,

that coincides with the output value of the horizontal synchronisation timing counter. The bounds of the region

are defined by the inputs a and b. The input, c, is the output of the horizontal synchronisation timing counter

and is compared to a,b to determine if c is within the bounds of a,b.

Lets demonstrate how this works with an example. The horizontal pulse width period is bounded by the

horizontal synchronisation timing counter values of a = 0 and b = 40 as can be seen in Figure 1:8-13.

Thus, if logic for the region detect algorithm shown in Figure 1:8-12 has been written, tested and documented

then, we could set the a input to 0 and the b input to 40. Then, if we connect the c input of the algorithm to the

output of the horizontal synchronisation timing generator, seen inn Figure 1:8-7 above, you should see the

detection of what is referred to as the horizontal synchronisation signal or Hsync as can be seen in Figure 1:8-

13.

Figure 1:8-13 : The Horizontal Synchronisation Signal or Hsync can be detected between counter values 0 and

40. A display can require a Hsync signal with negative or positive polarity.

Likewise, you could detect the horizontal period or horizontal active video width by setting the a input to 43 and

the b input to 522. What you have done, now, is detect the active display area of a line or in other words you

have detected a horizontal region on the TFT-LCD screen where pixels are visible. In fact each counter value

in this region corresponds to a pixel value.

What about the front and back porch detection areas then? Well, as it turns out they have no real "immediate''

value in driving the LQ043T3DX02 display or digital displays in general for that matter. However, they are

usually provided in data manuals to maintain backward compatibility with device drivers written for the previous

generation of analog displays. We can safely ignore the porch regions in our skeleton driver.

To conclude this section we should put all the symbolic building blocks together and end up with an entity or

module symbol similar to the one shown in Figure 1:8-14. We could name this module our Horizontal

Synchronisation Timing Module .

i i

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 8/13

Figure 1:8-14 : A Horizontal Synchronisation Timing Module allows us to determine all of the sub-regions with

the horizontal period. In the figure shown the horizontal period and Hsync can be detected.

If you have got this far and have understood every printed word, then you are a third of the way into writing a

skeleton display device driver for the LQ043T3DX02 display. On the other hand if you have really struggled up

to this point then the good news is that when you do get it and you have developed your first working model,

the more you will appreciate the product of your hard work.

The bad news is that we are still travelling uphill, thus it might be a while before there is some respite. However,

like most things the more effort you put in the easier it should become, so stick with it. In the next section we

shall look at another third of the design, the vertical synchronistion signals.

1.8.4 Vertical Synchronisation Signal, Vsync.

For those of you that are clever, lazy or both even, you might be wondering if there could be some commonality

of code between the horizontal and vertical synchronisation timing modules. You could be wondering whether

you could save some time, energy or both, by reusing the same code. Especially since the horizontal

synchronisation timing module already developed should have been verified by simulation, documented and

impressively archived with a testbench by now!

Figure 1:8-15 :The vertical synchronisation parameter's timing characteristics.

Indeed, if you compare both of the horizontal and vertical synchronisation timing parameters, in Figures 1:8-8

and 1:8-15, you should recognise that the names are identical except where in some cases the word

horizontal has been replaced with vertical.

However, there is a distinctive and important difference between the two sets of parameters. Whilst the

horizontal synchronisation parameters are typical values defined in units of pixel clock cycles, the vertical

synchronisation parameters are a typical value in units of the number of display lines.

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 9/13

Figure 1:8-16: The vertical synchronisation timing parameters are the pulse width, back porch, horizontal

period and the front porch. The ordering of these parameters is typical of most displays and maintains

backward compatibility with analog displays.

For those of you that have recognised the similarity and a "bell has tinkled'' then you have stumbled upon a

very important concept in the digital design process, the concept of modularity and component reuse. Why

write a separate module to generate the vertical "synchronisation'' timing data, when we have already written

one to generate the horizontal "synchronisation'' timing data. The two should be almost identical, except for

their incremental units.

If the synchronisation timing module used to derive the Hsync and horizontal active region, described in the

Horizontal Synchronisation Signal section above, has been carefully coded, then all that we should need to do

is to create a generic module that could be adapted to generate both of our vertical and horizontal

synchronisation timing data.

Creating a generic synchronisation core could mean that you would only need to code a singular

synchronisation module once, test and document it, but use it for both of the horizontal and vertical

synchronisation instances. To do so however could require you to make some changes to the horizontal

synchronisation timing module that you have already developed.

If you have hard-coded parameter values, to detect regions for example (in the horizontal synchronisation

timing module), then you could use generic constants in a paramerterised module. This should provide a path

towards developing a single module with parameterised inputs. In this case the parameterised inputs could be

used to detect the periods of interest.

However, there is one caveat as mentioned before. While the horizontal synchronisation counter increments in

units of clock cycles the vertical equivalent counter should increment once for every new horizontal line [Hint:

That is the vertical synchronisation counter increments by 1, every 525 clock cycles.] So what is missing?

Figure 1:8-17 : The vertical period of the LQ043T3DX02 display is 285 lines in duration and has a typical

vertical refresh frequency of 60 Hz.

Well, we need a way of detecting the end of a horizontal period, such that it can be used to update or

increment the vertical period. Thus, if we can detect the end of this period, by creating a horizontal period end

detect module, we could use it to assert the enable signal of our vertical synchronisation counter in a vertical

synchronisation timing module.

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 10/13

A symbolic modification to the horizontal synchronisation function, developed previously, with an integrated

horizontal period end detect algorithm could look like the one in Figure 1:8-17. Doing things this way

incorporates our modular HDL approach.

Figure 1:8-18: A horizontal period end detect module is used to assert the enable flag of a synchronisation

timing module. The synchronisation timing module can now be used to provide the timing of the vertical period

parameters in line durations.

Thus, with modularity and code reuse, which the clever readers amongst you may have already spotted, we

could save a considerable amount of time on coding, testbench writing, simulation, verification documentation

and version control management as well as bug tracking to say the least! The lazy ones should be delighted

too, as it means that only the minimum amount of extra work is required to generate our vertical

synchronisation data to drive the display. To make the point again, this has been achieved all because of

modularisation and code reuse.

If you have successfully navigated your way up to this point then you should end up with a modified

synchronisation function like the one shown in Figure 1:8-18. We should now be able to generate the

horizontal synchronisation signal, hsync and the vertical synchronisation signals, vsync. We should also be

able to detect the horizontal and vertical active display periods or regions in display coordinates.

In fact if we make a plot of our horizontal vs vertical synchronisation parameters on a piece of paper we should

end-up with a diagram similar to the one shown in Figure 1:8-19 below.

Figure 1:8-19 : A plot of the horizontal timing counter as columns against the vertical timing counter as rows

produces the familiar x,y matrix or grid of displays, in display coordinates.

Yes, although we are able to display "nothing" on the display's screen, we should be able to drive the display

with our Hsync and Vsync signals! What is missing however is some colour, that is, a way to synchronise our

horizontal and vertical period parameters with R,G and B display values. This is exactly what we are going to do

in the next section, find a way of relating the horizontal and vertical display parameters and the horizontal and

vertical active regions to RGB data.

If you have made it up to here then you are practically swimming!

1.8.5 Displaying Images

Well, by the end of this section we should be able to display images on TFT-LCD displays once we have

bridged the gap between generating the display's control signals and synchronising them with R,G and B

display data.

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 11/13

If we refer back to Figure 1:8-19, then it should be noticed that the active video display area appears between

horizontal and vertical timing counter values of (12,43) at the top left-hand corner and (283,522) at the bottom

right-hand corner, in display coordinates. What is need now is to translate this active video area in display

coordinates into the familiar screen coordinates defined in part 1 of the series.

Figure 1:8-20 : Within the active display region, the display coordinates generated by the horizontal and

vertical timing counters could be converted into screen coordinates by a translation algorithm.

In our screen coordinate system pixel values start in the top, left hand corner at (0,0) and end at the right

bottom hand corner at (271, 479). It seems that what we need to do is create a module that would allow us to

translate the active periods generated by our horizontal and vertical timing counters into our screen coordinate

system. A display to screen coordinated module that could perform this translation for us, with the horizontal

and vertical periods used as control signals, can be seen in Figure 1:8-20.

So what does this module do exactly? Well it translates the display's coordinate system into the screen's

coordinate system. It is this translation that now provides us with the means to display images.

QU: 1 : If you were unhappy with the screen coordinate system could you convert it to a Cartesian

coordinate one, by transforming the screen coordinate system such that (0,0) is at the bottom left

hand corner and (271, 471) is at the top, right hand corner? Could this transformation be performed

in the same or similar module to the Display-to-Screen-Coordinates module?

You might be thinking at this point that this all sounds and looks good but we still have not displayed images on

the screen. Well, the next and final thing we need to do, in the development of our skeleton display driver, is

use the generated screen coordinate values to index our memory display area which could be either an internal

portion of a FPGA's embedded memory or an external memory module.

Figure 1:8-21 : A screen coordinate (x,y) can be used to index a pixel 's RGB color by using a color look-up

table.

If our screen coordinate value at any instance, (x,y), indexes the colour value in a look-up table, for instance,

and writes it to the screen within the same clock cycle, then our skeleton device driver is complete. However,

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 12/13

when indexing colour look-up tables problems associated with timing synchronisation and memory latency could

arise. If we cannot access the look-up table in the required time period, that is within 1 pixel clock cycle, then we

could require more capable and generally more expensive memory devices to achieve a zero turn around clock

cycle period.

Instead, what is need is a method that allows us to read a region of memory and store the data from it, a few

clock cycles earlier than it is required for display. Hence, we wiill still be in synchronisation with the horizontal

and vertical synchronisation timing signals, Hsync and Vsync respectively. That is, enough clock cycles earlier

to allow cheaper memory devices to be used. How this is done will be the subject of another next part of the

seriesthat could be titled: A Skeleton TFT-LCD Device Driver using Video Memory.

1.8.6 Application to the LQ043T3DX02 Display Driver Board

There is nothing like putting theory to practise! The DS0-2150 oscilloscope, reviwed previously, has been

attached to the LQ043T3DX02 prototype driver board, which is itself attached to the spartan 3A Starter

Kit. The sampling of the hsync and vsync signals can be seen in Figures 1:8-22 and 1:8-23 below. If your

skeleton device driver can display something similar then you're swimming!

Figure 1:8-22 : The Hsync periods of a skeleton display driver have been captured in this oscilloscope

screen shot. The amplitude of the Hsync signal is 3.19V and the horizontal scan frequency is measured to be

approximately 17.12Hz.

Figure 1:8-23 : The amplitude of the Vsync signal is 3.25V and the measured frequency of the vertical period

is 60.68 Hz. This period is known as the refresh rate of the display, is it what we were expecting?

As you have probably noticed the timing periods and hence the frequencies measured are slightly different

from our theoretical values. Where have these discrepancies come from?

1.8.7 Conclusion ^ back to top

06/11/13 Series 1: Part 8 - Writing A Skeleton TFT-LCD Display Device Driver

www.recontech.co.uk/index.php/projects/series-1-a-lq043t3dx02-display-driver-board/65-series-1-part-8-writing-a-skeletft-lcd-device-driver 13/13

Login

Fabien 0

Reply

@RecontechInfo 0

Reply

Enter text right here!

Name Email Website (optional)

Check Spelling

Comment as a Guest, or login:

Displayed next to your comments. Not displayed publicly. If you have a website, l ink to it here.

Submit Comment

Go to comments start

Well, this has really been a long journey. This part of the series has shown how to interpret the timing

characteristics in a display's data manual and use it to derive the essential synchronisation signals required to

display images. It has shown that paying careful thought to the architecture of a design, in a modular fashion,

should help develop blocks of code that can be reused in other projects. It has also shown that by developing

an efficient coding style and making use of all of the utility coding management software tools, that are

available, there is a greater chance of developing a skeleton display driver, or any module, that works

flawlessly!

Thanks for taking the time in reading another part in the series. Next time we will continue by developing our

new architecture and presenting a new display! That's all for now, until next time.

1.8.8 References

1. Higher Level Programming Abstractions for FPGAs using OpenCL, 2011, Altera Corp.

Comments (2)

Sort by: Date Rating Last Activity

· 59 weeks ago

Hi, Great articles, can't wait to see the outcome!

Have you tried looking at how commercial display drivers are implemented? You should implement a 8080 parrallel interface (8-32 bits) for much faster data rate. This is how most controllers work, and is compatible with all MCUs.

Do you plan to release the source code/design files for hobbyistes when this is done?

Thanks a lot!

· 59 weeks ago

Hi Fabien, Thanks for the comment. I am currently considering writing new articles, using 2.3" and 3.0" displays, that have 8080parallel interfaces. As the articles are developed I intend to release the source files as part of the tutorial series,probably using github.

Cheers Ben

Post a new comment

Subscribe to None

facebook

Creative Commons Licence Recontech (C) 2003 - 2013 is licensed under a Creative Commons Attribution-

NonCommercial-ShareAlike 3.0 Unported License