Parallel 128x64 LCD converted to use SPI

Archive
1

I had a parallel ks0108 that I wanted to use and SPI seemed to have the fastest refresh rate. The draw time is 400ms if every byte has to update but the average rate is less than 300ms down to 150ms. I use a double buffer to check if a byte needs updated and it can skip over what doesn’t change.

It uses a couple shift registers with their latch tied to the SPI SS pin. I shave off some more time by also tying the SPI SS to the Glcd clock/enable. The shift registers take about 50ns to latch so I use a few invert buffers to delay the Glcd clock by about 500ns. There are shift register bits left over for backlight control.

First I made a schematic to map out what needs done:
[url]http://dl.dropbox.com/u/3647376/blogfiles/GLCDSPI_sch.png[/url]

Then I did a breadboard test:
[url]http://dl.dropbox.com/u/3647376/blogfiles/GLCDSPI_BB1.JPG[/url]
[url]http://dl.dropbox.com/u/3647376/blogfiles/GLCDSPI_BB2.JPG[/url]

and this is everything plugged together:
[url]http://dl.dropbox.com/u/3647376/blogfiles/GLCDSPI1.JPG[/url]
[url]http://dl.dropbox.com/u/3647376/blogfiles/GLCDSPI2.JPG[/url]

2

Very nice work but this will be lost if you do not add the project to the wiki. Plus you will receive experience points if you add it :slight_smile:

3

I’ll put it on the wiki when I finish in a few days. The speed was still too slow because it had to flip the SS pin every 2 bytes. I decided to try an auto latch method and it immediately doubled the speed then some software adjustments made it 5x faster. Now it’s able to stream a massive buffer to parallel without stopping. The only thing left to do is switch the 2 slow 4017 counters with a single faster 4516 hex counter and I may be able to push the SPI clock higher.

[url]- YouTube

4

Very cool i have a few of this type of displays laying around. Will have to keep up with this.

5

Using hardware to help the software, this is very smart thinking. Most developers are too lazy to make any hardware work.

6

[quote] Most developers are too lazy to make any hardware work.
[/quote]

I resemble that remark!

7 
Most developers are too lazy to make any hardware work.

I’ll take that as a compliment, lazy is a quality for developers :smiley:

8

Yeah. I am one of those lazy developers :d

9

Now that I had the hardware sorted I optimized the drivers and it can draw the screen in 15ms. I created a BMP loader that can load standard 1bit files and convert to optimized buffer objects. They load in 10ms which can stream directly to the screen in real time at 15fps minimum so only a single 1k load buffer is needed.

[url]DSCN0613 - YouTube

I should have the last missing piece next week and finally be able to finish.

10

Holy crap nice work.

11

WOW, this is worth 800 points if you details how you did that in a wiki page. Love it :slight_smile:

12

That would make a great shield. I would buy one.

-Eric

13

@ OP how did you “debug” it, how did you findout you needed the invert buffers ? Did you use a logic analyzer ?

14

What an excellent post. A lot of people use parallel LCD’s

I use a T6963C 240x64 quite a lot I can see the benefits of a shield.

I’m going to draw one up and have a few made. I might put several headers on for different screens… KS and Toshiba…

I’ll keep you posted. I’ll even put your name on it.

Cheers Ian

15

The invert buffers were added based on the timing shown on the datasheets. The LCD clock and shift register latch at about the same speed but the display needs the clock held around 450ns.The 4 buffers add about 500ns for the display while the registers are already loading the next cycle because the data can stay latched while loading.

I know the current design is bottlenecked with the 4017 counters because based on the datasheet they can barely handle 2mhz at 5V. The slight voltage drop when usb powered makes it even more unstable. Replacing those with a single 4516 will be much more stable and possibly let me push the SPI clock to 4mhz. It’s technically not what the 4516 is really used for but it counts to 16 and that’s all I need.

16

@ IanR It never crossed my mind about having multiple headers on a single shield. Since the control register pins are all assigned in software, it can easily control multiple display configs. The invert buffer even has a few extra available to add a flipped clock output or extra delay if needed.

17

post the eagle files too Ian, others can make some too - it seems a cool thing for these class of LCDs

18

If you need more speed why don’t we put an MCP23s17 spi - 16 i/o converter on it.
That will run up to 10 mHz, as for inversion of pins, its done in software.

The MCP23s17 has more overhead though you might not want to complicate things.

@ Brett…I don’t use eagle, but the gerber files are all the same. Yes I wil post them

Cheers Ian

19

I think the port expander would come out about even because of the extra instruction bits needed but it’s definitely worth testing. The advantage of an external counter is that it can clock the display without sending the extra instructions through the port expander. It basically cuts the amount of data that needs transfered per frame in half so even a slower clock speed can end up being faster.

The SPI speed probably can’t help much more even if it is faster because it can refresh now in 15ms at 2MHz and 4MHz only drops to 10ms. The last few speed improvements have come down to software adjustments at this point.

I know once I get it on the wiki somebody else will find plenty of ways to optimize the code and should get it to a 7ms refresh even at the 4MHz speed. There are some functions I haven’t even touched beyond just getting them to work. The last few bits are being finished now so I can finally start putting everything up.

20

My panda should be here very soon so I’ll crack on with the layout…

Can anyone update me as to the panda pins versus the arduino problem (if indeed there is a problem, I believe the arduino shields work ok! )

I can simulate the SPI -> screen interface on my software ( Protues )…

Cheers Ian