GLCD library version 3 (end of life - no longer supported)

Oh i forgot to mention, gLCD diags:

Diag Loop: 1
Initializing GLCD
GLCD initialization Failed: BUSY wait Timeout (status code: 1)
--------------------------------------------------------------------
Reported Arduino Revision: 1.2
--------------------------------------------------------------------
GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
GLCD Lib build date: Mon Dec  5 01:50:07 CST 2011
GLCD Lib build number: 442
Panel Configuration:ks0108
Pin Configuration:ks0108-Arduino
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
 CSEL1:14(PIN_C0) CSEL2:15(PIN_C1)
 RES:19(PIN_C5) RW:16(PIN_C2) DI:17(PIN_C3) EN:18(PIN_C4)
 D0:8(PIN_B0) D1:9(PIN_B1) D2:10(PIN_B2) D3:11(PIN_B3)
 D4:4(PIN_D4) D5:5(PIN_D5) D6:6(PIN_D6) D7:7(PIN_D7)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(14,0x1, 15,0x0) CHIP1:(14,0x0, 15,0x1)
Data mode: 
 d0-d3:nibble mode-Non-Atomic
 d4-d7:nibble mode-Non-Atomic

So there is absolutely no CS in this particular design, so ... i dunno of GLCD can even work with it.

rainwulf,
Unfortunately, you have a ST7920 display and the glcd library does not support the st7920.
Have a look at this library which does support the st7920:
http://code.google.com/p/u8glib/

--- bill

awww crap!!
I was looking forward to using gLCD as its pretty awesome.

Thanks for your help!!

What's the problem? You can drive your ST7920-based display using u8glib, and that display needs only 2 Arduino output pins to drive it - unlike the parallel-only interface displays supported by the standard GLCD library.

Its a lot slower with the 2 pin interface, and it doesnt seem to work with my 8 bit controller.
Even u8glib shows random noise, you can JUST make out the test graphics.

I dont know what the hell is going on...
I got text mode working though, using the code from dfrobot.

The 2-pin interface is quite quick if you use the SPI pins and the SPI hardware to drive it. Unfortunately, the ST7920 it doesn't have a CS input, so it can't share the SPI pins with anything else unless you use external clock gating hardware.

dc42:
The 2-pin interface is quite quick if you use the SPI pins and the SPI hardware to drive it. Unfortunately, the ST7920 it doesn't have a CS input, so it can't share the SPI pins with anything else unless you use external clock gating hardware.

"quite quick" is relative.
While it is definitely usable,
it is not anywhere close to the speed of being able to control the pins directly.
For example, it takes 3 bytes across the SPI and 24 sclk transitions to transfer a single byte on the st7920
Even if the the AVR was pushing the SPI at 8mhz that is 3us.
(fastest sclk rate on AVR is F_CPU/2 or 8mhz on 16mhz parts. so 24clock is 3us at 8mhz)
Just for a single byte transfer.
While 3us may sound fast, when doing thousands of updates it makes a difference.

The BIG issue when using SPI on glcds, is that there is no read capability.
That puts a big constraint on things. The library either has to create a full shadow buffer
or has to live with certain limitations.
Oliver took a balanced approach in u8glib by using a partial shadow buffer that moves around
to paint the display.
It does come with some limitations in that the user code must paint the display a
particular way. It also requires re-drawing the screen L/s times to update the display
where L is the size of the LCD display memory, and s is the size of the shadow memory.
For example on a 128x64 display the paint routine code will have to be called 8 times as the shadow
buffer is 8 pixels tall. It has to be called and run to full completion for each lcd page.
During each iteration, pixels that land in the shadow buffer are updated and at the end
of the iteration, the shadow buffer is pushed to the display.

This further slows things down.

And even after dealing with that, there is still some functionality that cannot be provided
without having full read access to the display data. Things like scrolling or being able draw
on top of the existing pixels.

It is still very usable but because of these issues and limitations, it ends up being quite a bit
slower than having direct control with read access.

That said, I do agree you do pay for the additional speed and capability it in terms of pins.

I've looked at supporting the st7920 in parallel mode. (It also has a 4 bit mode)
The issue that came up immediately is that the pixels in the st7920 are not
stored in its memory the same way pixels for ks0108, sed1520, and ks0713 are stored.
The existing code in glcd is highly optimized for a different pixel mapping and can't really
be made to easily work with the st7920.

The real answer, is to have a full shadow buffer and then you get the best of all worlds.
This would allow the library to have full access to the display pixels regardless of the interface used.
Because of the local shadow buffer the pixel to glcd memory pixel mapping becomes irrelevant.
It would also allow things like rotating the geometry on the display.
Lots of code in glcd could get smaller and faster if a shadow buffer were always used.
This issue is that the AVRs used in most Arduing boards don't have enough RAM to do that.
The chipkit, Maple, DUE, and even some of the "duinos" by third parties like teensy or the "sanguino" boards
do have enough ram to have a full shadow buffer.

I've been considering a glcd v4 design that may change things up and even
potentially require a frame buffer.

I also think, oliver could easily tweak u8glib to use a full shadow buffer
which would allow it work more like glcd and would give it a speed bump as well.

But as mentioned above, it requires more ram that is available on many AVR platforms.

--- bill

bperrybap:
The real answer, is to have a full shadow buffer and then you get the best of all worlds.
This would allow the library to have full access to the display pixels regardless of the interface used.
Because of the local shadow buffer the pixel to glcd memory pixel mapping becomes irrelevant.

That's exactly what I do in my ST7920 library. Yes, it uses just over half the RAM of an Arduino Uno; but I've not yet had any other tasks that don't fit comfortably in the remaining RAM, provided that I use PROGMEM for string literals and other constant data.

dc42:

bperrybap:
The real answer, is to have a full shadow buffer and then you get the best of all worlds.
This would allow the library to have full access to the display pixels regardless of the interface used.
Because of the local shadow buffer the pixel to glcd memory pixel mapping becomes irrelevant.

That's exactly what I do in my ST7920 library. Yes, it uses just over half the RAM of an Arduino Uno; but I've not yet had any other tasks that don't fit comfortably in the remaining RAM, provided that I use PROGMEM for string literals and other constant data.

agreed. It starts to get harder when the display gets larger than 128x64.

I uploaded the "Big Nums" test sketch to my Arduino Uno connected to my KS0108-controlled LCD module. However, what should be on the left side of the display shifted to the right side, and what should be on the right side shifted to the left. Other than that, everything displays perfectly. I double checked the wiring and found no issues. Could someone please help me?

I bought the LCD from this vendor at Ebay.

http://www.ebay.com/itm/128-64-12864-128x64-Character-LCD-Module-Display-Screen-LCM-IC-KS0108B-104-/170899666269?pt=LH_DefaultDomain_0&hash=item27ca69f55d

Here's a picture of what goes on.

Thank you,
Maxwell

Max,
The library includes a diagnostic sketch and documentation to help diagnose issues like this.
Have a look at the included HTML documentation as well as the library wiki.
Here is a link to the library wiki:
http://playground.arduino.cc/Code/GLCDks0108

--- bill

Hi
I can not display the degree symbol using GLCD.print (char (value))
I can create? Using examples of the library LiquidCrystal not work.
Any idea?
Thanks and sorry for my bad English

ehuntabi,
Many hd44780 displays have a degree symbol in character position 0xdf or 223 decimal.
The glcd library uses fonts that are different from a hd44780 display.
To display a degree symbol as a character, you will need a font that contains
a degree symbol character.
I went and looked at all the fonts that are included with the library and none
of them have a degree symbol.
If you are using the System5x7 font and would like to add a degree symbol,
it is fairly easy.
You can add a degree symbol to System5x7 font table.

Here is the definition for the degree symbol:

	0x00, 0x06, 0x09, 0x09, 0x06 // degree symbol

This can be added to the table by either replacing a character that you don't want/need
or it can be added to the back end of the table.
If this is added to the backend of the font table, you also have to bump
the character count from at the top of the table from 0x60 to 0x61.
If you add to the back end of the table you will use 0x80 or 128 decimal to print the character.

Attached is a SystemFont5x7.h header file that has the degree symbol added to the back end
of the font table.

Just keep in mind that if you use a modified version of the font, that your code will
only work properly with that modified font file. So that means that if you want/need
others to able to build your code you will need to also supply them with the modified
font file.

--- bill

SystemFont5x7.h (4.96 KB)

Hello Bill
I followed your instructions and .... Already!!
Thank you very much for your time.

Hi, i am a arduino - newbie and posted a thread in the german Forum- area (with Images and Serial output): http://arduino.cc/forum/index.php/topic,160271.0.html

I´ve got a Display with 1x HD44105 and 2x HD44102 , resolution 100x32. I wired the Display to an arduino UNO in 8bit mode via KS0108 wiring. The Images in the german thread represent my Problems, the GLCDdiags works fine in Serial LOG , but on Display it is wrong.

These are my changes in "..Panel.h":

/*********************************************************/
/*  Configuration for LCD panel specific configuration   */
/*********************************************************/
#define DISPLAY_WIDTH 100
#define DISPLAY_HEIGHT 32

// panel controller chips
#define CHIP_WIDTH 50 // pixels per chip
#define CHIP_HEIGHT 32 // pixels per chip

And These in "...Device.h":

 * LCD commands -------------------------------------------------------------
 */


#define LCD_ON				0x39
#define LCD_OFF				0x38
#define LCD_SET_ADD			0x40
#define LCD_DISP_START		0x3E   // Display start page 0 -->3E
#define LCD_SET_PAGE		0xB8

In glcd_config.h i use this Option : #define GLCD_READ_CACHE - whitout this, sie Serial Log Fails !

I hope it was somewhat understandable and you can help me.

Bahnbooster,
I kind of started work on the 44102 but it was never really implemented.
It's been so long I had forgotten about it.
The 44102 is pretty close to the ks0108 but has some differences like
the addressing to set column and page is a single command vs two individual commands.
I just looked at the datasheet and the code and it will require code changes to the
device layer code.
There needs to be a proper 44102 panel file created then there will need to be changes
to the device layer code in glcd_Device.cpp
I don't have a 44102 device so I can't test the code.
If you want, I can work with you directly to see if we can get something up and going.
pm me your email address and we'll continue discussions through email.

--- bill

sure, :smiley: tell me, how to Support . GLCDdiags should be the right way to fix it. What info you Need ?

Again, the update for this requires modifying and creating header files as well as code changes.
I'll be happy to work with you to get hd44102 support added.
I don't have a hd44102 module, so I can't test any of changes I provide to you.

PM me your email address so we can continue discussions through email.

you get a PM

Hello bperrybap.
Firstly thankyou for all the support that you obviously give to forum members using these GLCD’s. If you can suggest what type of display. I have purchased from Ebay and point me to any relevant information I would be grateful. Here is the link to the item.

http://www.ebay.com.au/itm/320960643544?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649

As I am as yet not getting too much help from the Ebay seller in regard to a data sheet etc. Here is the pinout if that might help.

  1. VSS
  2. VDD
  3. VO
  4. RS
  5. R/W
  6. E
  7. DB0
  8. DB1
  9. DB2
  10. DB3
  11. DB4
  12. DB5
  13. DB6
  14. DB7
  15. PSB
  16. NC
  17. RST
  18. VOUT
  19. BLA
  20. BLK

Hoping that you might be able to help, but if not thanks for reading this anyway Pedro.

Edit - The display has a sticker with this on it 12864ZW and Googling it revealed