Shop OBEX P1 Docs P2 Docs Learn Events
HDMI added to Prop2 — Parallax Forums

HDMI added to Prop2

cgraceycgracey Posts: 14,134
edited 2018-10-16 13:59 in Propeller 2
It seems to be working on the FPGA, but I now realize it's too slow to test, as the FPGA only goes to 80MHz.

Does anyone know of a data-to-TMDS translator program that lets you check the output of a TMDS encoder?

It's set up so that any set of 8 pins can be as follows:

rel 7 = Red+
rel 6 = Red-
rel 5 = Green+
rel 4 = Green-
rel 3 = Blue+
rel 2 = Blue-
rel 1 = Clock+
rel 0 = Clock-

It should route straight from the P2 pins to the female HDMI socket.

Does anyone know if the Clock+/- has any relative timing requirement in relation to the data? It cycles at 1/10th the Red/Green/Blue bit rate.
«13456721

Comments

  • Found this, but no idea if/how it works:

    https://github.com/mithro/tmds_encoding
  • RaymanRayman Posts: 14,571
    edited 2018-10-16 14:53
    I think you can do 480p over DVI/HDMI and that only needs a 25 MHz clock...

    At 75 MHz, you can do 1080p @30 Hz, but not everything accepts this...


    Never mind, what was I thinking... You need to do a bunch of bits at 25 MHz...

    Wait... Don't you need a 250 MHz clock just to do 480p VGA?
  • Wuerfel_21Wuerfel_21 Posts: 5,011
    edited 2018-10-16 15:01
    Rayman wrote: »
    Wait... Don't you need a 250 MHz clock just to do 480p VGA?
    An IBM VGA card's pixel clock is 25.175 MHz, i believe.
  • Been searching for a precalculated LUT, but couldn't find one :neutral:

    I think the clock fronts are aligned with the 10-bit packets, see:
    https://image.slidesharecdn.com/hdmivijaychachara152-140526050115-phpapp02/95/hdmi-15-638.jpg?cb=1401082522
  • cgraceycgracey Posts: 14,134
    Yes, we need 250MHz to be real-time for the bottom-end of 640x480 @60Hz.
  • Rayman wrote: »
    I think you can do 480p over DVI/HDMI and that only needs a 25 MHz clock...

    At 75 MHz, you can do 1080p @30 Hz, but not everything accepts this...


    Never mind, what was I thinking... You need to do a bunch of bits at 25 MHz...

    Wait... Don't you need a 250 MHz clock just to do 480p VGA?

    Yep, but there are also XXXp30 modes (progressive at 30Hz) requiring half the rate, which is still rock solid because the display buffers the whole page.

    Alternatively, the same TFP410 encoder that you used in the SSD1963 card would probably work, but requires a whole bunch of parallel RGB pins.
  • evanhevanh Posts: 15,853
    edited 2018-10-16 15:33
    Ah, oh, new hardware being designed into the prop2 I presume. I'm guessing this is really an LCD LVDS engine. Not actually HDMI with all its extra baggage.

    Chip,
    That's what I'd search for - LCD LVDS timings. You should find heaps of datasheets for various converter chips and embedded controllers, containing plenty details on the timings.

  • RaymanRayman Posts: 14,571
    TFP410 is easy to work with and number of pins depends on color depth you need...
    Be nicer to have one with I2S stereo included...
    I was contemplating a 1.4 version to do 3D...

    But, if P2 is stable at 250 MHz then having native 480p HDMI ability might be nice...
  • cgraceycgracey Posts: 14,134
    I worked it into the streamer. It takes the upper 3 bytes of the output long for R/G/B and the lower byte is used for command codes. In lieu of the normal 32 bits, it outputs {24'b0, r, !r, g, !g, b, !b, clk, !clk}. You have to pace your pixels at 1/10th the chip clock using 'SETXFRQ ##$0CCCCCCC'. To enable HDMI encoding: 'SETCMOD #$80'. It's maybe only good for 640x480 @60Hz, but gets us an HDMI output that will work with modern displays.
  • cgraceycgracey Posts: 14,134
    evanh wrote: »
    Ah, oh, new hardware being designed into the prop2 I presume. I'm guessing this is really an LCD LVDS engine. Not actually HDMI with all its extra baggage.

    Chip,
    That's what I'd search for - LCD LVDS timings. You should find heaps of datasheets for various converter chips and embedded controllers, containing plenty details on the timings.

    If we can generate HDMI signalling, does it still suffer from baggage?
  • evanhevanh Posts: 15,853
    edited 2018-10-16 16:06
    To be honest, I've not studied HDMI at all. I just assume LVDS, DVI,HDMI and DisplayPort are all the same at the basic framing/clocking level.

    On that basis, the distinction is the baggage.
  • cgraceycgracey Posts: 14,134
    edited 2018-10-16 16:07
    evanh wrote: »
    To be honest, I've not studied HDMI at all. I just assume LVDS, DVI,HDMI and DisplayPort are all the same at the basic framing/clocking level.

    On that basis, the distinction is the baggage.

    It doesn't look to bad to me. There's an encoding technique for the R/G/B bytes that become 10 bits (TMDS) and there are some control codes that can be output on those three channels, as well. Then, the pixel clock (25MHz) is output differentially, without any encoding. Seems pretty simple. I just need to be able to prove it, is all.
  • evanh wrote: »
    To be honest, I've not studied HDMI at all. I just assume LVDS, DVI,HDMI and DisplayPort are all the same at the basic framing/clocking level.

    On that basis, the distinction is the baggage.

    Yes, DVI and HDMI are equivalent for most purposes. I used Rayman's DVI board only with HDMI displays, with a simple passive DVI-I to HDMI adapter, since I have none with DVI input.

    IMHO the "baggage" (i.e. copy protection, ethernet, and all that stuff) can be safely ignored, that's what 99% of the FPGA implementations of HDMI output are doing anyway.
  • kwinnkwinn Posts: 8,697
    Been searching for a precalculated LUT, but couldn't find one :neutral:

    I think the clock fronts are aligned with the 10-bit packets, see:
    https://image.slidesharecdn.com/hdmivijaychachara152-140526050115-phpapp02/95/hdmi-15-638.jpg?cb=1401082522

    Checked a dozen or so papers on TMDS and there is no mention of any required phase relationship between the data and clock, although all the diagrams look similar to what Antoine linked to. Did see data rates of 10 x clock and 14 x clock mentioned so it looks like it is there for a PLL to lock on to and sync to the data bits.
  • kwinnkwinn Posts: 8,697
    That HDMI interface sure looks like it could be very useful. Looking forward to playing with it to see if it can be used for sound, data transmission, and other things as well as video output.
  • cgraceycgracey Posts: 14,134
    edited 2018-10-16 16:25
    Thanks for the links, Guys. I will make the clock start high. Right now, it's starting low.
  • evanhevanh Posts: 15,853
    Apologies, I'll take all that back. LCD LVDS is not the same LVDS as I remember from way back. It works on a row and column signalling mechanism rather than the traditional scan line mechanism.

    So don't look to LCD LVDS for any help on HDMI.

  • evanh wrote: »
    Apologies, I'll take all that back. LCD LVDS is not the same LVDS as I remember from way back. It works on a row and column signalling mechanism rather than the traditional scan line mechanism.

    So don't look to LCD LVDS for any help on HDMI.
    For a micro controller would it be better to support LCD LVDS instead of HDMI? Or maybe in addition to it? It seems like HDMI would be used less, maybe just for retro computing platforms and self-hosted development environments.
  • David,
    Most of the SBC's like the Pi, support HDMI. Some also support LVDS displays.
    There are tons of small/cheap hdmi panels now too (think 3-10 inch), largely because of the SBCs.
  • Chip, as for proving it, can a dedicated FPGA circuit do it, if that is all it is doing?

    Feed it from a data pattern in RAM, or the existing P2.
  • Roy Eltham wrote: »
    David,
    Most of the SBC's like the Pi, support HDMI. Some also support LVDS displays.
    There are tons of small/cheap hdmi panels now too (think 3-10 inch), largely because of the SBCs.
    Yes, I'm aware of those things. I'm just wondering if those are things a hobbyist might use but not someone building a commercial product.
  • evanhevanh Posts: 15,853
    Doug,
    Not in the way the Prop2 would end up. It would be some really convoluted staggered switching of flops to each output pin. Using every clock generator in the CycloneV.

  • potatoheadpotatohead Posts: 10,261
    edited 2018-10-16 16:59
    Would the LVDS need more than a streamer change?

    More state, not just a fairly simple serial stream?

    HDMI would be a very nice bullet point. Given it really is just a clock speed and minor streamer change, I would argue worth it.

    What people end up doing is very hard to tell. Honestly, half the chip is about options. Once people have them, who knows?

  • RaymanRayman Posts: 14,571
    edited 2018-10-16 17:01
    Seems the real P2 at 250 MHz should be able to create a simple test pattern of a couple different colors pretty easily...

    BTW: The TFP410 can input 24 bits using only 12 pins as I recall using a DDR type thing...
  • Considering the HDMI out costs essentially as much as the connector (plus potential licensing fees, but I've seen plenty HDMI equipped products that I'm pretty sure don't pay a single penny to the licensing trolls), products might just get the HDMI added on, especially if there's some other kind of display already.
  • evanhevanh Posts: 15,853
    edited 2018-10-16 17:30
    David Betz wrote: »
    evanh wrote: »
    Apologies, I'll take all that back. LCD LVDS is not the same LVDS as I remember from way back. It works on a row and column signalling mechanism rather than the traditional scan line mechanism.

    So don't look to LCD LVDS for any help on HDMI.
    For a micro controller would it be better to support LCD LVDS instead of HDMI? Or maybe in addition to it? It seems like HDMI would be used less, maybe just for retro computing platforms and self-hosted development environments.

    Looking around some more, I think there is two LCD interfaces called LVDS. Eg: https://www.winstar.com.tw/products/tft-lcd/module/ips-lcd.html
    That pinout looks much more like what I remember. The other one, with row and column, was from a TI chip datasheet.

    Here's a datasheet with signal timings, this is the one to support for embedded designs - http://www.display-solution.com/pdf/tft-displays/AUO/AUO_G185XW01 V2_20151012.pdf

    EDIT: Page 17 has the whole format. I remember that now because it is 7 serial bits per clock. The 7 stood out as oddly distinctive.

    Also known as CameraLink I believe.
  • I'm assuming it would be LVDS that would support touch screens?
    I will eventually want to use a small touch screen connected to the P2 but I have not looked into the requirements yet.

    j
  • evanhevanh Posts: 15,853
    edited 2018-10-16 17:47
    LVDS is electrical spec for digital data, it's purpose is to maximise data rate. The name gets reused for whole interfaces that are based on it.

    Differential analogue signalling of a bare touch surface is another world away where high sensitivity, not speed, to analogue changes in voltage and current is the game.

    EDIT: You may be wanting to communicate with a ready made touch controller though. These have historically used a separate interface from the display. Could be comport or I2C or SPI.

  • potatohead wrote:
    HDMI would be a very nice bullet point.
    Agreed, except that you can't call it that without being an official "HDMI Adopter" and paying royalty fees.

    -Phil
  • Ah! Ok they would just use a separate SPI or I2C connection. That makes sense.
    Thanks!

    J
Sign In or Register to comment.