KS0108 128×64 Graphic LCD

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.