8051 to DVI interface?
in [Embedded]
|
From: werty on 18 Feb 2007 01:25 > werty wrote: > >But for $10 and cleverness , you can go 100 > >times faster , yet use the same bandwidth . > >I will place many white LEDs in a matrix , > >and place white paper "notes" and images > >over the LEDs . ----------------------------------------- white paper covering white LEDs to communicate 100 times faster , with a human . start with 30 . Change the image as you create the software , to make the image , most intuitive . --------------- Imagination is more important than knowledge ... You cant do nuttin , only talk and write .
From: werty on 18 Feb 2007 01:42 > DDC = Display Data Channel > TMDS.= Transition Minimized Differential Signal I am an expert on ultra high speed serial . TMDS is obviously advert's , because you must minimize all transistions , and increase all data rates , as a ratio. And differential , rejects absorbed noise on the line . Any strong noise will add to both wires and cancel in the transformer . Everything today , is Run Length Limited , because its so good . Your HDD and USB and FireWire use it . So its all hype . I will be creating a new USB , bi-direction mode at 10 Giga Bits/sec . It needs new hardware . USB hi-speed can be up'd to 800 . I think you will succeed , if you assume the DVI-d ppl are lying to cover up a very simple digital system . Its just mostly Lum' and less color . and sending increments , then a full ref frame occasionaly . But why do you need to send a full Ref frame , unless you think it will lose "sync' !! And DescreteCosTransform is also Hype . There is a simple , common sense way to compress video , all you need is the desire and some hands on , and any one can beat MPEG . First ill do O.S. , then DVD ( MPG-2) ...JPG
From: Ian Bell on 18 Feb 2007 03:19 werty wrote: >> werty wrote: >> >But for $10 and cleverness , you can go 100 >> >times faster , yet use the same bandwidth . >> >I will place many white LEDs in a matrix , >> >and place white paper "notes" and images >> >over the LEDs . > ----------------------------------------- > > white paper covering white LEDs > > to communicate > > 100 times faster , with a human . > > start with 30 . Change the image > > as you create the software , to make > > the image , most intuitive . > Another technobabble troll hiding behind google groups. Ian
From: Paul Carpenter on 18 Feb 2007 05:54 On Sunday, in article <7JCdnWmhUqAwekrY4p2dnA(a)giganews.com> http://www.guymacon.com/ "Guy Macon" wrote: >CBFalconer wrote: .... >> >>Cool down. There is some sort of misunderstanding going on. Guy >>is a long term reputable contributor to c.a.e. You also appear to >>be knowledgeable and helpful. > >My apologies to "nappy" if my words came across as I suspect they >did judging from his response. I really would like answers to my >questions from someone with experience in developing displays. > ..... > >Getting back to the design; here is where I am so far: > >Even a 100 Mips 8051 isn't fast enough to directly generate >1024 x 768 video at 60Hz refresh. > >It looks like a counter clocking the address lines of a SRAM >will get me the video signal as parallel data, and that I can >turn the same data to VGA with some DACS and to DVI with some >sort of encoder. > >32 data bits seems like it will do the job, 8 for each color and >the rest for synch, resetting the counter, etc. Considering you are driving this display from a 8051 microcontroller. Do you really need to store full 24 bit colour information? How many colours do you need? Will you be displaying images like photos? I would consider using at most 8 bits for colour information or 9 to make it easier to process on video side. Then you only need 3 bit DACs or your own R/2R ladders for analog o/p, you can choose how to make the palette of colours. Effectively what 24bit colour codes are represented by the 8/9 bits stored. Weighting of R/2R ladder to be a summing point of different levels is a crude way to do it. Remember 8 bits for 256 colours is actually about the full COUNT of colours on most windows systems (when not displaying images). Storing the timing information in RAM is inefficient and will greatly increase the size of RAM required. Let alone the processing you will need to do. For example a typical VGA timing format, XGA - 1024 x 768 will be suitably larger but I don't have the figures at hand:- Pixel Clock 25.175MHz Line Frequency 31.469kHz Frame Freuency 59.94 Hz Line is 800 pixels total Active 640 pixels Blanking 160 pixels (front/back porch & sync time) Frame is 525 lines total Active 480 lines Blanking 45 lines (front/back porch & sync time) Therefore a full 'pixel' memory map of VGA is 800 x 525 pixels = 420000 pixels for 32 bit 'pixels' = 1680000 bytes (1.602 MB) Active Video is 640 x 480 pixels = 307200 pixels for 32 bit 'pixels' = 1228800 bytes (1.172 MB) So roughly 430kB is used just to store blanking information. For 1024 x 768 the data size is roughly increased by the ratio of the active dimensions e.g. (1024 / 640) * 800 = 1280 approx pixels per line (768 / 480) * 525 = 840 approx lines per frame Giving total memory as 1280 * 840 * 4 = 4300800 bytes (4.1MB) So your data storage (and hence address counters) is getting large and probably starting to get unweildy for your 8051 with its 64kB memory map. Simpler solution is PLD with pixel, line and address counter inside to deal with the timing and addressing memory. I would consider a device to take 8bit data and convert to 24 bit data (some lines may be fixed low or high) to pass to DACs and encoder chips. At simplest level you could use 3:2:3 encoding for RGB in the 8 bit data. These bits become the MSb of each RGB with remaining bits of the 24bit data fixed at 0. At the most complex you use a pallette of 256 colours and a wide LUT to convert at pixel clock rate into a 24bit value, which is what a lot of graphics and image processing systems have been doing for many years. Even this can be done in PLD/FPGA with 3 x 256 x 8bit tables if the PLD/FPGA has enough size. >Two banks will allow the 8051 to modify the undisplayed bank >with no particular time constraints -- a good thing considering >the bank switching and byte selection needed to fill a 32 bit >by 1 megabyte SRAM with a 8 bit by 64K microcontroller. But you will probably never need full 24bit unless you are displaying photo quality stills, as you will never have the processing power to run video through your 8051. >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: exp(j*pi/2) on 20 Feb 2007 21:07
On Feb 18, 12:19 am, Ian Bell <ruffreco...(a)yahoo.co.uk> wrote: > werty wrote: > >> werty wrote: > >> >But for $10 and cleverness , you can go 100 > >> >times faster , yet use the same bandwidth . > >> >I will place many white LEDs in a matrix , > >> >and place white paper "notes" and images > >> >over the LEDs . > > ----------------------------------------- > > > white paper covering white LEDs > > > to communicate > > > 100 times faster , with a human . > > > start with 30 . Change the image > > > as you create the software , to make > > > the image , most intuitive . > > Another technobabble troll hiding behind google groups. > > Ian It's indeed unfortunate that anal-retentive net nannies, like you, have such a problem with so-called trolls hiding behind google groups. That really wouldn't be a problem if pu__ies like you had a real life. |