Go Down

Topic: GLCD library version 3 (Read 82 times) previous topic - next topic

MikeSmith


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

bperrybap

#46
Jul 10, 2011, 06:29 am Last Edit: Jul 10, 2011, 06:31 am by bperrybap Reason: 1
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

MikeSmith

#47
Jul 10, 2011, 08:37 am Last Edit: Jul 10, 2011, 08:45 am by MikeSmith Reason: 1
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!

bperrybap

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

bperrybap


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

Go Up