Using on board LVDS LCD interface to transmit data.

Hi,

I was thinking, some embedded motherboards have an on board LVDS LCD
interface. Could I use this to transmit other data than video data? I
did a little investigation into this. Seems to me I need to write a
custom video driver, and connect the other end of the LVDS to a fpga
for which I need to write custom firmware for. The thing that worries
me is that I think that the LVDS driver keeps generatating data even
when the video memory is not changed. So the problem would be how to
synchronize the data? Am I right that I can change the datarate by
changing the vertical and horizontal frequency?
Has anyone done this before?

Greetz Dennis.

On 3 Mar 2006 02:17:51 -0800, d.kuppens@zonnet.nl wrote:

>Hi,
>
>I was thinking, some embedded motherboards have an on board LVDS LCD
>interface. Could I use this to transmit other data than video data? I
>did a little investigation into this. Seems to me I need to write a
>custom video driver, and connect the other end of the LVDS to a fpga
>for which I need to write custom firmware for. The thing that worries
>me is that I think that the LVDS driver keeps generatating data even
>when the video memory is not changed. So the problem would be how to
>synchronize the data? Am I right that I can change the datarate by
>changing the vertical and horizontal frequency?
>Has anyone done this before?
>
>Greetz Dennis.

This ought to work - fill frame buffer with data, wait for frame-sync, fill next buffer etc. 
I think most modern graphics chips have enough memory to double-buffer the data. 
Maybe you could use some 'magic colour' values as data start/end/change markers.

Mike Harrison wrote:

> This ought to work - fill frame buffer with data, wait for frame-sync, fill next buffer etc.
> I think most modern graphics chips have enough memory to double-buffer the data.
> Maybe you could use some 'magic colour' values as data start/end/change markers.

How about taking a hint from network protocols like TCP and packetizing
the data to fit in a frame, with a little header that gives the
sequence number of the first byte of data in the packet and the total
packet size.  The receiver then knows how many bytes to keep, or if the
entire packet is a repeate that should be ignored.  Since the header is
always in a fixed location at the start of the frame buffer ie,
sometime after some sync signal), you don't have to rule out any
particular data bytes as reserved.

No acknowledgement of course, but you should be able to verify that
your data got transmitted at least once just by the timing.