Go Down

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


Nov 24, 2010, 09:05 pm Last Edit: Nov 24, 2010, 09:08 pm by madepablo Reason: 1
Thanks PaulS,

Here is the full setup():
Code: [Select]
void setup(){
 Alarm.alarmRepeat(alarmH,alarmH,alarmS, AlarmTone);    
 GLCD.CursorToXY(40, GLCD.CenterY-3);
 GLCD.print("Arduino-based Clock");
[glow]  ClearScreen(WHITE);[/glow]


As soon as i posted it, i saw the error. the line should say:

I made a detailed review of the code for a long time without to see the problem... incredible. So thanks PaulS for your comment.
Thanks a lot!


Does anyone having the 160x128 Graphic LCD from sparkfun.com (pn: 08799), want to see it included in GLCD v3? Take the poll and let's see how many people do.




I'm looking to do a project with a Teensy 2.0 (or maybe Arduino) which will use a Graphics LCD. I'm not very experienced in this field, so I would like to use a graphs LCD that already has a library written for it. I wanted to buy a 128x64 LCD, but all of them are small, being about 2.5" in length.

Is there anything bigger? I found the Sparkfun one, but it's in different dimensions. I just want a bigger dot size, or possibly a bigger LCD, even color, so long as there is a Teensy or Arduino library for it.

Thanks!  :D


Hi All,
I posted a topic here:

..and was asked to move it to this thread  :)

As far as I've been led to believe this is an AVRDude issue, the explanation of which seems to make sense so far. I also understand there is a way of turning off the AVRDude 'smart' upload to get round this problem but can't seem to track down any info on this. Since encountering this problem ( took me 2 days and lots of hair pulling to pin it down..!  :'( ), I've simply altered my bitmaps and everything works fine.

As an aside, great though the GLCD library is, I found the lack of a 'switch' to divert the graphics routines to a frame buffer seriously limiting for my purposes. If I had a request for a follow up version, I would ask the writers of the library to tweak the code to allow this optional facility. In the meantime, I'm writing some graphics routines for my project that will allow me to display a variety of analogue style gauges for sensor input display. This necessitates use of a frame buffer in SRAM coupled with a slightly modified GLCD DrawBitmap routine to dump this to the display. This allows the graphics to be easily updated as there are no screen erase issues to contend with and makes for smooth animation and also allows the use of a background bitmap that can be pulled from PROGMEM and placed in the frame buffer to be animated over. So far, I've written basic plot, line ( modified GLCD routine ) and circle routines for drawing onto the frame buffer.  Ideally I would like to convert/use all the GLCD routines and add generic bit block transfer/scrolling routines. Doing the graphics this way is much faster and cleaner, especially if you've got lots of stuff going on. The limiting factor in terms of fps will be the transfer of the frame buffer to the GLCD. With a basic screen fill/erase cycle using the line routine, I appear to be able to get at least 30fps but at this speed you are starting to seriously hit the ability of the display to actually paint the pixels fast enough on the screen without leading to fading effects. Actually, this fading effect could be put to good use, with the right timing, in theory it would be possible to produce ( albeit limited ) 'greyscale' images... ;)


Nov 30, 2010, 09:11 pm Last Edit: Nov 30, 2010, 09:28 pm by bperrybap Reason: 1

On the bitmap/avrdude issue.

It may actually be an interaction between avrdude and the Arduino bootloader code. Its been a while since I looked at either but I do remember that the Arduino bootloader chose to ignore certain commands and I seem to recall it ignored one of the chip erase commands. The bootloader tended to work even though it ignored the erase command as it erased each page as it was written rather than erase the entire chip, but if avrdude never comes back and writes the pages of 0xff, then things will not work properly.
For code this is probably not ever going to be an issue as the "garbage" pages left behind will not have any code that would be executed.
But for data, it could cause real problems.

I'll have to take a peek at the avrdude code and the Arduino Bootloader to see if this is what is happening.
If it is, it is really an error in the Arduino Bootloader as the bootloader is the one that said it erased something when it didn't.

------ With respect to the Frame buffer.

Michael and I have discussed using a frame buffer several times.
It has its pluses and minuses; mostly pluses, but it does require a significant amount of very precious memory and cannot be used on the smaller AVR chips.
It's also quite a big change to the code to really do it correctly
because the current code "knows" how expensive data accesses are
and so it trades quite a bit complexity and code size to avoid
as many lcd data accesses as possible. The code, primarily the text
rendering code could be simplified quite a bit if it had direct access
to the frame buffer.

I experimented with a write-through cache frame buffer.
A write through cache on top of the existing code isn't
as effective as a  code re-write to use a dedicated frame buffer but
it is very easy to do and was only about5- 6 lines of code changes to the current library.
This was mainly intended to support displays that are write-only
using something like a SPI interface.
It actually worked quite a bit better than I thought it would.
The write-through cache mode doubled the through put of the
FPS demo sketch.
(A re-write for frame buffer would be significantly faster)

There are some quick an dirty ways to add in frame buffer support.
What I did with my experimental frame buffer code was to
hook the frame buffer into the ReadData()/WriteData() routines.
That way,  no upper level code has to be re-written and there were only 5 new lines of code.
In my case, reads, never went to the real hardware but were returned
from the frame buffer and writes went to both the real hardware and the frame buffer.

Depending on your situation, you might be able to use this same method
or something similar.
For example, rather than having to re-write any code, you could:
- Rename the existing ReadData()/WritData() routines to say glcdReadData()/glcdWriteData().
- create new ReadData()/WriteData() that use a frame buffer.
- add a glcdBufferFlush() routine that flushes the frame buffer
whenever you want/need to by calling the new glcdWriteData() routine
(which is really the old/original WriteData()) to dump the frame buffer to the physical display.

While not as efficient as it could be, it would be very minimal code changes and all the existing functions would continue to work.
You would just have to make sure to call the glcdBufferFlush() routine whenever you wanted to update the physical display.

--- bill


Hi Bill,
Yes, that's exactly the sort of thing I was looking to do, modify the ReadData() and WriteData() routines in glcd_Device to work from a frame buffer. For flushing (modified DrawBitmap):

Code: [Select]
void glcd::glcdFlushFB(Image_t *FrameBuffer)

uint8_t width, height;
uint8_t i, j;

 width = *FrameBuffer++;
 height = *FrameBuffer++;

 for(j = 0; j < height / 8; j++) {
    glcd_Device::GotoXY(0, (j*8) );
      for(i = 0; i < width; i++) {
            uint8_t displayData = *FrameBuffer++;

Having a buffer does use up 1KB of SRAM ( for 128x64 LCD's ), so yes, not practical for smaller AVR's. An option to invoke use of a buffer,  say in a call to GLCD::Init passing a pointer to the start of a frame buffer would have been very handy for those that have the memory to spare, allowing the opportunity to use traditional animation techniques...!   ;)


I am just getting into arduinos. I bought a kit with a glcd after I read it was well supported and saw the demo running on it (on youtube)

I want to thank the people behind this library, from what i read so far it seems to be well documented so a complete newbie (like me) can get into it.

Main thing I am missing for the projects I have in mind is touch screen. Plenty to be found on ebay, but I don't think they are supported (yet).


Hi there guys,

thanks for the hard work, excellent job!

i just tested the library on a 128x64 glcd and works perfect, i have an arduino MEGA 2560  (not 1280)  , arduino 0021, and win 7 64 bits.

now i am testing all the features you made for this library

the pdf and html guide are perfect, a few tips i can give:

- compatiblity with MEGA 2560 ( i know is just modify some lines in include files, but it would be great if not)

im really new in arduino world (about 2 weeks),  i was wondering, i have a tft color 320x240 glcd, but i cant find any library to control it with my arduino MEGA 2560, it is posible with this library ?  

another thing, it would be great to add this library a touchscreen call function, almost all new 128x64 glcd come with touchscreen.

thanks for all!!


Jan 10, 2011, 12:37 pm Last Edit: Jan 11, 2011, 11:08 am by dakudiv Reason: 1
I have just started using arduino's.
I wanted to compile this library for Atmega32.
I am using Usbasp to program my board.

board.txt configuration




I have changed ks0108.h to include atmega32 definitions.

#if defined(__AVR_ATmega32__)
#include "ks0108_Mega.h"

But on compiling following errors come :


D:\cvavr\arduino-0021\arduino-0021\hardware\arduino\cores\arduino\WInterrupts.c: In function 'attachInterrupt':
D:\cvavr\arduino-0021\arduino-0021\hardware\arduino\cores\arduino\WInterrupts.c:90: error: 'EICRA' undeclared (first use in this function)
D:\cvavr\arduino-0021\arduino-0021\hardware\arduino\cores\arduino\WInterrupts.c:90: error: (Each undeclared identifier is reported only once
D:\cvavr\arduino-0021\arduino-0021\hardware\arduino\cores\arduino\WInterrupts.c:90: error: for each function it appears in.)
D:\cvavr\arduino-0021\arduino-0021\hardware\arduino\cores\arduino\WInterrupts.c:91: error: 'EIMSK' undeclared (first use in this function)
D:\cvavr\arduino-0021\arduino-0021\hardware\arduino\cores\arduino\WInterrupts.c: In function 'detachInterrupt':
D:\cvavr\arduino-0021\arduino-0021\hardware\arduino\cores\arduino\WInterrupts.c:135: error: 'EIMSK' undeclared (first use in this function)

Is there a need of any modifications in the library to compile it with mega32 ?


(i am using sketch from ks0108 library)

Go Up