Pages: 1 2 3 [4] 5 6 ... 21   Go Down
Author Topic: GLCD library version 3  (Read 66540 times)
1 Member and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 14
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


There's a port/adaptation of GLCD that supports these displays available at:

  https://github.com/MikeSmith/glcd_pcd8544

The architecture of the library is such that it's difficult to cleanly add support for other display types, so this isn't something that can just be dropped into the existing GLCD codebase, but the changes are limited to just glcd_Device and some configuration so it should be familiar to anyone that's used it before.

Hope this is useful to someone.

 = Mike
Logged

Dallas, TX USA
Offline Offline
Edison Member
*
Karma: 47
Posts: 2328
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yep its a total pain right now to add in any other display support.
Currently, there isn't a good/simple way to replace
the device layer module with another device layer module.

The focus of v3 was speeding up the ks0108 low level code
and adding in the text areas with the new/improved character rendering with a very high focus on maintaining
API backward compatibility with v2.

Its not just a problem for new panels. It is also an issue even for things like using an i2c/spi i/o expander to reduce
the pin count even when using ks0108 panels.

What needs to happen is the device layer and its interface needs to be ripped apart
and re-done such that it can be easily replaced.
Michael and I tossed around some ideas quite a while back that allowed each different panel to have it's own
device source code module. We ran into *many* issues with the arduino IDE and how it builds code and libraries.
The method we really wanted to use simply could not be done due to the way the IDE worked.
We abandoned it for the v3 release but did start to toss in support for a other panels, albeit in a kind of ugly way
primarily for own testing/experimentation.

The hope was to migrate a few new features (things like ellipse, arc functions, etc...) through the v3 code base but then at some point
perhaps move to a new device layer design for a v4 release that would allow an easy way to insert new device layers.

I'm not sure how to keep stuff like your library in sync with the main line glcd code.
For v3 there will not be any additional functionality added for the final release so for now it's
not that big of deal.
The only things I have planned before the final v3 cut is primarily documentation updates.
I also plan to update the build environment scripts because currently it can only be built
on windows and I need to be able to build it on linux/unix.
So many things are so much harder in windows batch files than unix shell scripts or makefiles.
My plan at this point is to redo things such that the windows batch file is a mere wrapper that
locates the WinAVR/Arduino tools sets up some environment variables then calls a shell script
or makefile.
That way the shell script or makefile is common between windows and linux/unix and the library
package can be built on either OS.

--- bill
« Last Edit: July 09, 2011, 11:31:53 pm by bperrybap » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 14
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I've been through a lot of pain with the way that Arduino builds libraries - what you really want is a split model where you have a 'family' driver (GLCD) that can use one or more device drivers - the challenge is keeping the interfaces in sync.  If you can live with forcing sketch authors to include two headers (one for the family, one for the driver) then the library include path is broad enough for you to share headers between the family and driver modules.

With regards to keeping the PCD8544 bits in sync; at this point I don't see it being a big deal since you're keeping things relatively stable.  If/when you sort out the driver model it should be easy enough to port into that and drop the separate library, and I suspect you won't be changing the driver model much otherwise so keeping up won't be hard.

Thanks, by the way, for all the work you guys put into GLCD - it's been very useful!
« Last Edit: July 10, 2011, 01:45:48 am by MikeSmith » Logged

Dallas, TX USA
Offline Offline
Edison Member
*
Karma: 47
Posts: 2328
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

To create you own font header files,
use the GLCDFontCreator2 package that is available on the glcd_arduino google page.
It can create a font header from any font that is on your system.
Its Java and I've used it on both windows and linux.

On linux use the same command as in the start.bat batch file
to bring it up only change "javaw" to "java".

BTW, the java bitmap conversion tool in bitmaps/utils/java works for windows but not for linux.
For linux I use the commandline tool (bmp2glcd) that you saw down in my debug area.
bmp2glcd also works on windows as well. For windows to use it from the explorer GUI,
you simply create a batch file wrapper which allows the use use the drag & drop capabilities for batch files.

Eventually, I'll get around to adding in a  drag & drop batch file and then provide a download
package on the google-code page.

--- bill
Logged

Dallas, TX USA
Offline Offline
Edison Member
*
Karma: 47
Posts: 2328
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I've been through a lot of pain with the way that Arduino builds libraries - what you really want is a split model where you have a 'family' driver (GLCD) that can use one or more device drivers - the challenge is keeping the interfaces in sync.  If you can live with forcing sketch authors to include two headers (one for the family, one for the driver) then the library include path is broad enough for you to share headers between the family and driver modules.

We looked at doing that, but it was more work than we wanted to bite off for the v3 release.
It was a big enough change to split out the glcd & gtext classes.

Once you get into splitting out the device layer, things can get really hairy pretty quickly, because then you
start to see all kinds of displays. Some that can't read data, some have multiple colors and several have additional
capabilities that would be nice to take advantage and some have different pixel layouts. It starts to explode
quite quickly.

One of things that makes this code particularly complex and tied into the ks0108 page style pixel ordering
is not using a frame buffer. Using a frame buffer makes things so much simpler (and faster) especially
if the text rendering could render directly to a frame buffer but a frame buffer simply can't be used
to allow the code to run on things like a m168 which only has 1k of total RAM.

Using a frame buffer would make things so much easier as well as add lots of new capabilities (like being able to
write to the buffer in an ISR thread)  but we decided not to go that route for v3.


--- bill
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 14
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

To create you own font header files,
use the GLCDFontCreator2 package that is available on the glcd_arduino google page.
It can create a font header from any font that is on your system.
Its Java and I've used it on both windows and linux.

I tried using it, but it insists on discarding all the whitespace on either side of all of the glyphs, so fixed-width fonts become variable-width fonts (this happens both on Windows and on the Mac).  I've pulled the fonts into FontForge and the various system font tools to be sure that they're spaced correctly.  Mostly this just makes things look a bit funny when the font is weighted for fixed-width use.

There's also something weird going on with the font names it offers vs. those that the system uses for fonts that makes it a bit annoying to find a font after importing it (and don't get me started about installing fonts on Windows... smiley-cool

But, if it's what there is, I'll stick with it.

 = Mike
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 14
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I should have asked - is anyone maintaining a repository of additional GLCD fonts?

Now that I have the workflow sorted, I'll probably turn out a few more conversions, but it would be good to have somewhere to put them to share...

 = Mike
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I've been having a bit of a problem with the library recently. Due to some memory issues, I'm trying to migrate all my strings to flash space, initially I thought this would be simple due to the built-in commands that move strings from print commands to the flash space, but I've been getting errors on the ones I need:

With "GLCD.print(flashStr(""));" I get this error: "error: call of overloaded 'print(_FlashString*)' is ambiguous"
With "GLCD.printFlash("");" I get this: "error: no matching function for call to 'glcd::printFlash(const char [17])'"

"printf_P(PSTR(" does work, however, but it can't be used for the majority of my strings, as you can imagine. Any ideas what could be causing this, and how to fix it?
Logged

Dallas, TX USA
Offline Offline
Edison Member
*
Karma: 47
Posts: 2328
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'll have to take a look at it.
This appears to be a problem/bug with the glcd library and will more than likely require
some code tweaks.

Are you running the latest library? RC2?

Not that it should be the solution but I'm not understanding your comment:
but it can't be used for the majority of my strings, as you can imagine.

--- bill
Logged

Dallas, TX USA
Offline Offline
Edison Member
*
Karma: 47
Posts: 2328
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well its been a while since I used the glcd flashstring stuff.
While its usage is currently poorly and perhaps even incorrectly documented and the compilation errors are
quite confusing when not used properly, it actually does work.
The main reason that it is so odd is that as of Arduino 0022 flash strings are not supported by the arduino print class
This means that the glcd library has to extend the print class or implement it outside the arduino print class.
Currently the library implements support for printing flash stings outside the print class.
And because the glcd library is c++ it can't play some of the casting games that can be done in C
to hide some of the needed casts.

Code:
GLCD.print(flashStr(""));
won't work because the Arduino print class does not support flash strings.
Code:
GLCD.printFlash("");
doesn't work because the glcd library printFlash() function was written to only work for strings in flash memory.
The above call/declaration is not using a flash string. While the string is in flash program memory it is
still copied to RAM, which is defeating the point of printFlash(). So if you call it as above, there is no
printFlash() function to process a "normal" string stored in RAM.

The real answer would be to update the Arduino Print class or extend it to know about flash strings.
But for now that isn't the case.

So in order to print strings in flash memory you have a few options.

GLCD.printFlash(flashStr("your string here"));
GLCD.printFlashln(flashStr("your string here"));
GLCD.Puts_P(PSTR("your string here"));
GLCD.Printf_P(PSTR("your string here"));

Hope that helps.

I'll update the documentation to indicate how to properly use these functions
and in the mean time look at alternatives for making it simpler and more integrated
with the arduino print class.

--- bill
« Last Edit: July 26, 2011, 03:52:23 pm by bperrybap » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks very much for the help! "GLCD.printFlash(flashString("string"));" didn't work, however changing "flashString" to "flashStr" fixed it. It's a tad convoluted, but it does the trick, thanks for the help.  smiley
Logged

Dallas, TX USA
Offline Offline
Edison Member
*
Karma: 47
Posts: 2328
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks very much for the help! "GLCD.printFlash(flashString("string"));" didn't work, however changing "flashString" to "flashStr" fixed it. It's a tad convoluted, but it does the trick, thanks for the help.  smiley

oops  smiley-red Typo on my part.
(i'll fix the above post so nobody else runs across this).

--- bill
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 30
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm trying to hook up a KS0108 GLCD (the one that comes with MikroE EasyPIC3 devboard) to my arduino using your library.
I think all the wires are at correct place, and I've loaded the Diagnostic sketch which runs fine and says TESTS PASSED at the end.
Still, I can't see anything on the display.
I've tried moving the potentiometer of the contrast all around and it makes no difference.

Ouf. What could it be?
Here are the results of the test:

Code:
Reported Arduino Revision: 22
--------------------------------------------------------------------
GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
GLCD Lib build date: Sat 04/23/2011 15:01:49.03
GLCD Lib build number: 421
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)
 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
--------------------------------------------------------------------
Diag Loop: 3
Initializing GLCD
Displaying ChipSelect Screens
Walking 1s data test
Wr/Rd Chip Select Test
Testing GLCD memory pages
Horizontal Page Test Chip: 0 Pixels 0-63
Vertical Page Test Chip: 0 Pixels 0-63
Horizontal Page Test Chip: 1 Pixels 64-127
Vertical Page Test Chip: 1 Pixels 64-127
Full Module Horizontal Page Test:Pixels 0-127
Full Module Vertical Page Test:Pixels 0-127
Tests PASSED
GLCD.SetDot() speed (K ops/sec): 17.35
Logged

Dallas, TX USA
Offline Offline
Edison Member
*
Karma: 47
Posts: 2328
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

That diagnostic output is a very good sign. It means all the wires to the Arduino
are pretty much guaranteed to be hooked up correctly.
What that leaves is the contrast circuit.

On most glcd modules the contrast circuit will use a 10-20k pot.
The wiper (center connection) will connect to the Vo input pin on the glcd (usually pin 3)
One leg will connect to the Vee output pin this is usually glcd pin 18
One leg of the pot will go to ground.

Do you have it hooked up this way?
What value pot are you using?
Have you tried adjusting the pot?
One adjustment end will usually display nothing, and the other end will usually turn on the pixels
regardless of which pixels should be on. You have to adjust it a bit for the best display of pixels.


If you hook up the pot as above and still nothing, it could be that the Vee power supply is bad.
This can happen if the module was incorrectly hooked up.
To test Vee,
if you have a digital volt meter, measure the voltage between ground and Vee. It should be negative.
(black wire to ground, red wire to pin 18 on the glcd)
Be very careful if/when you test this as it is easy to slip between glcd pins and shorting
pins can damage glcd.

Hope that helps.

--- bill
« Last Edit: August 07, 2011, 05:29:00 am by bperrybap » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 30
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks for the reply.
so:

- The contrast pot is ok. I'm using a 10K one. If I turn it left or right, no pixels turn on on the screen. WEird?
- Vee is -5.04V, with Arduino running on USB power.

- Also, I tested the GLCD with a PIC and it perfectly works.

Attached is a picture of my actual circuit, to help check if connections are wrong.

By spookyrufus at 2011-08-07
« Last Edit: August 07, 2011, 07:33:20 am by spookyrufus » Logged

Pages: 1 2 3 [4] 5 6 ... 21   Go Up
Jump to: