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

Update, NUM6 fixed the problem! Adding a 1kohm resistor seemed to fix all the problems. But I will still post a more detailed answer to the problem. Hopefully it will help others.

  1. Yes. That is what happens. Here is a video of this occurring.
  1. This is a 128x64 display
  2. The part num is GDM12864HLCM from SparkFun
  3. The library has not been altered for the Uno. However manual pins were set for the Mega as one of the ports on that controller was found to be bad.
  4. The two green wires go to a 10k potentiometer. Which is read by A5.
  5. There was nothing previously. CONNECTING THE RESET PIN TO VCC WITH A RESISTOR SOLVES THE ISSUES
  6. The number of wires attached does not effect the display performance. The test in 1) was done using the setup from 7).

--Thanks for helping me figure this out Bill!

But with respect to #1 is the diag sketch still reporting that all the tests passed on
the serial port even though the displayed turned off?


The reset line on these ks0108 glcds varies between modules.
Some modules have pullups on them, some don't.
Many seem to self reset when powered up. But some don't and require
an actual pulse on them to function properly.
Ideally, it should be driven and it should be pulsed low to ensure the glcd
is put into a consistent sane state prior to initialization.
But that takes another AVR pin.
On many glcds you can get away leaving the reset pin unconnected,
but it is best to tie it high.

On some you have to actually pulse the reset.

I wrote about the different ways of hooking up the reset line
on the ks0108 playground page. So see the playground page for more information
about how to handle the reset line and potential issues and work arounds.

My guess is that module you have is experiencing a spurious reset
while the test is running because the reset signal input is not driven high.
Many ks0108s don't enable the pixels after a reset so what you are seeing
is probably a spurious reset because the reset input to glcd is floating.
I'm guessing that the diags would report a failure when this happens and that is why
I'm curious to know if you see a reported failure on the serial port when the screen pixels turn off.

The reason the pixels turn back on with the diags is because each test iteration re-initializes the glcd
and part of the initialization (it is actually the first thing done) is to turn on the pixels.

--- bill

I hope I'm not out of place putting this here, I did already post it in the Exhibition forum but figured it's much more likely to be spotted here.

I've created an online GLCD font generator. Technically it doesn't do the whole process, you have to submit a GIF with the text in it, however it's a ~6 step process in GIMP to create such a file and I've included basic instructions. Importantly, unlike the other tools I could find like the FontCreator on the google code site, this creates fixed width fonts.

FYI a friend first getting into Arduino and using GLCD was in need of some fixed width fonts so I threw this together. There is no ads or anything on the site. http://www.microintegrate.com/?/fontgen

Very nice little tool.
I put a link to this on the glcd google project page.

I'll respond further in the exhibition thread:
http://arduino.cc/forum/index.php/topic,118349.0.html

--- bill

Hi Bill. An engineer at my work gave me this 160X160 display that I'd like to play around with at home with my AVR chips. I'd like to get your feedback on whether its worth pursuing using the glcd-v3 library on this display for basic text and graphics. i.e. "Yeah, it's easy- just create a new glcd\device, but don't worry about that single CS pin.." or "..better to roll your own here...". XD

Model: Sunlike SG160160B http://gecw.co.kr/data/sunlike/sg160160b.pdf
Controller: SED1330F series http://www.lcd-module.de/eng/pdf/zubehoer/sed1330.pdf

I'm reading up on gLCD info at the moment, but there are clues to me to indicate that the glcd-v3 lib may not work for this display. Digging in a little further after looking at the datasheets (comparing SED1520 vs SED1330F)...

  1. only 1 CS pin, where as the library suggests requiring 2 or even 3 CS pins. Not sure how this is used- perhaps memory banks? Maybe the SED1330F has enough memory so that it can reference the entire 160X160 space?
  2. Extensive graphic layers and memory descriptions on the 1330F i.e. 3 layered graphics on the SED1330F. Again, I'll be happy if I can just do basic functionality on it (initialize, clear, display text, draw some lines and such), but I'm unsure if the commands, memory, etc are compatible between the two.
  3. Inverted A0 levels between data and command. Not sure if this is "auto detected", or specified, or hard-coded in the glcd-v3 library.
  4. Different duty cycles (1/160 vs 1/16 or 1/32) [I'm unsure what this characteristic defines, or even how it relates to the library]
  5. The SED1330F pdf has 150 pages (granted, a few pages account for the TV version) where as the SED1520 only has 50 pages, suggesting the display was designed for different purposes (i.e. perhaps for involved graphics for the SED1330F vs perhaps a simplified\industrial standard\KS0108 compatibility for the SED 1520)

Again, I'd like to get your feedback on whether its worth pursuing using the glcd-v3 library on this display for basic text and graphics as I continue to read up on the specs for this display.

Thanks for your time.
Andy

Andy,
Had a quick look at the data sheet. Still looking at the graphic
memory layout but electrically it can easily be made to work with the glcd library.
The module would be strapped for 6800 mode.
This changes the /RD signal to be E
Then strap CS to ground - shouldn't need to be disabled for this application.
AO is the DI which is used by glcdDI
All the timing can be configured/adjusted in a glcd config file for the module.
Specific device initialization can be handled by a glcd device specific file.

When using glcd on a more advanced module like this you will lose out on the more advanced
capabilities, because glcd treats the module as a dumb bitmapped display. However, all the glcd
libraries api capabilities should be available.

I'll need to confirm how the memory is addressed and the graphic layout to see
if it is compatible with the library.

--- bill

Just had a closer look at the datasheet for the module.
Looks like the SEL1 and SEL2 pins are not available on the 20 pin connector.
(SEL1 being the important one)
The question is what mode is it strapped for?
Looking at the figure on page 12, it appears be set for 8080 mode.
This complicates things as currently the glcd code and macros are not set up
to allow configuring separate read & write pins.

I've been wanting to change the library to make it easier to integrate in new device support
just haven't gotten around to it.
It costs a bit of performance to do it, but it would make things much simpler particularly for
situations like this. It can be done with the existing methodology it just requires a high level of
understanding of the existing code to coexist with the other devices.

If you don't care about supporting the other display types it wouldn't be that difficult modify the glcd_Device.cpp
code to support the module.
I believe that it would be much simpler to do that vs rolling your own.

Also, before you step out too far, you may want to talk to Oliver and see if his u8glib library could be wiggled
into supporting this module: Google Code Archive - Long-term storage for Google Code Project Hosting.
u8glib has support for more displays than glcd.

I'll continue to look at it an try to get a feel for the amount of effort involved for the glcd library.

--- bill

The controller has a very complicated setup sequence (section 3.2). I assume some of the settings depend on the connected hardware (LCD Panel, SRAM, Driver, etc), so without a proper init sequence from "Sunlike Display", it is difficult to setup the display module. Also "Sunlike Display" mentions the RA8835, which is also confusing to me.

Oliver

Hi, I am in a project of using glcd version 3 using sort of Sanguino board, however, using ATMEGA 16 and trying to fit the library according to Sanguino board ( ATMEGA 644 )
and manual configuration of the pin assignment. The problem is when I try the Hello World thing it completely doesn't work and found out the
#error 'ATMEGA 644 has not been tested' on arduino_io.h, is this chip really not available for the library or just my stupid mistake?

And also I've made changes to the font libraries line, the
static uint8_t System5x7[] PROGMEM = {
const uint8_t System5x7[] PROGMEM = {
how does this affect?

Many Thanks, Ivan

louis89:
Hi, I am in a project of using glcd version 3 using sort of Sanguino board, however, using ATMEGA 16 and trying to fit the library according to Sanguino board ( ATMEGA 644 )
and manual configuration of the pin assignment. The problem is when I try the Hello World thing it completely doesn't work and found out the
#error 'ATMEGA 644 has not been tested' on arduino_io.h, is this chip really not available for the library or just my stupid mistake?

And also I've made changes to the font libraries line, the
static uint8_t System5x7[] PROGMEM = {
const uint8_t System5x7[] PROGMEM = {
how does this affect?

Many Thanks, Ivan

The error should be commented out. What that meant is that neither Michael or myself had tested that configuration
on real hardware.
Complicating things is that there are 4 different pin mappings for the 644/1284 processors.
"standard", "bobduino", "avr-developers", and "mighty-1284p"

I have a "todo" item to support all of them but right now only one is supported.
(I can't remember which).

The key to getting it to work is to have the proper pin mapping macros in arduino_io.h
and that depends on which core/variant you are using.

Which core and variant are you using?

--- bill

Hi Bill

I tried to compile HelloWorld which produces the following error:

In file included from /home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/allFonts.h:11:0,
                 from HelloWorld.cpp:18:
/home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/SystemFont5x7.h:48:28: error: variable ‘System5x7’ must be const in order to be put into read-only section by means of ‘__attribute__((progmem))’
In file included from /home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/allFonts.h:12:0,
                 from HelloWorld.cpp:18:

Maybe related to the previos post, because i assume i have to add some "const" keywords.

Appears with Arduino 1.0 and 1.0.1, ubuntu, latest release. I have also avr-gcc on my system, i am not sure which gcc is used by Arduino IDE.

Is it sufficient to add the "const" keywords in your code?

Thanks, Oliver

olikraus:
Hi Bill

I tried to compile HelloWorld which produces the following error:

In file included from /home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/allFonts.h:11:0,

from HelloWorld.cpp:18:
/home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/SystemFont5x7.h:48:28: error: variable ‘System5x7’ must be const in order to be put into read-only section by means of ‘attribute((progmem))’
In file included from /home/kraus/prg/arduino-1.0.1/libraries/glcd/fonts/allFonts.h:12:0,
                 from HelloWorld.cpp:18:




Maybe related to the previos post, because i assume i have to add some "const" keywords.

Appears with Arduino 1.0 and 1.0.1, ubuntu, latest release. I have also avr-gcc on my system, i am not sure which gcc is used by Arduino IDE.

Is it sufficient to add the "const" keywords in your code?

Thanks, Oliver

My first and immediate concern is to get the library working for everyone on all the platforms.
After that, optimizations and enhancements can be done to make things even better.
I guess I missed from Ivan's post that this const/static/progmem stuff was creating a compile error.
I'm currently not seeing this so I need to be able to reproduce the issue.

Do you have -Werror turned on?
The IDE (at least the linux ones) does not set this option, it sets -Wall
So while it generates warnings on linux, it does not crater the compiler with an error.
What OS, IDE and gcc toolset are you using?
I'm not seeing this as an error but rather a warning - I'll have to go try it on a VM in Windoze.
I'm pretty sure I tried it on XP with 1.0 and didn't have any problem. I'll have to check it again on 1.0.1

More background and history on this below
--- bill


The warning is actually a bug in the C++ compiler that the avr gcc folks have said that they are not going to fix.
It is actually a warning rather than an error.
Something about the way they handled the progmem and gcc attributes in C++ for the AVR.

I've wrestled with changing things to not have to deal with these progmem issues
for several years now. Unfortunately, there isn't a quick fix for this
and any fix has some ripple effects into other tools like FontCreator.
Some (most of it at this point) goes back to the way fonts were handled in the ks0108 library
which was the basis for the glcd v3 library.
All the fonts are currently included as a header file with the data being declared in the header.
This is ok until you have multiple source files that use the same font or include the same font header file.
If the data is not static you get multiple references
to the data structure and the link fails. If you declare them as static then the link can work but
you get multiple copies of the data included into the final image.
Also, when declared static if there is no reference to it in the module, the data is removed by the compiler.
Recent versions of the compiler and linker now have an option that will also remove dead code/data
using special sections so this helps eliminate one of the original needs for the static declaration.

With avr-g++ if you try to declare the object static const you are back where you started
and get the warning again.

The real answer is to fix how fonts are declared to avoid the need for static declarations.
It would have zero impact on the actual sketch code as it could all be under the covers.
However, it does impact all existing font header files which would suddenly become incompatible with the
library as the declaration needs to be slightly different.
It also affects FontCreator2.
While it isn't a large or complicated task to convert over to a new & better way of handling the font data,
at the time we created glcd v3 we decided not to do it.
(Michael and I did have several long conversations about doing it).

It is still on my list of things to do. Also on my list is to change the font
data format as well. I believe that Theile made a mistake in the font data format when defining
residual bits. The residual bits are encoded backwards in the byte from all the other fonts data bytes.
Another thing I'd like to look at is using bdf font format instead.
This would allow access to many fonts with a simple conversion script/tool.

Oliver,
I just tried to build glcd library example HelloWorld on XP using the current
Windows Arduino IDE (1.0.1) and glcd v3
after doing fresh installs (I hadn't tried 1.0.1 yet on Windows)
It does issue warnings just like on linux but it does build fine.

I am unable to reproduce the error.


For the bug log on the progmem stuff:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734
It look like after many years, it has finally been resolved in recent versions of avr-gcc.

If it is really an issue for Arduino, then there are some other ways to deal with it by playing games
with the progmem definition in the glcd header files.

i.e. something like this:

#if defined (__AVR__)
// Workaround for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734
// to prevent: warning: only initialized variables can be placed into program memory area
#ifdef PROGMEM
#undef PROGMEM
#define PROGMEM __attribute__((section(".progmem.data")))
#endif
#endif

I looked at this quite a while ago. It didn't make it into glcd v3, but it was on the list
for consideration in the next version of the library.

--- bill

I found this statement in here: GCC 4.6 Release Series — Changes, New Features, and Fixes - GNU Project

On AVR, variables with the progmem attribute to locate data in flash memory must be qualified as const.

It seems, that PROGMEM requires "const" since gcc 4.6.x.

When I change

static uint8_t System5x7[] PROGMEM = {

to

static const uint8_t System5x7[] PROGMEM = {

in GLCD v3 fonts/SystemFont5x7.h, then this font compiles is find.

I think my local gcc was updated from 4.5.x to 4.7.x on my last Ubuntu update to 12.10.

I also assume, that the Windows Arduino version comes with an old gcc version. Arduino IDE for Windows will work as long as an old gcc version is shipped with it.

My suggestion is to update all GLCD v3 font definitions with the "const" keyword.
As example, this also happed to avr-libc: [avr-libc-commit] [2282] Add 'const' for PROGMEM variables.

Oliver

olikraus:
I found this statement in here: GCC 4.6 Release Series — Changes, New Features, and Fixes - GNU Project

On AVR, variables with the progmem attribute to locate data in flash memory must be qualified as const.

It seems, that PROGMEM requires "const" since gcc 4.6.x.

What an odd choice that they have made. (To break all the old code)
Seems like it should have been a warning when left off as it is obvious what the intent is.

I think my local gcc was updated from 4.5.x to 4.7.x on my last Ubuntu update to 12.10.

I think you are very brave to run the most recent avr gcc releases.
Doesn't the latest AVR stuff have knowledge about const using progmem and how to fetch the data
from progmem on its own without requiring user code to have to use progmem access routines?

I also assume, that the Windows Arduino version comes with an old gcc version. Arduino IDE for Windows will work as long as an old gcc version is shipped with it.

The latest Arduino IDE 1.0.1 also supplies its own full AVR toolset for linux.
which is currently 4.3.2

Are you using the IDE and what IDE version are you using?
If no IDE are you using -Werror ?

My suggestion is to update all GLCD v3 font definitions with the "const" keyword.

Yeah, I agree. My concern is that they will change their mind again.
I'll put it in for the next release - It will require an update to FontCreator2 as well.
I was planning on doing a quick turn release to put in Leonardo support, but I need to
get a few volunteers to test it as I don't have a Leonardo board.
The first round of testing with one person went well and it seems to work
but I want a few more people to test it before I push it out.

I've seen stuff about automatically supporting "const" to put data in progmem
so that the C code no longer has to use progmem access routines to access data stored in flash when using "const".
(I thought that was in gcc starting with 4.6)
I'm not sure what impact that would have on data still being accessed using progmem access
routines.
And also how literal character strings will work as they are normally const by default and
if the compiler now moves const variables to progemem that would seem to break things
when pointers are used, particularly since I bet "const" was not strictly used in many people's
pointer declarations.

I'll have to closely look at all the pointers in code.

--- bill

Are you using the IDE and what IDE version are you using?
If no IDE are you using -Werror ?

I got the same error with Arduino IDE 1.0 and 1.0.1
At least i have not intentionally changed/removed the avr-gcc. But maybe some modifications had forced the IDE to use the avr-gcc from the Ubuntu package.

I was planning on doing a quick turn release to put in Leonardo support, but I need to
get a few volunteers to test it as I don't have a Leonardo board.

I was about to do release testing for the GLCDv3 variant of M2tklib. I could do this testing with your GLCD update and a Leonardo board.

Oliver

olikraus:
I was about to do release testing for the GLCDv3 variant of M2tklib. I could do this testing with your GLCD update and a Leonardo board.

That sounds great.
I'm going to have to try to replicate the problem.
I have not been able to reproduce this yet.
Are you by chance using the "arduino" package?
I am not. I always download and install the IDE myself as it allows me to install multiple
versions of the IDE for testing.
I have no idea what the arduino package does or where it installs.
In the past it was very problematic so I have continued to avoid it.

I'll have to create a VM for Ubuntu 12.10 (yuck.... for me the new Ubuntu releases are totally unusable)
to see what is going on with Ubuntu.
From what I've seen on Mint 13 (which pulls in from ubuntu 12.04) and Ubuntu 10.10,
IDE version 1.0.1 uses its own included gcc toolset (avr-gcc 4.3.2) even if you have a locally
installed version.
And while IDE 1.0 will use the locally installed gcc, Mint 13 uses avr-gcc 4.5.3

My concern is that the newer compiler will have other issues and modifications
needed to make the code actually work once it compiles.

--- bill

I have created a fresh installation of Arduino 1.0.1 IDE. GLCDv3 runs without problems now. So it is really an issue with the latest avr-gcc version.

Let me know if i can do some test with GLCD and Leonardo Board.

Oliver

Hey Guys. Just bought some gLCDS of ebay,
http://cgi.ebay.com.au/ws/eBayISAPI.dll?ViewItem&item=280920620504&ssPageName=ADME:X:RTQ:AU:1123#ht_2101wt_906

And i have both two arduinos, and two LCDs, and i have rewired both multiple times, and no matter what i end up with this:

I tracked down the datasheet for this module, and i found out that the CS pin actually ISNT cs on this module, its programming mode, either serial or parrallel!

Thats the data sheet..
Any idea on how to make GLCD work with this panel?
it looks FANTASTIC, but as you can see, the garbage on the screen doesnt help.

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.