How to properly connect LCD 128x64 via SPI?

[prasimix]

I'd like to share here some experience working with 186x64 graphic LCD while work in multiple-SPI device environment. I bought a 128x64 LCD on eBay. Manufacturer is unknown and it could be like Raystar Optronic RG12864, DFrobot or any other with the same dimension (93x70mm) and controller device (ST7920). It looks like this:



Documentation is minimal and it says that you can be connected using parallel or serial bus. Pinouts is usually as follows:



Using serial has an obvious advantage since it does not require so many lines while access speed is still very good. I tested it first without invoking any other SPI devices on the same bus, and that works fine as it's presented here.
So far so good. The problem appears when multiple devices starts to be addressed (ADC, DAC...) after LCD was "initialized" (actively used to display any content). For example this is an screenshot when LCD is addressed alone.



... and below you can see what is happened when some other SPI devices are accessed after LCD:



First I  thought that something is wrong with used u8glib library. I tested it with some other but the result was the same. While accessing another SPI device unwanted content starts to appear. After all I come to conclusion that the way how such LCD has to be connected is not really in line with SPI "standard". What I found until now as proper way to made serial connection is:

SCLK --> E (Pin 6)
MOSI --> RW (Pin 5)
CS --> RS (Pin 4)

E stands for enable and you will presume that CS has to be connected there but that is not a case. It seems that when you trying to send something to other SPI device and what include SCLK activity make LCD also active with unwanted result. To fix this problem I decide to use "brute force" by using an 125 gate controlled by CS signal as shown below.



I'm wondering if someone else have similar problem and if there is a better way to resolve it. Thanks.

[amyk]

Put a scope on the signals and see if it's not deselecting the LCD as it should, or if there are any glitches that could be interpreted by the controller as stray commands.

[prasimix]

If LCD is accessed directly I can see this (CS is active high):



When I accessing another SPI device the same lines looks like this (zoomed in):



As you can see there is no activity on "CS" line. But on the E pin SCLK is indeed active.

[Kalvin]

From the data sheet http://www.dfrobot.com/image/data/FIT0021/ST7920.pdf, page 7:

"When chip is disabled, SID and SCLK should be set as "H" or "L". Trancient of SID or SCLK is not allowed."

Propably gating the SCLK when the CS is "0" is sufficient, like you have already done.

If the SCLK is relative slow, you might use a simple mickey mouse diode logic AND-gate to clamp the SCLK to "0":
http://hyperphysics.phy-astr.gsu.edu/hbase/electronic/diodgate.html

The best solution it to use a proper logic gate. Single logic gates are available in SC-70 or SOT-23 etc. small packages from multiple manufacturers.

[prasimix]

Argh, RTFM! I got that document long time ago and forgot to check it there is some valuable info. Thanks Kalvin. Yes, it seems that in one or other way some additional logic is required for such kind of device. Hopefully this now obvious fact will helps other people to not spend time trying to understand why it alone does not want to work properly when more SPI devices are present. I'm posting another circuit that is more "by the book" where both SCLK and MOSI are controlled by CS signal.

[zapta]

If you gate the clock and data signals, do you still need the select signal to the display? 

If not, you can use a dual multiplexer such as SN74HC253 to control up to 4 slaves.

[amyk]

Your CS line is quite a bit noisier than I'd like...

Someone else has encountered the same problem before:

http://forum.arduino.cc/index.php?topic=181039.0

However, the phrase "When the st7920 interfaces with several chips, chip select pin (CS) must be used." turns up in a lot of datasheets so I'd hesitate to say that its CS is broken completely without trying to manually enter commands while it's deselected; perhaps it is rather more sensitive to noise than usual.

[void_error]

I usually go for the parallel interface or if I want to use the serial one I slap on an I/O expander and use SPI/I2C for that. The datasheets for these displays are sometimes ambiguous.

[prasimix]

Instead of Q2, R3 and R4 I'll probably use single inverter '1G04 (for smaller part count and better timing).

[IanJ]

When you scope SCLK is the artefacts any worse or better?......i.e. the probe capacitance. Try a 33pF cap on SCLK to gnd.
I have a project on my workbench right now that doesn't work cleanly without the cap.

Ian.

[prasimix]

Thanks Ian for reply. So far I'm happy even with initial solution where mosfet is used for inverting LCD_SELECT. The latest post is added just because I found recently that one gate logic family that also include inverter.

[prasimix]

Another info that someone could find helpful. It seems that there is different LCD displays available on the market with the same pinout and different target usage. I bought two variants on the eBay where you can find it for so attractive price that it is worth trying . They look almost the same, the pinout is the same. My intention is to use it with SPI as described in initial post and one of them works immediately but the other wants to shut down supply every time I switch power on. I spent some time to finally realized that the second one have pin 15 (PSB) that define communication type (parallel or serial) "hardwired" to +Vcc. Fortunately it is done with zero-ohm resistor (position R9) that you can simply remove if serial communication will be used. Here is the picture ...



So, my suggestion is that before power is apply to test if pin15 is connected to +Vcc (or maybe in some variant to the ground).

[macboy]

From your scope shots, you are very clearly transitioning the MOSI data line at the same time as the rising edge of the SCLK. This is a problem, since the clock is a rising-edge clock (data is sampled at the moment of the rising edge). According to the data sheet the data should be stable on the serial input for 40 ns or more before the rising edge, and should remain for 40 ns or more after the rising edge. Ideally, you would change the data around the same time as the falling edge of the clock. If you are using a hardware SPI, then you probably have the clock phase set up wrong; the fix would be as simple as flipping a bit in a config register somewhere. If you are bit-banging it, then you need to revisit your code.

[Polle0]

Hola amigos, yo pude solucionarlo como describi en el siguiente link...

https://github.com/olikraus/u8g2/issues/367#event-1272813635

Saludos.

[tooki]

Hola amigos, yo pude solucionarlo como describi en el siguiente link...

https://github.com/olikraus/u8g2/issues/367#event-1272813635

Saludos.

Posts on EEVBlog must be in English, thanks!