Connect with us

8051 to DVI interface?

Discussion in 'Electronic Design' started by Guy Macon, Feb 11, 2007.

Scroll to continue with content
  1. Didi

    Didi Guest

    The monitors I develop are multi format. The H&V timings for DVI are
    Thanks, I hoped this would be the reason. This makes it quite
    likely that digital-only interfaced monitors will work at
    much lower frequencies than 60-70 Hz, perhaps out of spec.
    (One reason to prefer lower frequencies is to have the RAM
    consume less power).
    I still wonder why the strive for faster TFT-s, they
    now specify 8 mS response times, what's that about?
    I doubt we can see the difference between 30 and 8 mS...
    But then may be the test conditions are such that 8 mS
    is 10 to 90% and the tails are much longer and can be
    seen at lower speeds, I never dug into that.

    Dimiter
     
  2. nappy

    nappy Guest

    Graphics, animation, video.

    Oh yes we certainly can. Especially when it is repetetive.
     
  3. On Friday, in article
    <12lBh.15136$>
    Finding LCDs at one time with response times sufficient for real time
    stereo dispalys was a pain. Easier now.
    Especially if it is something moving fast across the screen.
     
  4. Guy Macon

    Guy Macon Guest

    I am having trouble reconciling the above with the previous
    claim that "no analog DVI interface for monitors exists."
    That's not an answer to the question I asked.
     
  5. nappy

    nappy Guest

    I answered your question. It was a silly childish attempt at some kind of
    test. My displays are running in military aircraft all over the world. Not
    Mattell.

    There is no such thing as an analog-digital anything. If you are having
    trouble understanding that then go read the DVI spec again. It is simpy VGA
    piggybacked on a DVI connector. . It is NOT DVI.

    So blow it.

    test over.
     
  6. CBFalconer

    CBFalconer Guest

    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.

    --
    <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
    <http://www.securityfocus.com/columnists/423>

    "A man who is right every time is not likely to do very much."
    -- Francis Crick, co-discover of DNA
    "There is nothing more amazing than stupidity in action."
    -- Thomas Matthews
     
  7. He is looking from a different perspective:-

    You are looking the DVI connector spec for COMMERCIAL monitors (VESA)
    Which have analog and digital interface on same connector.

    He is ONLY thinking about what you would see as the DVI pins. (DVI only)
    Once you have time for line, frame, active and resolution, you can work it
    out.

    e.g. dot clock is basically H pixels in H active time
    line time divided by dot clock gives pixel counts per line
    Non-active periods gives you relative position of active to whole line

    Similarly V timings give you total number of lines and position
    of active lines to vertical blanking and whole frame
     
  8. craigm

    craigm Guest

    This may, or may not help.
    http://www.ramelectronics.net/html/DVI_info.html
     
  9. nappy

    nappy Guest

    Resepct is a good thing. I don't take to people calling me a liar. Or
    expecting me to complete some test of theirs.
     
  10. Engineer

    Engineer Guest

    That's a set of indicators, not a display. Indicators
    are a great solution if the information to be displayed
    is binary and known beforehand, but dispays are more
    appropriate for arbitrary text and graphics.
    You do not appear to have read the thread. Nobody mentioned
    Microsoft, Linux, C++. We are talking about an 8051 and some
    custom hardware.
    You obviously are not familiar with the fact that I have been
    an advocate of FORTH for embedded systems for many years.
    That being said, it doesn't help to tell fibs about how fast
    C++ coders can finish a job. The good ones are very fast indeed.

    BTW, Usenet posts are usually single spaced.
     
  11. Guy Macon

    Guy Macon Guest

    That's a set of indicators, not a display. Indicators
    are a great solution if the information to be displayed
    is binary and known beforehand, but dispays are more
    appropriate for arbitrary text and graphics.
    You do not appear to have read the thread. Nobody mentioned
    Microsoft, Linux, C++. We are talking about an 8051 and some
    custom hardware.
    You obviously are not familiar with the fact that I have been
    an advocate of FORTH for embedded systems for many years.
    That being said, it doesn't help to tell fibs about how fast
    C++ coders can finish a job. The good ones are very fast indeed.

    BTW, Usenet posts are usually single spaced.

    Guy Macon
    <http://www.guymacon.com/>
     
  12. Guy Macon

    Guy Macon Guest

    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.

    By the way, I strongly suspect that there are more aircraft flying
    that contain parts that I designed than contain parts he designed,
    but that is purely a function of the fact that aircraft have many
    more hydraulic actuators than they have custom digital displays,
    not a metric of engineering prowess.

    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.

    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.

    Guy Macon
    <http://www.guymacon.com/>
     
  13. werty

    werty Guest

    -----------------------------------------

    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 .
     
  14. werty

    werty Guest

    DDC = Display Data Channel

    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
     
  15. Ian Bell

    Ian Bell Guest

    Another technobabble troll hiding behind google groups.

    Ian
     
  16. 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.
    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.
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-