Right. That is an interesting subject for those that will get a similar LCD. First, i need to note that this LCD does not have a controller. It would be extremely convenient to have one, but it doesn't. That is normal though, if you consider that this is an OEM part.

So, i need to make the controller myself. And here is how this LCD works. It has 240 scan lines, and each scan line has 320 pixels (this makes the 240x320 LCD resolution). To show an image, you need first of all to break this image into horizontal scan-lines. Then, you load the first scan-line on the LCD. This is done by sending packets of 4-bits to the LCD, a total of 80 packets are needed for one complete scan line (80x4=320). When this is done, the LCD shows the first scan line. Then, the second scan line has to be sent, again in packets of 4 bits. When this is done, the LCD shows this second scan line, and so on, and so on.

Someone would now think: "Ok, when you load 240 scan lines, you stop sending data to the LCD and a static image is shown, right?". Wrong! The problem with a controller-less LCD is that when you send a new scan line, the previous scan line is lost. Actually, there is ONLY ONE scan line that is shifted from bottom to top. And in every new position, this same scan-line changes its bits according to the image. So, to have one static image on the LCD, the scan-lines must be sent non-stop. And to avoid screen flickering, this process must have a refresh rate of more than 50Hz, which means that each second, the screen must refresh itself 50 times..

I should have start from this point, but i went backwards (as usual). What i mean is, i had to theoretically calculate the frequency needed for the PIC to run, before going into programming. This cost me many hours. Anyway. Here is the problem. 50Hz refresh rate, means 50x240=12000. So the controller must send 12000 scan lines in one second. Considering also that each scan-line has 80 packets of 4 bits, this means that the controller must send in one second at least 12000x80=960000! Can a PIC do that? Let's see. I will not use a classic 20MHz PIC, instead i will use something like the 16F1937 which has 32MHz max CPU speed, which is rather fast. As we know, to complete one full instruction cycle, the PIC needs 4 clock cycles. So with 32MHz, it can run 8.000.000 instructions per second.

This number looks good, but then you must consider how many cycles must be carried out for a screen to be delivered. Suppose that the image is uploaded to a serial memory, and the only thing that the PIC needs to do is to recall this image. Here is a simple algorithm to do this:

Up to here, all 4 bits are sent to the SIPO shift register

The above algorithm will ONLY send data from external ram to the LCD. There are more instructions to load memory base positions and such, but they cause a very slight delay. Now, let's count the instructions needed: There are total 20 instructions right? Wrong again! Because there are two nested loops: The first loop contains 11 instructions and it will run 80 times (line 2 to 7), and the second contains the first loop plus 10 instructions and it will run 240 times. Doing the multiplications, you get the total number of instructions which is 386400 instructions for a full screen. Divide the maximum speed of the PIC by this number: 8000000/386400 makes approximately 20.7 Hz. So, A PIC Cannot control the LCD this efficiently. Actually, to get 50 Hz refresh rate, you need to have a PIC with 80 MHz clock, but this is not a good solution - high clock means designing problems of the PCB.

The answer is simple: Use simple TTLs to run the above process. See the following circuit (click to enlarge):

The circuit on a breadboard for test

So, let's see how the data are transferred from the PIC to the external memory, and then how they go from the memory to the LCD (which is the interesting part). The first part is simple. The PIC I/O RA0 sends the data to the memory (Serial Input pin). The clock pulses are delivered from the PIC pin RD0, through the OR gate of the 7432 chip. At this point, the other input of this OR gate is all the time LOW. So, the pulses are delivered as-is to the SCK (Serial ClocK) of the memory chip. So, the PIC is able to fully control the memory chip, although this is done in a slow speed, but this is not a problem. One full screen (top to bottom) is transferred to the memory within a second.

So far so good. Now it is time to display this saved screen. The PIC RD0 stops delivering pulses and becomes LOW. Then, the PIC output RC4 (pin 23) becomes HIGH. This is connected to one of the 2 inputs of a NAND gate. The other input is connected to the PIC pin 14, which is actually the CLKOUT (CLocK OUT) pin. This pin delivers all the time 1/4 of the PIC's oscillator. If you do the NAND truth table, you will now see that the output of this NAND gate will be the inverted pulses of the PIC's CLOCK OUTPUT pin, 100% synchronizes with the PIC instruction cycles. The internal oscillator of the PIC is 16MHz, the clock output is 16/4 = 4MHz. If i use external oscillator (which i will use a 32MHz later on), i will get pulses directly from the 32MHz, to multiply by 8 times the refresh rate.

With 16MHz internal PIC oscillator and 4MHz frequency to the LCD driving circuit, the refresh rate is 50Hz

So, as i was saying, the output of this NAND is the inverted pulses of the CLOCK OUT of the PIC. This output is driven to both inputs of another NAND gate. This acts as an inverting gate. The output of this NAND is the PIC's CLOCK OUT pulses with same phase. These pulses are then driven to the input of the OR gate. The other input (as we said before) is kept LOW, so the output of this OR is the same pulses as the PIC's CLOCK OUT, which are finally driven to the clock input of the memory chip. So, the memory chip is now using a high frequency to serially output its data.

The LCD requires 4 bits parallel data load. So, first of all, i have to convert the serial output of the memory chip into parallel data. This is done by the 74195 chip which acts as a SIPO (Serial In Parallel Out) shift register. I also have to "inform" the LCD controller, whenever a new packet of 4 bits is ready to be transmitted. This is done by a pulse on the 3^rd input of the LCD. This pulse has to be sent once every 4 bits that are transferred from the memory chip to the SIPO shift register. To achieve this, i put the 74393 binary counter. The clock input is taken form the inverted clock pulses (for synchronization reasons). The 1/4 output of this chip is then driven to the 3^rd input of the LCD.

50Hz is already very good refresh rate, but it can climb up to 400Hz with an external oscillator

Remember before, the length of the algorithm that the PIC requires to show a full screen? It was 386400 instructions. The circuit above can do it much faster. As a matter of fact, it can do it in just 240x320 clock pulses, which is 76800 pulses total. If i use the CLOCK OUT of the pic (with 16MHz internal oscillator), this means 76800 instruction cycles, which results in 4000000/76800=52Hz refresh rate, which is already very good. But if i use an external 32MHz oscillator and drive the circuit's clock directly from this oscillator, the refresh rate will rise up to 32000000/76800=416.6Hz, more than 20 times faster as the software solution with the same PIC and same oscillator.

Name   Email (shall not be published)   Website Notify me of new posts via email Write your comments below: BEFORE you post a comment:You are welcome to comment for corrections and suggestions on this page. But if you have questions please use the forum instead to post it. Thank you.