Beta version of GLCD library version 3

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

Thanks, it could be great.

But in any case, right now, the library is great and a fantastic work.

Well done and thanks so much!

#include <glcd.h>
#include "fonts/Arial14.h"         // proportional font
#include "fonts/SystemFont5x7.h"   // system font
#include <Wire.h> // initialize wire
#include "nunchuck_funcs.h"

int loop_cnt=0;

byte accx;

void setup()
{
  Serial.begin(19200);
  nunchuck_setpowerpins();
  nunchuck_init();
  GLCD.Init(NON_INVERTED);
  GLCD.SelectFont(System5x7);
  Serial.print("Wii nunchuck ready");
GLCD.DrawHLine(0, 32, 127); // horizontal line
}

void loop()
{
   if( loop_cnt > 100 ) { 
        loop_cnt = 0;

        nunchuck_get_data();

        accx  = nunchuck_accelx(); 

       Serial.println((byte)accx,DEC);
    
    
        GLCD.CursorTo(5,5);
        GLCD.println((byte)accx,DEC);
       
    }
    loop_cnt++;
    delay(1);
}

Ive been playing around with code for a few hours and got the nunchuck value to print from 73 to 184 or 185 the same in the serial.
At around 130 the value of accx is level.
My question is which im completely stumbled on is read a value from accx and depending on which state it is in draw a line (like a tilt plain) from level to be at 0, 32. if tilted to the right itd draw a line from 0,0 to 127,63. if tilted from left itd draw a line from 127,0 to 0,63.