Go Down

Topic: How to control 2 graphic LCDs with one Arduino (Read 9 times) previous topic - next topic


Hi Bill
I had a look on the files you indicated and identified the changes to do.
I would like to double check if it is correct (using autoconfig panel) to wire  CSEL1 and CSEL2 of the second display to pin 32 and 31 of Arduino Mega?
Thank you.


Yes that is correct.
The CSEL1 and CSEL2 of the second glcd will connect to the pins for CSEL3 and CSEL4 in
the config file.

When I did my prototype, I used separate backlight resistors and separate contrast pots
for each glcd module as well.

One thing that might help wire things up is to use header pins on the glcd modules
(if you aren't already) and then use an old IDE cable. You can then plug the glcds into
the IDE cable (each one gets a row) and plug the cable into a proto board
where you can connect up the control and data lines and split off the other signals
as needed.

Be careful with the IDE cable though. Some are not straight through for all pins.
I forget which pins are funky but there is lots of information about it if you google around
a bit.

--- bill


Hi Bill.

It seems that it is not working as expected...

Let me explain what i did:
1) I wired LCD1 according standard pin configuration and executed GLCDDiags: works fine
2) I wired LCD2, connecting together D0 to D7 of both LCDs, then GLCDDiags failed for LCD1. It seems that Mega outputs are not strong enough to pilot 2 LCDs in parallel (the Mega is powered by an external 5V power supply).
3) I decided to bufferized the signal before wiring D0 to D7 to LCD2 (using a IC I had : http://www.datasheetcatalog.org/datasheet2/0/01slcj14uf4688drxqfuui427d3y.pdf). GLCDDiags worked well again with LCD1.
4) I connected R_W, D_I and EN for LCD1 and LCD2 together. GLCDiags continued to work well with LCD1. LCD2 was displaying wrong data (normal as CSEL1 and CSEL2 were not connected).
5) I connected CSEL1 and CSEL2 respectively to pin 32 and 31 of Mega. Same behaviour for LCD1 and LCD2.
6) I compilled GLCDDiags with the modified files (copied below). GLCDDiags blocked in loop1 while initializing GLCD. In LCD 1 I could read on the half left Chip:1 64-127 and in the right half a bitmap pattern. Nothing displayed in LCD2.

Here below are the files I used:

Code: [Select]
* glcd_Config.h - User specific configuration for Arduino GLCD library
* This file has been modified to automatically configure the library for using
* two LCDs 128x64 ks0108 panel as one LCd 256X64
* Use this file to select the active glcd configuration file
* Then edit the selected panel file to configure parameters for that panel.
* This wiring is identical to the wiring used in the previous ks0108 library.
* For Teensy devices the wiring selected matches the wiring documented on the Teensy website.

#ifndef glcd_CONFIG_H
#define glcd_CONFIG_H

 * You can select a configuration file by uncommenting one line to include the
 * the desired configuration file.
 * Select 1 and only 1 configuration file.
 * The "AutoConfig" configuration files will configure the library based on a set of
 * pre-customized configurations for the supported Arduino board type.
 * These configurations match the the panel configurations and wiring diagrams
 * in the library documentation based on the type of board selected in the Arduino IDE
 * and are compatible with wiring used in earlier versions of the ks0108 library
 * NOTE: if you have a panel that has different dimensions than the distributed configuration, you can either
 * edit the supplied configuration file for that board type or create a fully custom configuration file.
 * The auto configuration file (default is named  "config/ks0108_Panel.h") selects the appropriate board
 * pin configuration file based on the current board selection in the Arduino IDE.
 * The auto configuration panel configuration files can be found in the "config" directory, the naming is:
 *  "{PANELNAME}_Panel.h"
 * Where:
 *   {PANELNAME} is the glcd panel type. (for example, ks0108)
 * The pin configuration files for each board type can also be found in the "config" directory, the naming is:
 * Where:
 *   {PANELNAME} is the glcd panel type. (for example, ks0108)
 *   {BOARDNAME} is the name of the board (as selected in the Arduino IDE).
 * So for example, the auto configuration file name for a ks0108 panel
 * would be: "ks0108_Panel.h"
 * The ks0108 pin configuration file for a "Arduino" board would be: "ks0108_Arduino.h"
 * and the pin configuration file for a "Mega": "ks0108_Mega.h"

*  - Does the autoconfig work correctly in your environment with your boards and displays?
*  - Is the mechanism to make a custom configuration easy to use?
*  - We want your comments and suggestions for making configuration easer, particularly for novices
* Additional "autoconfig" files can be created, there is an example for 192x64 panels in this distribution.
* In the future there will be more for different panel types, like sed1520, ks0713, etc..
* Not all custom configuration files that may be supplied in the release are included in the alpha distribution

 * autoconfig includes - (comment this out if using manual configurations, see below)
//#include "config/ks0108_Panel.h"          // automatically configure library for a ks0108 panel
//#include "config/ks0108-192x64_Panel.h"   // automatically configure library for a ks0108 192x64 panel
#include "config/ks0108-256X64_Panel.h"          // automatically configure library for a 256X64 panel



Code: [Select]
* ks0108-256X64_Panel.h - User specific configuration for Arduino GLCD library
* Use this file to set LCD panel parameters
* This version is for a standard ks0108 display using 2 LCDs 128X56
* This file uses a board specific pin assignment file based on the board selected in the IDE


* define name for panel configuration
#define glcd_PanelConfigName "ks0108 - two LCD 128X64"

/*  Configuration for LCD panel specific configuration   */
#define DISPLAY_WIDTH 256 // width using two 128X64 graphic LCD

// panel controller chips
#define CHIP_WIDTH     64  // pixels per chip
#define CHIP_HEIGHT    64  // pixels per chip

* the following is the calculation of the number of chips - do not change

/*  Chip Select Configuration                            */

* Change the following define to match the number of Chip Select pins for this panel
* Most panels use two pins for chip select,
* but check your datasheet to see if a different number is required
#define NBR_CHIP_SELECT_PINS   4 // this panel is using 4 CSEL pins (2XLCDs)

Any idea on how to debug?
Thank you for suporting.


Hi Bill

Maybe it can help to understand...

I wired in parallell CSEL1 and CSEL2 for both LCDs and executed GLCDDiags standard (to pilot one 128X64 LCD). In this case LCD1 is displaying fine while screnn in LCD2 is not fine.
GLCDDiags shows Tests PASSED.

I was wondering, as I am using a buffer for LCD2, this is introducing a delay on D0-D7, shall I need to tune delays?



You should not need any additional buffering. There should not be a loading issue.
The glcd will place very little load on the AVR pins and the AVR pins have quite a bit of "oomph".
This is a wiring issue or possibly a library code issue as I haven't specifically tested your exact configuration.
The main reason that I say it might be a library code issue is that currently the library
uses 8 bit values for x/y coordinates for speed. Because of this, the maximum
pixel value can be is 255.
There are some funny things that happen in the code as the display size gets to 256 pixels wide.
The code will actually not be able to address all 256 pixels across.
You will for sure lose the right most pixel all the way down.
There well may be some issues with the code as I have never tested the code with a 256 pixel wide
configuration and currently a pixel value of 255 is "magic" to the code internally.
We didn't put much effort into testing 256 pixel wide displays as we hadn't seen any panels this large
and this dual display mode is not something that many people will hook up.
You are off pioneering into some new territory.

Also keep in mind that incorrect wiring could potentially damage the glcds.
(unconnected wires are essentially the same as miswired wires)

On reason there can be issues is that if both glcds are not wired correctly, more than 1 glcd
or even more than 1 chip on a single glcd module
can attempt to drive the data bus at a time so you end up with bus collisions.

The way these modules work is that depending on the control line logic levels,
the ks0108 chips will do various things to the data bus.
The data bus is bi-directional. It must be shared between input and output so
all entities that are hooked up to the data bus must all be in agreement with
who should be using the data bus and in which direction.
In this setup, there are 5 entities (6 if you count the buffer chip)
that are potentially driving/accessing the data bus. The AVR, and four ks0108 chips (2 per glcd).
(Also the buffer chip if that is hooked up)

If a chip is selected, then it looks at the other control lines to see what to do
with the data bus. If the chip is not selected it floats its data bus pins to allow
something else to drive the bus. That could be another ks0108 chip on a glcd module
or it could be the host (AVR) depending on what is going on.
When selected, the chip will then look at the read/write line to see if the data bus
should be listened to (write rw=low) or driven (read rw=high).
The EN signal determines when the chip will drive the bus. If the rw pin is high,
the chip will drive the data bus pins as soon as EN goes high and will continue
to drive the bus as long as it remains selected, EN remains high and rw remains high.

When the data lines of both glcd modules were originally tied together, it sounds like none of the control lines
of the second glcd were hooked up. Because of this, the second glcd has floating control
lines. Floating inputs are not good. More than likely many if not all of the control lines float up to high.
If they all float high, then you would end up with the both ks0108 chips on the second glcd module
being selected (cs1+cs2 high) in read mode (r/w high) and EN high.
In this condition, both ks0108 chips on the second module
would attempt to drive the data bus all the time and that would
crash with the other module or even the AVR trying to drive the data bus.

Adding an external chip to drive the data bus for the AVR will not solve this.
Also, I'm not sure how the library code could work with that buffer chip.
(I'm betting that diags was failing).
I'm not sure how the buffer chip was hooked up but
since that buffer chip is not bi-directional and does not seem to have any output enables, it
will drive the bus all the time. Because of this, the AVR would not be able
to properly read data from the glcd memory as the buffer chip would be
driving the data bus at the same time as the ks0108 chips during read

My suggestion is to remove the buffer chip and wire up the glcds directly
to the AVR pins.
Since these two glcd are being treated as a single glcd module to the software,
they both must be fully hooked up before either will work properly. It is just
like with a single glcd. If you left any wires not hooked up, the glcd will not work
properly. In this case if any wires on either glcd are not hooked up correctly,
it makes both fail.

Hook up d0-d7 lines together, hook the rw, en, di, lines together.
Then hook up each modules contrast and backlight pins separately.
All the CS lines must be hooked up and none can be shared.
(I can't see your mega pin configuration file but I'm assuming you didn't change it)
CS1 & CS2 from first module would pins 33,34
and CS1 & CS2 from second module would be pins 32,31

It should then work.
If not, run the diags sketch and capture the serial output
and past it here and we can diagnose from there.
If things are not working, then the serial output is a great tool
as it shows everything that the library is using to configure its low level
i/o code.

I'll work with you until we get this up and working to make sure that there is not
any issues in the actual library code, especially when the display
size is 256 pixels wide.

--- bill

Go Up