Beta version of GLCD library version 3

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
 CSEL1:2(PIN_D2) CSEL2:3(PIN_D3)
 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
Tests PASSED
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...

:slight_smile:

@ 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.

@cr0sh
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.

// 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++) 
      GLCD.WriteData(*frame++);
  }

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!

Guys,

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!

Mario

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)
NJU6450A
SPLC501C
ST7920
NT7532
SED133X
ST7565R
(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.

Mario

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

Too bad the T6963C isn't one of them...

As I was trying to say in an earlier post, it's difficult to add and support LCD panels we don't have on hand in our labs.

Thanks for your work! I've just ordered one GLCD 128*64. Waiting right now. Hope to get it to work since it's KS0108 compatible. Is there any way to reduce the data line to 4 bits so I can still sense a few buttons and digital I/O? The GLCD will take 13 pins out of 18 pins (I need to keep serial). There's only 5 pins left. I have 3 buttons and 2 inputs and that leaves no room to expand. Is there any way to sacrifice speed and support shift register for the data bits? Thanks.

The ks0108 does not have a four bit mode so all eight data lines are required. The data is bidirectional (bot read and write). Bidirectional shift register solutions are complicated and it may be easier using a low cost bare bones instead to drive the GLCD that talks to Arduino through somthing like I2C.

Another solution is to use an Arduino compatible board with more pins. The Mega has 54 pins, and thats overkill there are boards with a smaller price and form factor - have a look the Sanguino (32 pins), Teensy (25 IO pins) and the Teensy++ (46 IO pins).

Sanguino: http://sanguino.cc/
Teensy: Teensyduino - Add-on for Arduino IDE to use Teensy USB development board

All those boards work well with the GLCD library

Thanks mem. It seems atmega644pa with sanguino bootloader will give me a beefed up version of atmega328. I'll fiddle with this idea once I get a sanguino kit.

Just my 2 cents, but at this point in time, I don't see the value of the Sanguino now that the Teensy++ is available and PJRC has a teensy plugin for the arduino IDE.

Teensyduino s/w includes re-written digital i/o routines
(digitalWrite(), PinMode(), etc...) that are MUCH
faster than the standard libraries provided by Arduino.

Teensy++ board hardware has
Double the flash, Double the RAM, double the EEPROM, same analog inputs, more PWM pins, Hardware USB support builtin so you can emulate lots of USB devices with simple s/w (PJRC provides lots of sample code), does not need a USB to serial cable (like an FTDI cable) as USB support is built into the AT90USB1286.

It is also quite a bit cheaper than a Sanguino and comes fully assembled and tested.

The Sanguino is usually a kit which can be a plus for some people as it is kind of fun to solder up a board and you can also replace the processor as they are through hole vs SMT.

I really like the hardware USB support especially for virtual serial communication as not only can the virtual serial interface run much faster but also has built in flow control management because it sits on top of USB.

Just my crazy views & opinions....

--- bill

don't see the value of the Sanguino?

Actually, the Sanguino kit is the same price as the Teensy++ and would be a better choice for applications that need two hardware TTL serial ports (without USB). It's a particularly good choice for hardware hackers - I have a project using the Sanguino circuit (an ATmega644P and a crystal) that was put together for $10 in parts.

That said, the Teensy++ is a good choice for the typical Arduino usage that uses USB connection to a computer.

FYI, it is working perfect into my system:

Arduino Duemilanove
Arduino IDE 17
Windows XP

GLCD model: AGM1264B

Thanks for this new library with a lot of tools... it promises a lot of fun!

Just only one question, is there a way to use shift registers (eg., 74HC595) with GLCD in order to reduce the number of pins used? Thanks!

Cheers,

The library needs to both write and read to the LCD and implementing a read/write shift register a little tricky. For a similar component cost you could probably use a second ATmega168 to run the library code that communicates with a master Arduino via something like I2C. Someone else asked about that capability and if it's a popular request then we can put I2C on the wish list for a future release.