Conversion of LCD to VGA
July 27, 2006 11:46 AM Subscribe
ElectricalEngineerFilter: I have an Intel XScale processor (on a gumstix, with integrated LCD controller. I think I've rigged up a way for it to output a VGA signal. Will you reality check my work?
In active mode, I note that the LCD controller puts out both a line clock signal, a frame clock signal, and a pixel clock signal. It produces 16-bit digital color information via a parallel interface.
The line clock seems to correspond to the HSync of VGA, while the frame clock seems to correspond to VSync. I can also get analog RGB values by DACing the color signals, using the pixel clock to pump the DAC.
With analog RGB values, an HSync, and a VSync, I have VGA.
QED?
(Note: I can, through software, vary the timings, add delays, etc.)
In active mode, I note that the LCD controller puts out both a line clock signal, a frame clock signal, and a pixel clock signal. It produces 16-bit digital color information via a parallel interface.
The line clock seems to correspond to the HSync of VGA, while the frame clock seems to correspond to VSync. I can also get analog RGB values by DACing the color signals, using the pixel clock to pump the DAC.
With analog RGB values, an HSync, and a VSync, I have VGA.
QED?
(Note: I can, through software, vary the timings, add delays, etc.)
Sounds to me like this should work. You'll need to check the polarity of the sync signals and make sure your line and frame rates are OK for whatever monitor you're using. If the precise timing of the hsync and vsync signals isn't software-controllable, you might need to introduce some delays so that your picture ends up in the right place on your screen.
You might even be able to press some other port into service to get DDC happening.
Best bet: suck it and see! Those gumstix look like a cute little device family - have fun!
posted by flabdablet at 4:55 PM on July 27, 2006
You might even be able to press some other port into service to get DDC happening.
Best bet: suck it and see! Those gumstix look like a cute little device family - have fun!
posted by flabdablet at 4:55 PM on July 27, 2006
Sounds like you don't want to hang your gumstix on an lcd screen... I'm gathering you want to drive a VGA CRT. While the signals correspond to their video equivalents (HSYNC, VSYNC, etc) I don't know that they are actual signal equals. I couldn't find any info in the Intel docs about the signal levels, timing, etc to give you a definitive answer. My guess is you could do it but you'd be far better off just going with an LCD panel.
For what it's worth, VGA used Look-Up Table (LUT) DACs. They took an 8bit value from the processor, ran it thru the DAC which converted it to the 18bit (six bits per color) needed. With sixteen bits, you'll have slightly less color range but that's not a huge problem.
This site is slightly helpful if short on the schematic level stuff.
posted by jdfan at 5:06 PM on July 27, 2006
For what it's worth, VGA used Look-Up Table (LUT) DACs. They took an 8bit value from the processor, ran it thru the DAC which converted it to the 18bit (six bits per color) needed. With sixteen bits, you'll have slightly less color range but that's not a huge problem.
This site is slightly helpful if short on the schematic level stuff.
posted by jdfan at 5:06 PM on July 27, 2006
You need to configure your LCD controller for TFT mode to generate Vsync and Hsync. You will also need a RAMDAC with 75-ohm output buffers for RBG or else external buffers. You may have to tweak the Vsync and Hsync timings.
I assume that your LCD controller will output zeros during the blanking intervals or else you will have to handle blanking yourself. This can be done by using an XNOR gate to generate a composite sync signal. The composite sync is used on the blank# pin of the RAMDAC to turn off RBG during the retrace intervals.
You don't have to use the palette tables in the RAMDAC. Most can be configured to operate in true-color bypass mode, so you don't need to ever load the tables. You are just using the RAMDAC as a video buffer with a blanking input.
posted by JackFlash at 5:36 PM on July 27, 2006
I assume that your LCD controller will output zeros during the blanking intervals or else you will have to handle blanking yourself. This can be done by using an XNOR gate to generate a composite sync signal. The composite sync is used on the blank# pin of the RAMDAC to turn off RBG during the retrace intervals.
You don't have to use the palette tables in the RAMDAC. Most can be configured to operate in true-color bypass mode, so you don't need to ever load the tables. You are just using the RAMDAC as a video buffer with a blanking input.
posted by JackFlash at 5:36 PM on July 27, 2006
Theoretically yes but it depends heavily on how fast the LCD is refreshing. You want to refresh your VGA at no less than 50Hz, preferably 75 otherwise it will fail to sync; likewise keep it under 100Hz and check the specs on your monitor to ensure that the hsync frequency is in range; if it's not, the monitor will not lock onto the signal.
Another thing to keep in mind is that LCD interfaces often pump out multiple pixels per clock cycle, eg 4. That means you'll effectively have 1/4 of the horizontal resolution that you think you do unless you want to go to a shitload of effort to buffer those 4 pixels and DAC them individually clocked from a PLL.
One last thing: LCD has no front or back porch, let alone a vertical refresh pause. You will need to insert those dead times into your VGA signal to give the monitor time to get the electron beam back to where it needs to be after each scan line. If you want examples of the sorts of timing involved, see this or look at the "Mode Lines" in an XFree86 configuration file - they contain all the appropriate times for a huge number of interesting modes.
Unless you're buffering data and clocking it out off a different clock (ie building a whole VGA controller), you're going to have to take the porches and retrace times off the edge of your framebuffer, resulting in much reduced
resolution.
In summary: possible, very difficult or very low performance and fairly pointless unless the exercise is "I'm a rockin' EE hacker". Just plug a LCD in if what you want is to see the image.
posted by polyglot at 5:46 PM on July 27, 2006
Another thing to keep in mind is that LCD interfaces often pump out multiple pixels per clock cycle, eg 4. That means you'll effectively have 1/4 of the horizontal resolution that you think you do unless you want to go to a shitload of effort to buffer those 4 pixels and DAC them individually clocked from a PLL.
One last thing: LCD has no front or back porch, let alone a vertical refresh pause. You will need to insert those dead times into your VGA signal to give the monitor time to get the electron beam back to where it needs to be after each scan line. If you want examples of the sorts of timing involved, see this or look at the "Mode Lines" in an XFree86 configuration file - they contain all the appropriate times for a huge number of interesting modes.
Unless you're buffering data and clocking it out off a different clock (ie building a whole VGA controller), you're going to have to take the porches and retrace times off the edge of your framebuffer, resulting in much reduced
resolution.
In summary: possible, very difficult or very low performance and fairly pointless unless the exercise is "I'm a rockin' EE hacker". Just plug a LCD in if what you want is to see the image.
posted by polyglot at 5:46 PM on July 27, 2006
The XScale LCD controller has timing registers that can adjust the HSync width, VSync width, porch delays, and signal polarities. You will have to study the specs to see if these will give you the resolution you need to meet the VGA monitor specs. Keep in mind that horizontal timings are multiples of the pixel clock and the vertical timings are multiples of the line clock.
You can configure the controller for 16-bit pixel mode. This gives 5 bits of red and blue and 6 bits of green for each pixel. You can ground the unused inputs to the DAC.
The controller also has a BIAS pin that can be used for DAC blanking, so you don't need to generate a composite sync.
posted by JackFlash at 7:14 PM on July 27, 2006
You can configure the controller for 16-bit pixel mode. This gives 5 bits of red and blue and 6 bits of green for each pixel. You can ground the unused inputs to the DAC.
The controller also has a BIAS pin that can be used for DAC blanking, so you don't need to generate a composite sync.
posted by JackFlash at 7:14 PM on July 27, 2006
I found this thread at eng-tips when I searched for "microcontroller VGA output". The LCD out might make it easier, but perhaps not by as much as you hope..
posted by Chuckles at 8:20 PM on July 27, 2006
posted by Chuckles at 8:20 PM on July 27, 2006
« Older Does "economies of scale" really make a business... | Should I take a permanent job knowing I'll only be... Newer »
This thread is closed to new comments.
I'm confused... do you just want to drive something with VGA? If so, check out these which generate VGA based on a serial stream (can you give up a serial port on the Gumstix?).
posted by phrontist at 1:22 PM on July 27, 2006