Multiple 192 x 64 KS0108 Displays using OpenGLCD library?

How can this be accomplished? Because of the global instantiation of GLCD, there doesn't seem to be an elegant way to accomplish this without a lot of modification to the library. I am using an Arduino Mega 2560 with an ERM19264-1 series display I bought from buydisplay.com. The LCD uses 3 chips and 3 chip selects. I am trying to get three of them connected and working synchronously.

Thanks

Yes the current library only supports a single display instance.
However, there is a way to “trick” the library into using more than one.
You can trick the library into thinking the multiple displays
are part of a larger single display.
See the attached images for examples of using two 128x64 displays.

There are some issues to be aware of:
The current code uses uint8_t for the pixel coordinates so you can’t have a pixel coordinate larger than 192,
which doesn’t seem to be an issue in this situation.
This means that you would create a 192x192 display by creating a virtual display of the physical displays
my mapping them vertically to create the larger display.
That said, the current code can only deal with having 4 chip selects, so depending on how your chip select
signals need to work, it may not work for all 3 displays.
It is very likely that you will need more than 4 chip selects.
The change to support more than 4 chips selects is quite trivial and if you chose to go down this path,
I can update the library for this.

With respect to wiring:
All glcd modules will share

  • data lines,
  • R/W
  • DI
  • E
  • reset (if used)

Each module will have its own contrast control circuit and pot for control.
(You might be able to share the pot across all of them using the VEE signal from one,
but I’ve not dug deep enough to see if that could work or has any potential issues)

The chip selects may or may not be shared depending on how the
chipselects work for the GLCD.
More than likely the chipselects will not be shared.
So if you have a GLCD that uses 2 chip selects, then you will likely need to have 6 chip selects
and the macros that control the chip selects will need to be updated to support more than
the current 4 maximum.

Depending on how you are planing to use the displays wiring may be an issue.
(i.e. if they are not all very close to each other it will not work).

To use them/it, you use it as a single larger display. For text you can create text areas
that are within the desired physical display. Graphics is a bit of an issue since there is no equivalent
to a text area for graphics. So you have to be careful with your coordinates and clearing the display.
For clearing an individual physical display, you can cheat a bit and create a text area
that encompasses the pixels for the physical display and then use ClearArea() to clear that display.

— bill

Thank you very much for the reply. I have been trying to 'objectify' the library on my own a bit; with regards to the wiring, I have had that exact wiring scheme. However by having multiple objects I lost some of the modularity and compile efficiency (which was expected). Unfortunately with this current wiring scheme, I get artifacts on the other screens when drawing to a different one. If you could alter the library to support up to 9 chip selects, which would be the 3 x (192 x 64) screens, I would be incredibly grateful as dealing with the bugs I'm running into is becoming a bit arduous and I want to keep wiring to a minimum rather than taking all GPIO pins of the Mega. On a separate note, these particular displays I bought use a negative voltage supply of 0 to -10 volts to control the contrast. I have the backlights (powered by external power supply) of all three tied to a 2N4401 transistor controlled by a PWM pin. I wanted to do something similar to digitally control contrast, however the negative voltage makes it a bit annoying. Is the best approach simply a PWM pin connected to an inverting op-Amp with the output gain tied to a low-pass filter then to the contrast input voltage pin? Thank you again for your help, I sincerely appreciate it!

What did you mean by:

Unfortunately with this current wiring scheme, I get artifacts on the other screens when drawing to a different one.

Not sure if you looked at Olivers u8glib library: http://code.google.com/p/u8glib/ I believe that it can support multiple displays. It works very differently than openGLCD.

Bummer on the number ofchip selects. Some 192x64 glcds use 2 and some use 3. Can you post a link to the displays you are using? I'd like to see which one you are using to see if there are some other possibilities other than having to use 9 chip selects and to make sure that the updates will work with your displays.

But even if 9 chip selects are needed, it might be worth using something like a 4-line/BCD to 10 line decoder like the 7442 to reduce it down to 4 pins to save pins.

--- bill

Yes, these are the displays I am currently using:

http://www.buydisplay.com/default/4-inch-192x64-lcd-arduino-dot-matrix-display-ks0107-ks0108-black-on-yg?gclid=CjwKEAjwpcGfBRDni__JqrTIqx4SJAB9BpSOJgcPubybeNwn7NjTbMWsbOC3XwiMXelo0bFOyBJAlBoCAjXw_wcB

I did originally plan on using u8glib, however the lack of native 192 x 64 support made me think it would have been easier to approach what I am doing with modifications to openGLCD.

Also what I meant by artifacts is that when I have all of those data lines shared in parallel, when I, for example, send an image to screen #1, you will see some remnants of that same image appear on the other screens. This is happening after I modified the library to create different instances of screens. Its happening likely because of some timing issues while sharing data lines which I have been slowly getting to. But I would love an easier solution than what I am currently doing.

Thanks again for your help and ideas

--Pete

Big_Pete:
Yes, these are the displays I am currently using:

http://www.buydisplay.com/default/4-inch-192x64-lcd-arduino-dot-matrix-display-ks0107-ks0108-black-on-yg?gclid=CjwKEAjwpcGfBRDni__JqrTIqx4SJAB9BpSOJgcPubybeNwn7NjTbMWsbOC3XwiMXelo0bFOyBJAlBoCAjXw_wcB

Ok, I see these are the displays with 3 chip selects.
I’ll go update the code to support more chips & chip selects.

I did originally plan on using u8glib, however the lack of native 192 x 64 support made me think it would have been easier to approach what I am doing with modifications to openGLCD.

I’m kind of surprised at the lack of ks0108 192x64 support in u8glib.
Modifying openGLCD for multiple instances is a pretty big modification.
I have plans to refactor the code for a 2.x release but that is still a ways out.
When that happens, many things will change like multiple instances, and support
for different interfaces and user definable pins in the sketch along with support
for more display chips.

Also what I meant by artifacts is that when I have all of those data lines shared in parallel, when I, for example, send an image to screen #1, you will see some remnants of that same image appear on the other screens. This is happening after I modified the library to create different instances of screens. Its happening likely because of some timing issues while sharing data lines which I have been slowly getting to. But I would love an easier solution than what I am currently doing.

typically a timing issue will cause corruption on the selected display.
If the data is going to the incorrect display or the incorrect portion of the display or showing up multiple times
on the same display, that is more than likely an issue with the chip select code
incorrectly driving the chip select pins and selecting the incorrect chip or selecting multiple chips.

I’ll PM you when I have something to try as I’ll want to work off line with you to
have you give it a try before I release it.
It may be a day or so before I have something ready.

— bill