8051 to DVI interface?
in [Embedded]
|
From: Paul Carpenter on 12 Feb 2007 14:11 On 12 Feb, in article <1171301228.735967.108130(a)a34g2000cwb.googlegroups.com> zwsdotcom(a)gmail.com "larwe" wrote: >On Feb 12, 11:37 am, Guy Macon <http://www.guymacon.com/> wrote: > >> I am still thinking that a counter clocking data out of >> RAM can make a VDI signal. > >I agree this sounds doable, but I would not expect this system to work >unless you are delivering at minimum VGA scanrates. > >A method I used to drive an LCD (not DVI) "directly" from an 8051 was Well I would first look at the manufacturers of the DVI (LVDS etc chips) for example National DS90CF383, they have a whole series of app notes on driving monitors using these sorts of interfaces. >to embed the sync signal in spare RAM bits; i.e. I used two bits each >for r,g,b in a x8 SRAM and put the v-sync and h-sync bits in the >remaining bits. The v-sync bit caused a micro interrupt; the micro >then held v-sync active while resetting the counter that addressed the >video RAM. (Actually it was a bit more complex than this - the micro >tristated the counter and held the v-sync active, then if necessary >wiggled the address/data bus on the RAM to update display data). The problems I have found with various LCDs/monitors that use a DVI or DVI style interface, they can go screwball if you miss one clock cycle or worst get one pixel difference between two frames. They tend to use Hsync Vsync and enable as helpers, and not resyncers as monitors do, so make sure you have the right amount of clock pulses on every line INCLUDING blanking. Work out what scheme of bpp you want as well as encoding. Supply the parallel data to the LVDS or TMDS chip and timing and you are away. >Your intermediate divider and base dot clock will depend on what >resolution you want to use to drive the display. You will probably >also want to add extra logic so that you can reuse scanline data; i.e. >have separate scanline and dot position counters and ignore the lower >bits. Make sure the clock sent has the expected frequency for the display format even if you are using it a lower resolution, not all the rescalers are good at dcoding and expect exact frequencies and ratios. >Let's try to work some nice numbers into this. Start with a 32kHz horz >sync, since it's a nice round number. You need to supply a v-sync >pulse every 480 lines, which is 15ms (66.67Hz). Some displays will balk at that especially if they do not get a repeated frame in 40-60 Hz rate. LCD specs are notoriously at specifying min and max clock, Hsync, Vsync rates. they tend to spec at one display format only. -- Paul Carpenter | paul(a)pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate
From: Paul Carpenter on 12 Feb 2007 14:21 On Monday, in article <7_2dnYDFG7p0Ok3Y4p2dnA(a)giganews.com> http://www.guymacon.com/ "Guy Macon" wrote: >Guy Macon <http://www.guymacon.com/> wrote: > >>I am working on an 8051-based project that needs a >>display. Normally I would just use a small character- >>based LCD display, but in this case I am thinking of >>going with something a bit more impressive; a standard >>flat-panel PC monitor. > > >Here are the results of my resarch so far: > >This fellow did 20 rows by 20 columns of 8x12 characters >using a 16MHz AVR.: >http://www.serasidis.gr/circuits/AVR_VGA/avr_vga.htm Not bad, but like all things you do not see what the overhead of changing the text is like as to what happens on scrolling the text as a new line is added. >..and a simle colorbar generator: >http://www.serasidis.gr/circuits/colour_bar_gen/colour_bar_gen.htm > >If a 16Mhz. AVR can do that, what can a 100mips Cignal C8051F120 do? Firstly Mips means nothing when doing video circuits, continuous data bandwidth is the major key, as you cannot miss anything or everything slides or gets holes in. Not very impressive, considering I have driven two LCDs with parallel 24 bit to EACH LCD from one PLD, having proper 8 colours in the colour bar pattern, greyscale ramps (ALL codes) and many other patterns, no memory required. Each LCD had switch selectable pattern, inverted, missing colours and other test functions. Each LCD could display its own pattern. That was with a 128 macrocell device. Not uncommon for me to drive 10 bit video ADCs to generate the analog signals. >A OMAP5910 might have potential: >http://focus.ti.com/lit/an/spra847/spra847.pdf I class most we can do complete VGA in a micro as 'willy waving' excercises to show what a processor can do, not whether it is a useful example or exercise. Have any of the above been used in anger? Are they more than just interesting projects documented on web pages? >Or maybe this TVT-KVGA: >http://www.tvterminal.de/Flyer_TVT_KVGA_international_070129.pdf Probably closest to what you are looking for but analog not DVI output, would need digitising and serialising to use the digital portion of the DVI interface. From about 1981, when I was working at DEC in Reading it would considered as what was then the VT30H (quad and hex unibus card) graphics controller, converted to VT30S. This had 8085A processor to control the colour graphics controller and keyboard for remote mimic displays in factories/railways and the like. The ANSI command set makes it look like later VT30S or VT2xx colour terminal on a chip actually at lower resolution. >The Parallax Propeller appears to have some sort of "video object": >http://www.parallax.com/propeller/index.asp Not had time or resources to test the usefulness of this approach but see it more as another interesting exercise and what can be done. Whether it is useful or can provide the parallel digital output to drive the LVDS/TMDS interface is to be seen as these interfaces run at 7 x main clock rate by internal PLL. >Or maybe a Xlinnx XC4005XL? >http://www.ece.umr.edu/courses/cpe214/vga_datasheet.pdf The basis of that in a newer chip could easily provide the VGA timing and control a dual port RAM, which favoured display cycles to host cycles which in simplest forms can have WAIT states inserted. Interupts for H and V blanking can get major updates done. Xilinx and Altera have examples for NTSC timing generation so it would be easy to implement. >Or I could go with good old DonTronics: >http://www.dontronics-shop.com/product.php?productid=16388&cat=262&page=1 Without knowing more of the application it is difficult to say as most of theirs seem suited to CSTN/STN displays that operate differently to TFT the major types of LCD on DVI interface monitors. Their outputs are analog or stepped analog (crude R2R ladders for lower res), which is not much use on a digital DVI interface. >Any thoughts on any of the above? Important questions Are you displaying symbols/text/moving text or just changing complete display frames (aka bill board advertising) What type of DVI interface are you going to do Analog Digital Both at same time How often does a display change (average and peak) Is colour required? What is the max update rate for say a screen full of text scrolling to add another complete line of text or Direct Cursor Addressing to change a partial of whole line of text. The big killers in simple text displays is scrolling/inserting text in the display and what happens to wrapped or cropped data. The other killer is how they scroll the text i.e. jump or smooth for the character lines. Do any of these blank displays during large updates, and what is a large update for each controller? I have seen many that assume a few characters of change occur a second so stop displaying video to do the update. It is better to update as low priority compared to displaying to avoid extra flicker and judder on displays. >Guy Macon ><http://www.guymacon.com/> -- Paul Carpenter | paul(a)pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate
From: nappy on 12 Feb 2007 19:23 "Paul Carpenter" <paul$@pcserviceselectronics.co.uk> wrote in message news:20070212.1921.325648snz(a)pcserviceselectronics.co.uk... > > What type of DVI interface are you going to do > Analog What is an analog DVI interface? :) > Digital > Both at same time > > How often does a display change (average and peak) > > Is colour required? I don' think there is a monochrome DVI protocol.
From: Homer J Simpson on 12 Feb 2007 20:21 "Guy Macon" <"http://www.guymacon.com/"@example.com> wrote in message news:9KKdnQkb_NJoMlPY4p2dnA(a)giganews.com... > I am working on an 8051-based project that needs a > display. Normally I would just use a small character- > based LCD display, but in this case I am thinking of > going with something a bit more impressive; a standard > flat-panel PC monitor. > Another possibility would be some sort of display chip; > does anyone know of one suitable for a slow 8-bit micro? Look at "The Cheap Video Cookbook" Donald E. Lancaster, Vols 1 and 2.
From: Frank-Christian Kruegel on 13 Feb 2007 04:47
On Sun, 11 Feb 2007 05:56:03 +0000, Guy Macon <"http://www.guymacon.com/"@example.com> wrote: >I am working on an 8051-based project that needs a >display. Normally I would just use a small character- >based LCD display, but in this case I am thinking of >going with something a bit more impressive; a standard >flat-panel PC monitor. Depending on your needs TV and teletext chips would be another option. Philips makes the SAA5x9x series, which is 8051 based, and some of these chips even allow external data and external program memory. These processors have video hardware inside, and instead of receiving teletext data you could write into the internal display ram in order to to display things. Some of these are also 100/120 hz ready. The older chips (SAA1054 etc) were i2c controllable, without internal CPU. If you can still get them, they are easier to work with due to lower pincount. You must feed an empty BAS signal (sync only) into these controllers for video timing. Mit freundlichen Gr��en Frank-Christian Kr�gel |