To read more about or even try the openGLCD library, it can be found on bitbucket:
bperrybap / openGLCD / wiki / Home — Bitbucket
Please post any questions or support issues for this library in new threads.
Very good. After reading your comment, i just went to my lab, pulled out my GLCD test board and did some testing with openGLCD. Works without any problems. Real plug and play. I would call this already very stable.
Also M2tklib works after one minute in compatibility mode without any visual issues. I just replaced all
#include <glcd.h>
lines with
#include <openGLCD.h>
#include <include/openGLCD_GLCDv3.h>
In the documentation i have seen that API calls will be more consistent. I guess that implements some of my suggestions long time back 
Unfortunately font data is still located in the header files.
Also bitbucket.org seems to be a nice replacement for google code. I wonder what is the difference to google code (except for the disabled download feature for google code in the next year).
All in all: Looks very promising.
Oliver
olikraus:
To read more about or even try the openGLCD library, it can be found on bitbucket:
bperrybap / openGLCD / wiki / Home — Bitbucket
Please post any questions or support issues for this library in new threads.
Very good. After reading your comment, i just went to my lab, pulled out my GLCD test board and did some testing with openGLCD. Works without any problems. Real plug and play. I would call this already very stable.
Did you happen use the Arduino IDE to install the library?
That should work.
Also M2tklib works after one minute in compatibility mode without any visual issues. I just replaced all
#include <glcd.h>
lines with
#include <openGLCD.h>
#include <include/openGLCD_GLCDv3.h>
**There is also another way that is documented.**
**Created a glcd.h header file that includes those two header files and put it in the openGLCD library.**
**With either way, I want people to consider GLCDv3 mode as a temporary solution.**
In the documentation i have seen that API calls will be more consistent. I guess that implements some of my suggestions long time back :)
**I got sick of the inconsistencies. Most of them go back to whoever did**
**the java AWT graphic lib as SUN as this is what was used as model for GLCDv3.**
**The java drawn "pixels" are in between the actual real physical pixels and then**
**get mapped to the real pixels.**
**They did it in an attempt to make things easier for color when merging colors**
**betwen adjacent pixels.**
**The problem is that they were not consistent, particularly when filling objects**
**and especially for circles. So it is one big mess that merely creates confusion.**
Unfortunately font data is still located in the header files.
**That is not as bad as it seems.**
**Part of the issue is backward compatibilty with GLCDv3 and some**
**of the font tools.**
**The user no longer includes font header files. That is taken care of by the library.**
**When a user does include the font header if it is a font that the library knows about**
**then the include is a NOP since it has already been included.**
**This methodology works when using the IDE as the IDE combines all C++ files (if there are multiples)**
**into to one megalithic CPP image so the actual data will only get declared once.**
**This might break users that don't use the IDE and use real tools like make.**
**However, there is a plan in place to move the data to a .c file.**
**I wasn't ready do it yet, but it is pretty simple for the library.**
**The bigger issue is updating some of the font and bitmap tools to work**
**with it.**
**Not sure if you notice but the font and bitmap headers now use a openGLCD macro**
**for declarations.**
**This eleminates all the progmem section issues for the AVR platforms.**
Also bitbucket.org seems to be a nice replacement for google code. I wonder what is the difference to google code (except for the disabled download feature for google code in the next year).
**Well, I may actually go back to google code.**
**The reason is I really don't like the bug tracker on bitbucket which is kind of clone**
**of the one on github. I think the google issue tracker is much more powerful**
**and much more useful. It is much better if you want to allow users to enter their**
**own tickets as you can provide templates.**
**Overall, the google code issue track is simply much better.**
**Also the wiki on bitbucket as many issues and can't do many types of direct links**.
All in all: Looks very promising.
Oliver
**Thanks.**
**I have many plans for the project.**
**I'm looking at adding in support for other interfaces besides direct parallel**
**like shift register and i2c.**
**I have a shift register implmentation that uses only a single pin.**
**Not very fast but only uses a single pin.**
**At some point I'm going to do a major re-write which will break things**
**into cleaner layers and separate out the panel/devcice layer and the interface layer.**
**That is when support for many of the other displays will come in**
Hi Bill
Yes, I have used Arduino IDE 1.0.5 and I just followed your instructions. The M2tklib port was more like a quick and dirty modification. I just wanted to see how openGLCD behaves under more heavy conditions. Your preliminary release indeed behaves very stable.
I hope to find some time to migrate the existing GLCD glue code for M2tklib to the new openGLCD API, but maybe i should wait for some first official release. Do you expect larger changes to the openGLCD API?
Also thanks for your comments on "bitbucket.org".
Oliver
olikraus:
Hi Bill
Yes, I have used Arduino IDE 1.0.5 and I just followed your instructions. The M2tklib port was more like a quick and dirty modification. I just wanted to see how openGLCD behaves under more heavy conditions. Your preliminary release indeed behaves very stable.
I hope to find some time to migrate the existing GLCD glue code for M2tklib to the new openGLCD API, but maybe i should wait for some first official release. Do you expect larger changes to the openGLCD API?
Also thanks for your comments on "bitbucket.org".
Oliver
I wouldn't think that the glue will change much.
There may be a +1/-1 to some pixel values here and there
and a few include changes, but hopefully isn't more than that.
My goal was to try to make it as painless as possible to transition.
I don't anticipate any big changes to the API.
In fact the API changes at this point are probabaly going to be pretty minor if at all since
any change at this point is LOTS of work, since there is so much existing documentation
and API examples already in place.
The reason I have that warning in is that longer term, some things must change
to support things like multiple displays and I REALLY want to change the variable font format
but those will be part of a 2.x release
where several things may have to be "broken" to move forward.
I had thought about removing some of the really old API functions
like PrintNumber(), and the functions that use the FLASHSTRING type
but I may just leave them in.
One of the changes I was considering was changing a few of the Arduino pins.
The main thing is that I really want to free up the i2c pins on the m328 boards and
currently A4/SDA is being used for the enable pin.
Changing this isn't an API change but wouldn't allow quick and easy testing
for an existing wiring/board using GLCDv3.
The other area of change that I'm looking at is to create a new way to configure the pins.
This might require the user sketch code to create the GLCD object using a constructor or something that
looks like a constructor rather than it already existing.
The GLCDv3 compatibilty mode might create it for you.
So really the changes at this point are not so much to the API but perhaps to the
initialization/declarations.
And even then, I'm really trying minimize the changes from GLCDv3.
--- bill
BTW, if you have any issues or suggestions that would help make it easier for M2tklib to integrate with openGLCD
let me know and I'll see if I can get them integrated.
updates to openGLCD should be more timely than with GLCD as I pretty much stopped
working on GLCD due to it being LGPL vs GPL.
--- bill
I wouldn't think that the glue will change much.
Ok, then i can start updating M2tklib at any time.
bperrybap:
BTW, if you have any issues or suggestions that would help make it easier for M2tklib to integrate with openGLCD
let me know and I'll see if I can get them integrated.
As far as i remember, i had to hardcode ascent and descent values of a font into the M2tklib code GLCD code. Having procedures to return these values, would be great.
Oliver
The font rendering really doesn' t use true ascenders or descenders.
The characters are rendered within a rectangular box.
The height is the same for all characters of a font, and the width is either
a constant for fixed width fonts, or variable per character for variable width fonts.
There are several things you can query that should give you the
information that you need.
font height, character width, and many text area properties.
See:
- CharHeight()
- CharWidth()
- GetAreaProp()
See the html documentation and examples.
There is an example for every single API function which includes
information about the function in the comment header of the sketch.
Also, some fonts have padding between characters and some dont,
so it is best to use the API function to determine rendered width of a character/font.
--- bill
Another thing you might want to take a look at is the
DrawString() function. It has many new features for positioning.
Sounds good. I will look more deeply into the new API procedures when i start porting M2tklib. Thanks for the hints.
Oliver