Re: A black strip on right side of LCD

Hi Bradley,

I've got the data*** from LCD vendor. According to the data***, Win XP's
signal forms are actually wrong and Win CE's signal forms are correct. But if
HSync action happens at the falling edge exactly, the Win XP signals should
also work.

Then I measured the timing of each signals and calculated how many data
could be sent between DENA signal. I was suppresied to find out that the Win
CE sends out exactly 800 data and Win XP sends out 804. I guess the extra 4
is due to my measurement error. So, my Win CE did send out 800 data
horizontally. Then the last 100 data (because I got only 700 pixels in
drawing a line horizontally) must be lost before the place the timing is
generated. I found an artical talked about display driver briefly. It seems
even the display driver calls functions with the resolution paramenter passed
to it. So, it seems my data are lost between the driver and whoever generates
the timing (assuming the driver got the data from boot.ini correctly). Am I
right? And what can I do to solve (or further trace) the problem? Any
suggestions?

Many thanks in advance!

John

PS. Other experts, any ideas and suggestions? Thanks.


"John" wrote:

Hi Bradley,

Your reply is very educaional. I think I've got a good idea of how a SBC
drives a CRT and an LCD simutanously. Thanks a lot.

I measured the frequencies on the LCD connector with running Win XP and Win
CE. The clock/DENA/HSync/VSync are a little different but all in the range of
the specs of my LCD module. The only thing puzzled me is that: the HSync
under WinXP is a positive pulse train. The pulse is about 3.8uS wide and two
pulses are about 32.1uS apart. The HSync under WinCE is a negative pulse
train. The pulse is about 3.2uS wide and two pulses are 26.4uS apart. If like
a CRT, the scanning signals use the polairty to control brightness (e.g. the
polarity of the pulse is for blanking the returning beam) how one of these
two HSync signals will ever work when the LCD module they drive is the same
module?

Also my SBC uses AMD LX800 display driver. I think it's file name is
ddi_agx.dll. Do you know anything about it, such as the effect of its keys in
registry, related ini file, its source code, ...? Do you know any other
display drivers that are compatible with an AMD CPU that I may be able to use
to replace ddi_agx.dll and give it a try?

BTW, I also drew some lines with different lengths on the LCD under WinCE.
The available width is 700 pixels (i.e. the black strip is 100 pixel wide).
Does this give you any clue?

Many thanks!

John

"Bradley Remedios" wrote:

On Jul 30, 12:15 am, John <J...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Thank you for the help. I am going to check the frequencies tomorrow. It
will be very interesting to see what the actual frequencies are. In the
meantime, could you teach me a little bit more about the display driving?

There are many methods of connecting a display that I am aware of for
Embedded Devices
1. Any Standard Interface (DVI/VGA/HDMI, ...) that is often found on
Desktops
2. Standard RGB Interface. This basically is a line for each bit, a
clock and some sync signals.
3. Another Interface whose name eludes me at the moment.
4. Probably more that I am not aware of.

I am not an expert in all the modes (in fact I've only dealt with the
RGB Interface myself.) The timing is pretty simple for the RGB
Interface. Essentially a pixel of color data is clocked into the
LCD. The frame is drawn horizontal line by horizontal line. The
Hsync and VSync is used to define where the frame starts and the
Porches are used to define data that gets thrown away, or is not
displayed on the screen.

I should have been more clear in my previous post, it assumed that the
Display Controller Outputs in format 2. Although, your problem is
most likely still a timing issue with your driver, where to look for
how the timing may be wrong may not be exactly as I mentioned if you
use a different interface from the Display Controller and to the LCD
itself.

My
SBC board can drive a CRT and an LCD at the same time. I can hardly believe
the CPU will spend time to run two display drivers to drive them seperately.

It might, I don't know how your SBC is designed, or what processor you
are using. It could take a RGB signal from the Display / LCD
Controller pass it through another IC / FPGA and voila you have a VGA
signal suitable for a CRT and another passed through suitable for an
LCD, or vice versa it could output as VGA suitable for a CRT and pass
that through generating signals for RGB suitable for an LCD.

It's also possible that there are two display controllers and two
video buffers and the display driver is handling the cloning (or
having both controllers point to the same video buffer.) It could
also be one display controller that that supports 2 Video Outputs and
1 or 2 simultaneous outputs.

In addition, I never specified what type of display to use when I built the
NK.bin. The reason I want to learn this is I want to know where the desktop
image signals are seperated and goes to each display, in software or in
hardware. This may give me some clues where to look for the problem because I
can drive both displays at the same time, one works fine and the other has a
black strip. But if say this is a hardware problem, I can have right (full)
images on both displays if I use Win XP. I hope you see why I am puzzled.

To proceed I would try to understand how your hardware is setup, then
I would look at your Display Driver. Because of the fact that it
works with another OS (Windows XP) I would assume that this is a
software problem with your BSP and that likely, it is configuring the
timing for the LCD incorrectly.

Hope that helps,
Brad.

.

Loading