Go Down

Topic: Beta version of GLCD library version 3 (Read 49164 times) previous topic - next topic


you might want to edit the playground articles then..

Wiring and Configuration:
Pin assignments are contained in the appropriate header file for the supported controller chips. There are three controller types supported in the current version:

?ks0108_arduino.h <- this is for ATmega168 and ATmega328 boards
?ks0108_mega.h <- for the Arduino Mega (ATmega1280)
?ks0108_Sanguino.h <- for Sanguino (ATmega644)

See the readme file supplied with the download for more details on configuration.

It is suggested that you wire up the panel using the default pin assignments. This diagram shows how panels should be connected using the default pin assignments in the distributed library.

Or make a note that it changed at some point in the development of the ide/library.

http://www.arduino.cc/playground/Code/GLCDks0108  ;D


Thanks for the feedback.  I think the playground article and the readme file for the previous version of the library are correct (if not completly clear) - that version, like the new one, will automatically include the correct file if you use a standard arduino board (ATmega 168 or 328), Mega or Sanguino board.

But its not made explicit that when you use the default pin assignments everything would get configured automatically for the supported boards. You only needed to edit a config file if you changed the wiring or used an unsupported board type.

The new library and documents replace the old, I trust that they are clear enough.

I will be updating that playground page with info for the new library when the beta cycle is over so new users will be directed to the new version.


Jul 18, 2010, 04:26 pm Last Edit: Jul 18, 2010, 04:28 pm by copiertalk Reason: 1
Thats  funny.

This was my fifth or 6th project. I  got this inexpensive display off of ebay as I mentioned before. I hooked it up four or five ways and read every bit of information I could find was interesting at the time. I finally sat down, went pin by pin, connection by connection, line by line from the datasheet (As I should have from the beginning).

It has been on my board for several months playing with it.

You mentioned frame buffers in a previous thread, can you elaborate on that a little more or is there some documentation on how to  take advantage of it released yet?


The GLCD library uses the memory in the LCD panel instead of a frame buffer in Arduino RAM. A frame buffer require lots of RAM which is a scarce resource on Arduino chips. Was there something you wanted to do that needs a frame buffer or were you just curious?


Code: [Select]

Serial initialized
GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
Panel Configuration:ks0108
Pin Configuration:ks0108-Arduino
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
RW:14(PIN_C0) DI:12(PIN_B4) EN:13(PIN_B5)
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:(2,0x1, 3,0x0) CHIP1:(2,0x0, 3,0x1)
Data mode:
d0-d3:nibble mode-Non-Atomic
d4-d7:nibble mode-Non-Atomic
Diag Loop: 1
Initializing GLCD
Displaying ChipSelect Screens
Walking 1s data test
Wr/Rd Chip Select Test
Testing GLCD memory pages
Horizonal Page Test Chip: 0 Pixels 0-63
Vertical Page Test Chip: 0 Pixels 0-63
Horizonal Page Test Chip: 1 Pixels 64-127
Vertical Page Test Chip: 1 Pixels 64-127
Full Module Horizontal Page Test:Pixels 0-127
Full Module Vertical Page Test:Pixels 0-127
GLCD.SetDot() speed (K ops/sec): 18.93


The GLCD library uses the memory in the LCD panel instead of a frame buffer in Arduino RAM. A frame buffer require lots of RAM which is a scarce resource on Arduino chips. Was there something you wanted to do that needs a frame buffer or were you just curious?

Personally, I would love to see a frame buffer, if it could be made optional (so that if you didn't want it or need it, no RAM would be taken up). In theory, this would allow you to do updates off-screen (erase/redraw), then just dump the entire buffer to the GLCD as fast as possible, to reduce or eliminate any flicker.

If it could be put in now while it is fairly early in the game, then if faster GLCDs become available, it would only help. Plus, with such a buffer, you could potentially do collision detection, sprite handling, and a few other things related to graphics and game development.

I understand that such an option would increase memory footprint, even in a 328 there wouldn't be much left. Perhaps, though, in such a situation the 328 could be made "standalone" as a graphics engine processor, and maybe an I2C, SPI, or bit-bang serial interface could be incorporated into the engine's core to allow other microcontrollers (another Arduino, perhaps) to control it...

I know I have pushed this idea before; I am already glad somebody has went this far with GLCDs and a library - I just think adding this kind of functionality could open up other development avenues for our favorite device...

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.


@ cr0sh,  although there are applications such as animation where a frame buffer would be more suitable, in many cases a frame buffer would not be a good solution.   Updates involving relatively few pixels would be slower with a frame buffer. But the main problem is RAM - a 64x128 panels would need 1k, a 64x192 panel 1.5k. Color panels (which will be supported in a future version) would need more RAM then an entire Mega.

That said, the architecture of the Library could accommodate a frame buffer. The drawing and text functions are in a separate layer from the code that sends pixels to the LCD panel. If someone wanted to experiment, have a look at the glcd_Device.cpp module, this could be modified to use a frame buffer instead of LCD memory. But it would be complex to implement and there are more pressing things we are looking at adding in future like:
- supporting more display controller types
- displays larger than 256 pixels
- color displays

But if someone has the desire and skills to implement a frame buffer within the architecture, please do PM me or bill.


Unfortunately, it is not early in the game as far as design and coding goes.
When designing something like this, in order to get fast efficient code, you have to go one way or the other.
There are advantages to either method. As Michael said the biggest issue with using a framebuffer architecture is that it consumes quite a bit of memory. In fact to do anything really nice you actually need multiple buffers for different "planes".
With multiple planes you can do fancy things like scroll text on top of the graphics or have different animations on different layers.
There simply is not enough RAM memory in AVR chips to support frame buffers especially for larger displays.

It really is something that can not be "optional". Well ok, it could be but
in order to really take advantage of a frame buffer architecture, it really needs to be different code for the low level and especially the text rendering code. Yes the current text code and graphic code could run on top of a frame buffer "as is" but it would not be as efficient compared to what is possible.

Currently the routines would need  a bit of a re-write to take advantage of direct access to frame memory, as currently they assume indirect page based memory access and do alot of extra things to ensure things are bundled up and packaged into lcd page bytes. This is because the LCD memory interface is SLOW compared the speed of the AVR, so it is advantageous timewise for the AVR to do a few extra instructions to ensure that the glcd write pipeline is not broken and reads are avoided as much as possible. This page logic and indirect function call overhead to access the data is simply not needed when updating a local frame buffer.

In reality, a frame buffer is not always faster. It may sound counter intuitive but in many real world situations it will be no faster and can actually be slower than what the current code is doing as the current code only updates those lcd pages that are being changed vs updating the entire display or even a region of the display.

Along with some fancy multiple graphic "planes" features,
the biggest thing that a frame buffer architecture can do is time shift when the display update gets done rather than actually improving display update performance speed.

I have a long post about this in the other ks0108 thread on page 27, 5th from the top.

Now a couple of the things we could do that would be very easy and is actually on our "to do" list is to have some sort of alternate DrawBitmap() function that takes a pointer to a RAM buffer address rather than a FLASH address. Or perhaps some kind of ram buffer dump routine
so that people could then experiment with their own frame buffer code.

Adding that kind of functionality would be quite easy.

--- bill


If someone wants to experiment with frame buffers then the following (untested) fragment added to a sketch should allow a frame in RAM to be sent it to the display.  Filling the RAM frame with pixel data in the correct format is left as an excercise to the reader.
Code: [Select]
// frame points to a RAM buffer with pixel layout same as LCD memory (8 vertical pixels on ks0108)
void writeFrame( char *frame)
 for(byte page = 0; page < GLCD.Height / 8; page++)
   GLCD.GotoXY(0, page * 8 );
   for(byte x = 0; x < GLCD.Width; x++)

As said earlier, to use the existing graphic and text functionality to fill frame buffers requires the frame buffer implimentation to go into the device layer and the code needed to keep track of x and y addresses would required a very significant amount of effort for reasons Bill gave in his post.  


Works fine for me: Win 7 (32 bit) and IDE 0017 (No idea why I haven't upgraded)

I'm in the process of cleaning up and creating a library from some GUI code I wrote (for stuff like text labels, text boxes, scroll bars etc) and most of it seems to be working fine with some minor tweaks. (Though I suppose some of it is redundant now gText exists).


Agib, good to hear its working on an ancient Arduino version  ;  )

Text support in the new version makes it easy to create text boxes and scroll regions. You may want to take a good look at the built in capabilities before you finalize your library.

Have fun!



Great work you're doing!

I just ordered my first GLCD to play with. I made sure it uses a controller currently supported by this library.
During my search for a GLCD I've seen some very nice (mostly big) GLCD's that unfortunately used "unsupported" controllers like T6963C.
Can you shed some light on which other controllers are going to be supported by the library?

Keep up the good work!



Jul 29, 2010, 01:03 pm Last Edit: Jul 29, 2010, 02:41 pm by mem Reason: 1
Can you shed some light on which other controllers are going to be supported by the library?

In addition to the KS0108 and compatibles, the SED 15220 controller is supported in the current version.

Some work has been started on a number of other LCD controller chips.

The KS-0713 is coded but we don't have a controller to test this with.

Some work has been done for the SED1330 but this is a complex beast and it may be a while before its ready.

There is a prototype of the Nokia 6610 display working with the library although the code is not ready to release (it was done primarily as an experiment to explore color support in the library).

It would be interesting to hear what displays would be most appealing. If you want to use a display that is not yet supported then please post a reply saying why you chose that display along with links to product sources.

Priority for development depends on lots factors, including the potential popularity of the display, the development effort needed to integrate, and the availability of samples to test. The latter does have significant weight and if  a couple of samples of a panel were sent to Bill and me, that will help to peak our interest (You can PM me or Bill for details)


Thanks for the reply Mem.

I think one of the most other used controllers would be the T6963C. This one is #1 on my request list for the library.
While browsing the web for GLCD suppliers the controllers listed below were mostly used.
S6B0086      (=NT7086)
(Some may be compatible, I haven't checked yet)

Perhaps of interest:
http://www.powertip.com.tw/img_src/news/Seminar.ppt (page 19)

I'm not sure what you mean with you last remark "send a couple of samples to Bill and me that will definitely peak our interest"?
Currently I'm guarding my mailbox awaiting the arrival of the postman who should deliver my first (KS0108) GLCD any day now.

For testing the T6963C controller I may be able to help. I've salvaged a 320x64 display from some old device, but I don't have the connections/specs for this display yet.
I've requested info from the vendor but they have trouble finding the datasheet for this (10 year old) module. When (and if) I get the data I need I will be able to power-up the display and do some testing.



There are a lot of part numbers that  may be compatible with the ks0108. I have tested with the ks0107 and S6B0108.  

Here is a more extensive list I have come across of parts that may be compatible:
KS0107/KS0108, HD61202/HD61203, AX6108/AX6107, PT6608/PT6607, KS0708, S6B0708, S6B0108A, S6B2108, S6B0108, SBN0064, ST7548, NT7108, RA8808, RW1065

Go Up