KS0108 128×64 Graphic LCD

All,

Spent a couple of hours trying to get one of these to work with Maple Mini clone yesterday evening without success. The display is similar to http://www.adafruit.com/products/253. The data sheet does state a min supply voltage of 4.75V, so I knew I would be pushing my luck.

The device does not seem to be 3.3V compatible. It has a negative voltage generator on board to allow the contrast to be adjusted, but this just does not seem to be able to generate enough negative voltage if you provide it with only 3.3V supply. I could not tell if the display was operating or not without being able to adjust the contrast properly.

Next I switched to powering it from the 5V USB power. I was then able to adjust the contrast, so that for example at one extreme of the contrast adjustment, all pixels went slightly dark. But the display remained blank. Checking the data sheet, I don’t think its logic inputs will recognise the 3.3V logic from the Maple when it is operating at 5V supply. The data sheets state that a HIGH must be above 0.7 of the supply voltage, i.e. over 3.5V.

So my conclusion is that I would need level converters to run the display. However, its possible that I made some other error in my code and that was why the display remained blank. I tested the display with an atmega328 running at 5V with no problems.

Has anyone else had any success with this type of display? If so, how did you achieve it?

Thanks,

Paul

All I can say is, that I ported the 128×64 display with a ST7920 chipset. The board is quiet similar to the KS0108, so I have no voltage problems (for sure: VCC must be 5V). Do you own a logic analyzer? So you can compare the output from the uno-library with the stm32-library.

Thanks for the reply madias. Your ST7920 based display does seem to have similar characteristics to the ks0108. HIGH must be 0.7 of Vdd according to both data sheets.

I don’t have a logic analyser. I am not using a library, just digitalWrite().

Please post your code, so I can have a look on it! (at the earliest on Monday)

Edit: As I can remember, some AVR code I used, was too fast on ARM for the ST7920 chipset. So maybe you can test your code with some minor delays after each display commands?

Matthias

I found the AVR was also too fast for the KS0108, so I already added delays to my code when it was running on the AVR. I hoped, given that these delays were made using delayMicroseconds(), that the extra speed of the ARM would not matter. I will try longer delays, thanks for the suggestion.

Guys,

I know you will probably guess at the amount of delay your need, but bear in mind… from what I’ve read on the old Maple forum, the delay functions are not particularly accurate. They don’t use systick, they are just loops with nops in them.

So delay will be partially dependent on anything that will interfere with the main time line, i.e heavy use of ISR’s will lengthen the time given my delay() etc

I usually try an utilize a Nano or Pro Mini to test displays when I get something strange from China… the AVR code selections are particularly vast. Then, over to the ARM once I know for certain the display will perform! Just my anal character, I suspect

Ray

Hi all,

I managed to get one of these ks0108 displays working on a maple mini clone using openGLCD. At first the compiler complained about the definition of analog pins (A0 through A5), so I simply changed the pin assignments in ‘ /config/ks0108/PinConfig_ks0108-CoreCode.h ‘ to something like this:

/* Data pin definitions
*/
#define glcdPinData0 11
#define glcdPinData1 10
#define glcdPinData2 9
#define glcdPinData3 8
#define glcdPinData4 7
#define glcdPinData5 6
#define glcdPinData6 5
#define glcdPinData7 4

/* Arduino pins used for Control
* default assignment uses the first five analog pins
*/

#define glcdPinCSEL1 14
#define glcdPinCSEL2 12

#if NBR_CHIP_SELECT_PINS > 2
#define glcdPinCSEL3 3 // third chip select if needed
#endif

#if NBR_CHIP_SELECT_PINS > 3
#define glcdPinCSEL4 2 // fourth chip select if needed
#endif

#define glcdPinRW 28
#define glcdPinDI 29
#define glcdPinEN 30
// Reset - uncomment the next line if glcd module reset is connected to an Arduino pin
//#define glcdPinRES A5 // optional s/w Reset control

//#define glcdPinBL XX // optional backlight control pin controls BL circuit

#endif //GLCD_PIN_CONFIG_H


Strange its running slow, it should be almost as fast as a Teensy and a lot faster than AVR

But at least its now working

I don’t know the openGLCD library either not the KS0108, but I guess, if it’s SPI driven, the SPI divider should be changed somewhere in the code. If it’s only “software SPI” or 8-bit parallel then I guess there must be some special code and perhaps for the teensy there is a low-level pin manipulating code and the STM32 is using the generic “digitalWrite”?
…but even with 8-bit “digitalWrite” the STM32 should be faster than the KS display can handle.

It uses an 8-bit parallel.
Have not had much time to look over the specific libraries for teensy and the generic one, but even in the nano I got to 15 fps using the ‘graphictest’ sketch. On the maple it showed 3-4 fps.

8 bit parallel was already discussed, for instance here.