[J-core] HDMI

D. Jeff Dionne Jeff at SE-Instruments.com
Wed Oct 19 07:22:58 EDT 2016


On Oct 19, 2016, at 19:51, txt.file <txt.file at txtfile.eu> wrote:

> Why did you chose HDMI and not DisplayPort?

Because Turtle is physically and electrically compatible with Raspberry Pi 2/3, which specifies a (physical) HDMI port.

> DisplayPort is an open standard created by VESA. It is even able to
> transport HDMI signals if you really need HDMI. With HDMI I have to use
> a proprietary format on an otherwise fully open specification processor.

No, just use it as connector carrying DVI-D.  It's just TMDS encoded clock and pixel data with embedded sync.

Don't bother with any of the added stuff.

J.
> 
> kind regards
> txt.file
> --
> This email is digitally signed.
> 
>> On 19/10/16 08:15, Rob Landley wrote:
>>> On 10/18/2016 06:57 PM, Rich Felker wrote:
>>> On Tue, Oct 18, 2016 at 05:59:04PM -0500, BGB wrote:
>>>>>> my thought here is that the 250MHz needed to pull off HDMI output may be out
>>>>>> of reach for lower end FPGA's, but I am not sure.
>>>>> Why do you think we need 250Mhz ? For the lower pixels format, aka
>>>>> 640*480 @60Hz, we only seems to need 25Mhz. Is there something I
>>>>> missed ? Also the turtle will only come with an HDMI output, like the
>>>>> RPi do.
>>>> 
>>>> 25MHz is the pixel-rate, but the pixels need to be sent as a serial
>>>> stream of bits; this pushes the required bitrate up *considerably*,
>>>> and you would end up needing to drive 250MHz on the output pins (and
>>>> for serial parts of the interface).
>>>> 
>>>> contrast with the analog interfaces, one doesn't need to send nearly
>>>> as many bits, and the bits don't need to get through reliably; it is
>>>> more just the faster the DPWM is, the higher the output image
>>>> quality can be (one might only need a few bits per pixel to get
>>>> "acceptable" output).
>>> 
>>> I don't think there's any need for concern here. My understanding is
>>> that Jeff has already tested HDMI output via a simple pattern
>>> generator bitstream and it works fine. Scanning out a framebuffer
>>> should not be any harder to meet timing for; AFAIK the plan is to have
>>> a small local buffer that fills via DMA, and output bits from this
>>> buffer at the HDMI video clock.
>> 
>> Jeff posted the example code he used, attached to this message:
>> 
>> http://lists.j-core.org/pipermail/j-core/2016-August/000341.html
>> 
>> Rob
> <0x590865E8.asc>
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core



More information about the J-core mailing list