This is an old revision of the document!
Published 18 Aug 2022
Ks0073 Driver Library
I have a pile of display panels from Siemens optiPoint 500 series phones, that I wish to use in Arduino projects. These are 2 line by 24 character LCD status displays, controlled by Samsung KS0073 - a Hitachi HD44780 compatible LCD controller/driver chip that includes an SPI style serial interface.
I looked for an Arduino library that would talk to this chip-set, but failed to find one.
I based my library module for this on a standard Arduino library for the Hitachi HD44780 chip, LiquidCrystal.cpp. The programs included here are HelloWorld.ino, LiquidCrystal_ks0073.cpp and LiquidCrystal_ks0073.h.
The command set is compatible with the Hitachi HD44780 with extensions.
The controller is mounted on a PCB joined to the LCD glass via a PCB flex cable, and the LCD module has a 10 pin, 1mm pitch, PCB flex cable to connect to a suitable socket. The displays are a two lines of twentyfour, 5 by 8 pixel, characters.
The great advantage of these serial SPI LCD modules is the simplicity of the Arduino interface. There are four signal lines SID (data to the display), SOD (responses from the display), SCLK (clock), and CS (select). Plus power (+5V) and ground (the module should also work from a 3.3V supply).
The controller chip is capable of parallel and serial interfacing, but on this module it is hardwired for serial connection. It uses its own variation of a SPI protocol where data and commands are prefixed by a control byte that specifies what the following bytes are going to be - ie read or write data, or a command.
All data is sent least significant bit (LSB) first, on the rising edge of SCLK. The control byte consists of 5 successive “1”s followed by command/data register select (RS) and read/write (R/W) bits. So typically you assert CS and send a control byte indicating a command follows, then if there is data to be sent, send a control byte followed by a stream of data bytes terminated by releasing SS. Both commands and data are split into two nibbles and a prefix of four “0”s is added to each - so there will never be a command or data byte starting with four “1”s. ie to send 0x1F, you send 0x00 0x01 0x00 0x0F.
I used a minimum of 2uS for the clock cycle for SCLK and, as I was not checking the ready status of the chip, a delay of about 40uS between sending bytes to give sufficient time for the chip's internal processing.
There is a separate power line, VCI, to supply the voltage converter that sets the LCD contrast voltage, around 1.3V was typical.
The data pins can be any available Arduino pins.
As mentioned earlier the library is based on a standard Arduino HD44780 LCD library. Most hardware commands, including programmable characters, seem to be compatible with the HD44780, but I would need to do a lot of experimentation to find any extended commands.
The functions implemented are:
The functions appear to be the same as for the HD44780 but have not been extensively tested for compatibility. There didn't seem to be any need for 4/8 bit interface selection. It is conceivable that the display controller chip might support 4/8 bit modes, but no account of this possibility is included in this driver. So initialisation is simplified.
When writing data to be displayed on the LCD screen it would be more efficient to assert SS, send a positioning command and then a stream of bytes, and de-assert SS when complete. But this driver has a, print.h library compatible, single-character output routine, 'write', which is used to output one character at a time, each preceded by a display-on command.
The original firmware sent an extra code, 0xf8, during startup. On an HD44780 chip this would just be a cursor positioning command (to set data cursor to location 0x78), but this would not be a displayable location, and no data is sent to be displayed. It appears that this may be a reset or other initialisation command.
I finally realised why I sometimes had trouble setting the programmable characters (only 4 available on these chips) - after setting a programmable character future writes also go to the programmable character CGRAM (corrupting it) until you deliberately switch back to the display ram. This is a problem from the original LiquidCrystal.h library - the solution here is that I just reset the cursor to the home location after programming characters.
The programs (v1.00):
If any referenced page no longer exists, try looking for its URL on http://archive.org.