HDMI added to Prop2
cgracey
Posts: 14,134
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.
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.
Comments
https://github.com/mithro/tmds_encoding
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?
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
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.
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.
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...
If we can generate HDMI signalling, does it still suffer from baggage?
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.
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.
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.
So don't look to LCD LVDS for any help on HDMI.
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.
Feed it from a data pattern in RAM, or the existing P2.
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.
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?
BTW: The TFP410 can input 24 bits using only 12 pins as I recall using a DDR type thing...
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 will eventually want to use a small touch screen connected to the P2 but I have not looked into the requirements yet.
j
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.
-Phil
Thanks!
J