Electronics Help with LCD required. - *more* Pics added (revived)

Before we march completely off topic, there are high speed serial ports that can handle 843kbps without a problem, i bought one when i nurfed the RS-232C ports on my mobo. However you would need to buy a highspeed UART for the other end, but it would still be a heck of a lot simpler than USB

 

Yes, the overall bits needed may be 345k, but you cant JUST send 9 bits from the PC to whatever Im using. Per pixel, I have to send 2 bytes (and wasting 7 bits). Considering I need a bit or 2 for control purposes, this brings me back to 75kBytes/screen. There are of course blanking lines per screen, and the overall time comes out to the 60Hz refresh rate for the maximum timing on the signals. So, I would need 4.5MBytes transffer in order to reach this maximum.

 

I don't see how getting to the MAXIMUM is going to do you any good. That maximum is the required rate necessary for the segment drivers... nothing else.

The problem lies within the fact that if you DID refresh that screen at 60hz (meaning changed the data going to the segment drivers at a rate of 60hz), you would see nothing but a smear. The LCD crystals can't switch between positions faster than about 20hz given the Tr/Tf rates. Regardless of how fast the segment drivers want the data.

Not to mention the fact, that if you are going to use some kind of LCD controller in front of the segment drivers (like a SED13xx or T6396) you aren't even required to send data to the controller at that rate. The output of the controller can be at a different clock multiple than the input. So, in other words, all the controller would do is refresh the segment drivers with what ever data was in the controller's frame buffer at the time. Whether you moved data into the frame buffer that fast is moot. The controller doesn't require you to do so. If you sent data at 30hz and the output required was 60hz, all the controller would do is refresh the segment drivers with the same frame buffer data twice for every change you made. That's the whole point of having the controller w/frame buffer there in the first place.

Now, given this infomation, you don't NEED to send data to the LCD at 60hz. I would say if you are *really* worried about it, just stick a PIC in there. Not only could you then do your serial to parallel conversion for you, you could also encode a packet format that would include any necessary control data you want to use, in a single 'word' of 16 bits. Why waste the 7 bits of data in the second byte???? 9bits pixel data + 4 bits Control = 13 bits out of 16.

That decreases your 4mbs down to 2mbs since rather than wasting a whole nother set of bytes on control data, you can just encode it into the 7 bits of unused pixel data you are sending to the screen.

This is still within the realm of hi-speed serial, USB 1.1, or possibly even parallel.

BTW, the 9th bit on a parallel port can be taken from one of the other specialized I/O pins that are unused (such as the PaperOut pin).

None of these issue are insurmountable at all, given a little ingenuity.

 

Not really TheAnimus. If you use something like the FTDI chip, which only requires three additional components (a couple of caps and a crystal), it's almost painless. The FTDI includes a nice driver already for you, that shows up as a serial port within windows. So you'd just develop your software like it was being used off of a serial port (or parallel port, depending on the FTDI chip you use), and you're all done.

It's just as easy as using a uART now.

Granted, prior to these integrated chips it was a *major* hassle. But hey.. that's the whole point of progress right!

 

Thanks kt3946.

 

edit: ignore

 

revived!

Hi all and anyone.

was thinking about selling some stuff on ebay, and i'm really loath to let this go.
this is a fresh call for help (or for links to people who might be able to).

if you know (or know anyone) who can help me turn this into a working LCD you'll be my saviour.

please.

thanks in advance.