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

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

Hi
I can not display the degree symbol using GLCD.print (char (value))
I can create? Using examples of the library LiquidCrystal not work.
Any idea?
Thanks and sorry for my bad English

ehuntabi,
Many hd44780 displays have a degree symbol in character position 0xdf or 223 decimal.
The glcd library uses fonts that are different from a hd44780 display.
To display a degree symbol as a character, you will need a font that contains
a degree symbol character.
I went and looked at all the fonts that are included with the library and none
of them have a degree symbol.
If you are using the System5x7 font and would like to add a degree symbol,
it is fairly easy.
You can add a degree symbol to System5x7 font table.

Here is the definition for the degree symbol:

	0x00, 0x06, 0x09, 0x09, 0x06 // degree symbol

This can be added to the table by either replacing a character that you don't want/need
or it can be added to the back end of the table.
If this is added to the backend of the font table, you also have to bump
the character count from at the top of the table from 0x60 to 0x61.
If you add to the back end of the table you will use 0x80 or 128 decimal to print the character.

Attached is a SystemFont5x7.h header file that has the degree symbol added to the back end
of the font table.

Just keep in mind that if you use a modified version of the font, that your code will
only work properly with that modified font file. So that means that if you want/need
others to able to build your code you will need to also supply them with the modified
font file.

--- bill

SystemFont5x7.h (4.96 KB)

Hello Bill
I followed your instructions and .... Already!!
Thank you very much for your time.

Hi, i am a arduino - newbie and posted a thread in the german Forum- area (with Images and Serial output): http://arduino.cc/forum/index.php/topic,160271.0.html

I´ve got a Display with 1x HD44105 and 2x HD44102 , resolution 100x32. I wired the Display to an arduino UNO in 8bit mode via KS0108 wiring. The Images in the german thread represent my Problems, the GLCDdiags works fine in Serial LOG , but on Display it is wrong.

These are my changes in "..Panel.h":

/*********************************************************/
/*  Configuration for LCD panel specific configuration   */
/*********************************************************/
#define DISPLAY_WIDTH 100
#define DISPLAY_HEIGHT 32

// panel controller chips
#define CHIP_WIDTH 50 // pixels per chip
#define CHIP_HEIGHT 32 // pixels per chip

And These in "...Device.h":

 * LCD commands -------------------------------------------------------------
 */


#define LCD_ON				0x39
#define LCD_OFF				0x38
#define LCD_SET_ADD			0x40
#define LCD_DISP_START		0x3E   // Display start page 0 -->3E
#define LCD_SET_PAGE		0xB8

In glcd_config.h i use this Option : #define GLCD_READ_CACHE - whitout this, sie Serial Log Fails !

I hope it was somewhat understandable and you can help me.