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

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.

rainwulf,
Unfortunately, you have a ST7920 display and the glcd library does not support the st7920.
Have a look at this library which does support the st7920:
http://code.google.com/p/u8glib/

--- bill

awww crap!!
I was looking forward to using gLCD as its pretty awesome.

Thanks for your help!!

What's the problem? You can drive your ST7920-based display using u8glib, and that display needs only 2 Arduino output pins to drive it - unlike the parallel-only interface displays supported by the standard GLCD library.

Its a lot slower with the 2 pin interface, and it doesnt seem to work with my 8 bit controller.
Even u8glib shows random noise, you can JUST make out the test graphics.

I dont know what the hell is going on...
I got text mode working though, using the code from dfrobot.

The 2-pin interface is quite quick if you use the SPI pins and the SPI hardware to drive it. Unfortunately, the ST7920 it doesn't have a CS input, so it can't share the SPI pins with anything else unless you use external clock gating hardware.

dc42:
The 2-pin interface is quite quick if you use the SPI pins and the SPI hardware to drive it. Unfortunately, the ST7920 it doesn't have a CS input, so it can't share the SPI pins with anything else unless you use external clock gating hardware.

"quite quick" is relative.
While it is definitely usable,
it is not anywhere close to the speed of being able to control the pins directly.
For example, it takes 3 bytes across the SPI and 24 sclk transitions to transfer a single byte on the st7920
Even if the the AVR was pushing the SPI at 8mhz that is 3us.
(fastest sclk rate on AVR is F_CPU/2 or 8mhz on 16mhz parts. so 24clock is 3us at 8mhz)
Just for a single byte transfer.
While 3us may sound fast, when doing thousands of updates it makes a difference.

The BIG issue when using SPI on glcds, is that there is no read capability.
That puts a big constraint on things. The library either has to create a full shadow buffer
or has to live with certain limitations.
Oliver took a balanced approach in u8glib by using a partial shadow buffer that moves around
to paint the display.
It does come with some limitations in that the user code must paint the display a
particular way. It also requires re-drawing the screen L/s times to update the display
where L is the size of the LCD display memory, and s is the size of the shadow memory.
For example on a 128x64 display the paint routine code will have to be called 8 times as the shadow
buffer is 8 pixels tall. It has to be called and run to full completion for each lcd page.
During each iteration, pixels that land in the shadow buffer are updated and at the end
of the iteration, the shadow buffer is pushed to the display.

This further slows things down.

And even after dealing with that, there is still some functionality that cannot be provided
without having full read access to the display data. Things like scrolling or being able draw
on top of the existing pixels.

It is still very usable but because of these issues and limitations, it ends up being quite a bit
slower than having direct control with read access.

That said, I do agree you do pay for the additional speed and capability it in terms of pins.

I've looked at supporting the st7920 in parallel mode. (It also has a 4 bit mode)
The issue that came up immediately is that the pixels in the st7920 are not
stored in its memory the same way pixels for ks0108, sed1520, and ks0713 are stored.
The existing code in glcd is highly optimized for a different pixel mapping and can't really
be made to easily work with the st7920.

The real answer, is to have a full shadow buffer and then you get the best of all worlds.
This would allow the library to have full access to the display pixels regardless of the interface used.
Because of the local shadow buffer the pixel to glcd memory pixel mapping becomes irrelevant.
It would also allow things like rotating the geometry on the display.
Lots of code in glcd could get smaller and faster if a shadow buffer were always used.
This issue is that the AVRs used in most Arduing boards don't have enough RAM to do that.
The chipkit, Maple, DUE, and even some of the "duinos" by third parties like teensy or the "sanguino" boards
do have enough ram to have a full shadow buffer.

I've been considering a glcd v4 design that may change things up and even
potentially require a frame buffer.

I also think, oliver could easily tweak u8glib to use a full shadow buffer
which would allow it work more like glcd and would give it a speed bump as well.

But as mentioned above, it requires more ram that is available on many AVR platforms.

--- bill

bperrybap:
The real answer, is to have a full shadow buffer and then you get the best of all worlds.
This would allow the library to have full access to the display pixels regardless of the interface used.
Because of the local shadow buffer the pixel to glcd memory pixel mapping becomes irrelevant.

That's exactly what I do in my ST7920 library. Yes, it uses just over half the RAM of an Arduino Uno; but I've not yet had any other tasks that don't fit comfortably in the remaining RAM, provided that I use PROGMEM for string literals and other constant data.

dc42:

bperrybap:
The real answer, is to have a full shadow buffer and then you get the best of all worlds.
This would allow the library to have full access to the display pixels regardless of the interface used.
Because of the local shadow buffer the pixel to glcd memory pixel mapping becomes irrelevant.

That's exactly what I do in my ST7920 library. Yes, it uses just over half the RAM of an Arduino Uno; but I've not yet had any other tasks that don't fit comfortably in the remaining RAM, provided that I use PROGMEM for string literals and other constant data.

agreed. It starts to get harder when the display gets larger than 128x64.

I uploaded the "Big Nums" test sketch to my Arduino Uno connected to my KS0108-controlled LCD module. However, what should be on the left side of the display shifted to the right side, and what should be on the right side shifted to the left. Other than that, everything displays perfectly. I double checked the wiring and found no issues. Could someone please help me?

I bought the LCD from this vendor at Ebay.

http://www.ebay.com/itm/128-64-12864-128x64-Character-LCD-Module-Display-Screen-LCM-IC-KS0108B-104-/170899666269?pt=LH_DefaultDomain_0&hash=item27ca69f55d

Here's a picture of what goes on.

Thank you,
Maxwell

Max,
The library includes a diagnostic sketch and documentation to help diagnose issues like this.
Have a look at the included HTML documentation as well as the library wiki.
Here is a link to the library wiki:
http://playground.arduino.cc/Code/GLCDks0108

--- bill