openGLCD library and Arduino UNO connection to backpack

hey everybody,

I am sort of new to area and i have got a question regarding this openGLCD library.
After reading the documentation I am very excited and I want to try it.

Probably my question looks very simple to some but i will go on and ask it.

So far I was using the old (very difficult and limited) library with my sparkfun 128x64 lcd. I have to admit that the connection was very easy using the backpack hence I went straight to the programming.

But now that I want to use the wiring as shown in the documentation I am facing some issues.

As you can see in the picture the CSEL1, CSEL2 and D7 are not there (or are under a different label maybe?)

I am really confused.
Can someone please advise?

I can't tell what you are trying to do so you will need to supply additional information.
I am assuming you are eliminating the backpack (won't be using it)
and will be wiring the Arduino directly to the glcd as you won't be able to use this
library with the backpack.
Actually, it would be possible to use the backpack,
but it would require quite a bit of s/w work and an additional library to make it work.

In order to proceed we need to know/have:

  • a datasheet for the display you have.
  • which Arduino you have

Have you read the openGLCD library html documenation on wiring?
[Wiring]->[KS0108 Family]
Which parts were confusing?
Knowing this will help me update the documentation to make it better.

--- bill

Bill thanks for the response.

I want to use this library hence if i have to get rid of the backpack I will do so (or I will manage to get an lcd without the backpack using the KS0108). Of course in this case I fully understand the wiring since the instructions are crystal clear.

My query is whether I could use it with the backpack (but you already answered that I guess).

The lcd that I have is this SparkFun Serial Graphic LCD 128x64 - LCD-09351 - SparkFun Electronics
And I have got an Arduino UNO, a Leonardo and I recently managed to burn the bootloader and program a little bit with an ATmega644p (similar to sanguino).

tsosmi:
Of course in this case I fully understand the wiring since the instructions are crystal clear.

So are you saying you have the glcd wired up directly to an Arduino board and working with openGLCD?
Which Arduino "board" did you end up using?
Uno, Leonardo, or the 644?

I had a look at the serial glcd you have. Is the backpack soldered to the glcd?
If so, it will be difficult to desolder. It might be better to order another ks0108 display
if you want to play with openGLCD.

--- bill

Yes, it it soldered hence I will have to order an other one.

Thanks a lot for the guidance!

I really appreciate it :slight_smile:

If you are not pressed for time, you can get ks0108 glcds fairly inexpensively on ebay.
--- bill

tsosmi,
you could treat the backpack like an Arduino board and load sketches on it that use openGLCD.
It would be a standalone Arduino board at that point rather than being a backpack to another Arduino.
You would use an ISP programmer to program it which would overwrite the backpack firmware, but it would work.
You would have to update the openGLCD configuration file to match the wiring/pinout that is used
on the backpack as it is different from the default openGLCD configuration.

--- bill

hm, that sounds kind of interesting. Though I think i will be lost :grin:

I guess that suggests burning the bootloader on the backpack right?
It uses the ATmega168.

I think I could go through with it. Similarly with the other AVRs..
I will connect to the MISO/MOSI/CLK/RESET/GND/Vc and upload the bootloader, then upload some test code.

but i think i will need some help with the wiring/pinout configuration (I have NO idea whatsoever..).

:roll_eyes: :roll_eyes:

I connected the backpack as I said and uploaded the arduino bootloader.

As we can see https://www.sparkfun.com/datasheets/LCD/Monochrome/Graphic%20LCD%20Backpack-v15.pdf
and http://arduino.cc/en/Hacking/PinMapping168
the pinout is:
Analogue Inputs - ADC0 up to ADC5
Digital Pins - PD0 up to PD7 and PB1 up to PB5

I understand that the schematic is for a PDIP and not for a TQFP but I guess the pins are similar, right?

Now I need some guidance.. :roll_eyes:

Not sure a bootloader will be the way to go. The reason is that the serial connector on the board
only has TX, RX, VCC and GND. They didn't bring out the DTR or RTS signal. This means that autoreset
can't work even if you have a FTDI cable.
They also don't have a reset button/switch on the board, so can't simply press the button as you upload
from the IDE.

Since you were able to burn a bootloader, you have ISP programming capability.
Did you use an ISP programmer or maybe Arduino as ISP with another Arduino?
Regardless, that will be the way you will want to program the backpack with your openGLCD sketches
as that way you won't need a bootloader.
i.e. use [File]->[Upload Using Programmer] rather than the upload button.

To use openGLCD sketches on the backpack you will need to modify the openGLCD config file used
for the m168 processor to match the wiring of the backpack.
I would recommend making a copy of it before you modify it.
The config file is openGLCD/config/ks0108/PinConfig_ks0108-Uno.h

You will need to modify the pin definitions to match the backpack wiring.
The good news is rather than deal with the Arduino pin mappings for the part,
openGLCD will allow you to specify the AVR port/bit numbers directly.
So for example, if you look at the schematic you can see that GLCD data bit 0 is
connected to PB0.
So that means you must chnage the define for glcdPinData0 to PIN_B0
a few more examples:
EN on PC0 so glcdPinEN will be PIN_C0
DI on PC1 so glcdPINDI will be PIN_C1
etc...
You will need also need to uncomment the glcdPinBL line
to allow using the backlight. The backlight (BL_EN in the schematic) is wired to PB2
so glcdPinBL will be PIN_B2
You probably should also define the reset signal as well. You can see that on the schematic
as PC3.

For your display you can ignore the glcdPinCSEL3 & glcdPinCSEL4 in the config file as they are not
needed for your display.

After you update the needed 15 signals in the pin config file, you will also have to modify
the ks0108 panel file since the backlight is turned on when
the signal is low vs high.
To do that you will have to modify the configured panel file.
The default panel file is openGLCD/config/ks0108/AutoConfig_ks0108-128x64_Panel.h

You must change this:

//                    BLpin    on   off
#define glcd_BLctl glcdPinBL, HIGH, LOW

to this:

//                    BLpin    on   off
#define glcd_BLctl glcdPinBL, LOW, HIGH

After you make those changes the openGLCD diag sketch or other examples should be able to run on the backpack.
If you have any issues with getting pins assigned just ask, and I'll help you.

--- bill

Hello,

Update on the project...

I changed the files according to your guidance.

 * ks0108_Uno.h - User specific configuration for openGLCD library
 *
 * Use this file to set io pins
 * when using an Uno, 2009, or any AVR m168/m328 based board
 *
 */

#ifndef GLCD_PIN_CONFIG_H
#define GLCD_PIN_CONFIG_H

/*
 * define name for pin configuration
 */
#define glcd_PinConfigName "ks0108-Uno"

/*********************************************************/
/*  Configuration for assigning LCD bits to Arduino Pins */
/*********************************************************/

/*
 * Pins can be assigned using Arduino pin numbers 0-n
 * Pins can also be assigned using PIN_Pb 
 *    where P is port A-L and b is bit 0-7
 *    Example: port D bit 3 is PIN_D3
 *
 */

/* Data pin definitions
 */
#define glcdPinData0        PIN_B0
#define glcdPinData1        PIN_B1
#define glcdPinData2        PIN_D2
#define glcdPinData3        PIN_D3
#define glcdPinData4        PIN_D4
#define glcdPinData5        PIN_D5
#define glcdPinData6        PIN_D6
#define glcdPinData7        PIN_D7

/* Arduino pins used for Control
 * default assignment uses the first five analog pins
 */

#define glcdPinCSEL1        PIN_C4
#define glcdPinCSEL2        PIN_C5

#if NBR_CHIP_SELECT_PINS > 2
#define glcdPinCSEL3         3   // third chip select if needed
#endif

#if NBR_CHIP_SELECT_PINS > 3
#define glcdPinCSEL4         2   // fourth chip select if needed
#endif

#define glcdPinRW           PIN_C2
#define glcdPinDI           PIN_C1
#define glcdPinEN           PIN_C0 // (A4 is also I2C SDA)
// Reset  - uncomment the next line if glcd module reset is connected to an Arduino pin
#define glcdPinRES          PIN_C3    // optional s/w Reset control (A5 is also I2C SCL)

#define glcdPinBL	PIN_B2 // optional backlight control pin controls BL circuit

#endif //GLCD_PIN_CONFIG_H

As well as the "AutoConfig_ks0108-128x64_Panel.h: file.

I managed to get the "Hello World" example (though I think there is something wrong) running but not the others...Pic atached.

Any ideas?

Looks good. It is very close.

Have you run the diags sketch?
All the documenation recommends running this if there is any issue or
to initially get things working.
See the html documenation for the expected results including screen shots
of the display.

Have you read the section on troubleshooting in the html documentation?
This issue is the 3rd bullet down.

The chip select pins are reversed.
You can either fix it in the panel file or the pinconfig file.
I'd fix it in the pin config file.
Just swap the definitions for CSEL1 and CSEL2.

I'm curious about the other sketches. What is happening there?

--- bill

Hey Bill,

I am away for a couple of days, I will make the changes on Thursday and i will post the results.

What does the CSEL1 and CSEL2 actually do?

This morning that I tried to upload the other examples, the screen just changed in terms of contrast (darker or not) but nothing else was was happening.

Thanks for the guidance.

tsosmi:
Hey Bill,

I am away for a couple of days, I will make the changes on Thursday and i will post the results.

What does the CSEL1 and CSEL2 actually do?
Good question. The 128x64 ks0108 glcd modules internally use a chip that only controls
64x64 pixels, so there are two of them on the glcd.
One controls the left 64 pixels and one controls the right 64 pixels.
So in order to modify the pixels on the display, you have select one of the chips then
tell it what to do. The CSEL1 and CSEL2 pins are how you select which of the two chips
to talk to. If you get them backwards, then you end up talking to the wrong chip and
the two halves are reversed.
And that is what you see in the hello world picture above.
The actual addressing is a little more complicated but when there are only two chips
the CSEL lines essentially pick which chip to talk to; so, to fix it, you can simply reverse
the connections

This morning that I tried to upload the other examples, the screen just changed in terms of contrast (darker or not) but nothing else was was happening.

Please get back to me when you can as I want to track down what is causing the issue
to make sure it isn't something that needs to be fixed in the library.

Hey Bill (and everybody),
Merry Christmas!

Thanks for clearing up the CSEL pins..
Following the changes you told me to do, everything works ok so far regarding the "Hello World" (pic attached) and all the other examples.

I tested all the examples, at least the ones that were small enough tobe stored on the ATmega168.
Unfortunatelly the diagnostics do not fit...

The issue that I am facing is when using the Serial2GLCD..
The lcd show the "listening..." line but when I type on the serial screen strange symbols occur (pic attached).

I thing we are very close into finishing the whole thing (sorry for the trouble)..

PS. I am trying to assign an analogue input (potensiometer) but I have an issue with the pin assigment.
Lets say that I forward the signal to PC2 (analogue input) - I assign it as:
int sensorPin = PIN_C2;
And I connect the signal to the shield to that pin(It is named WR). nothing happens.
.Any ideas??

hm...
the diag sketch fits for me.
I'm using the 1.0.5 IDE on linux.
(Different IDEs and OSes use different version of gcc)
What IDE version and OS, and board type are you using?
How big is it when you compile it for the m328?

Also, the IDE does not properly calculate the amount of space available
when not using a bootloader. So when using ISP programming the IDE still
tries to reserve the bootloader space.
If you are using a board type using the older bootloader then 2k is "lost".
If using optiboot, then only 512 bytes is lost.
When I build it, there is still about 1k free so it fits even when the 512 bytes
is reservered for optiboot, but not for the older bootloader.
The only work around for this is to create a new board type and then
you can set the bootloader size to 0.

Using AVR pin/bit numbers defines is only supported by openGLCD.
There is quite a bit of special code in openGLCD to unwind all the arduino pin mappings to make it work.
For any of the Arduino core functions you will need to use the Arduino pin numbers.
So you can't use PIN_C2 for analogWrite() but you could use A2 instead.
However, unfortunately, for that board all the analog signals are already connected to the glcd.
While there are some tricky ways to share some of the pins the real issue is how to disconnect
the sensor/pot from the analog pin?
i.e. you can't have sensor on the Arduino pin as well as use the Arduino pin to control the glcd
because depending on how the sensor/pot is driving the Arduino pin, it will potentially create a short
when the Arduino pin is re-programmed ad used as an output.
i.e. when the pot is at one end the Arduino pin would be grounded and at the other end
of the pot the Arduino pin would be connected to VCC.

There are a couple of alternatives.
Solder your wire to the ADC6 or ADC7 pins and use those.
You will need to use a board type that has 8 ADC pins.

Alternatively, you could cut the trace between the glcd RESET and PC3.
Then wire the glcd RESET pin to VCC and disable s/w reset control in the pin config file.
That would free up PC3 which is A3 or D17.

Another useful option would be to cut the traces going to CS1 and CS2
and re-wire them to go to PB3 and PB4. That would free up the i2c pins
and then you could use i2c devices.

On the wierd characters, it looks like a bad bad baud rate.
This could be caused by the F_CPU value being used not matching the actual clock rate of the MCU.
This could be because the crystal frequency on the board,
doesn't match the frequency defined by the board type used, or
perhaps the fuses got messed up and the AVR using the internal osciallator,
but F_CPU still being set as if the crystal was being used, which would also
cause the F_CPU to not match the actual clock rate of the MCU.

--- bill

bperrybap:
hm...
the diag sketch fits for me.
I'm using the 1.0.5 IDE on linux.
(Different IDEs and OSes use different version of gcc)
What IDE version and OS, and board type are you using?

I am using the 1.0.5 and Windows 7 (I have Ubuntu installed but I havent started using it yet -noob)
the board type is Arduino Nano with ATmega168.

How big is it when you compile it for the m328?

It has the same capacity as when it is compiled for the m168 - 15.924 bytes

Also, the IDE does not properly calculate the amount of space available
when not using a bootloader. So when using ISP programming the IDE still
tries to reserve the bootloader space.

I have burned the Arduino bootloader on the m168.

If you are using a board type using the older bootloader then 2k is "lost".
If using optiboot, then only 512 bytes is lost.

How can I see which bootloader was burned? I guess that depends on th m168, right? Arduino as ISP burned the one that refers to that chip..?

When I build it, there is still about 1k free so it fits even when the 512 bytes
is reservered for optiboot, but not for the older bootloader.
The only work around for this is to create a new board type and then
you can set the bootloader size to 0.

Hm, you mean I will copy the file of the Arduino Nano w/m168 and set bootloader to 0?

Using AVR pin/bit numbers defines is only supported by openGLCD.
There is quite a bit of special code in openGLCD to unwind all the arduino pin mappings to make it work.
For any of the Arduino core functions you will need to use the Arduino pin numbers.
So you can't use PIN_C2 for analogWrite() but you could use A2 instead.
Understood

..........

On the wierd characters, it looks like a bad bad baud rate.
This could be caused by the F_CPU value being used not matching the actual clock rate of the MCU.
This could be because the crystal frequency on the board,
doesn't match the frequency defined by the board type used, or
perhaps the fuses got messed up and the AVR using the internal osciallator,
but F_CPU still being set as if the crystal was being used, which would also
cause the F_CPU to not match the actual clock rate of the MCU.

--- bill

Regarding the workarounds I will give it a shot.
Of course these issues will not exist when the LCD I ordered will arrive.

Kind Regards,
Dimitrios

When you use ISP programming, you don't use the bootloader.
In fact the ISP programming erases the bootloader so when not using the bootloader
the space is available for normal code.

That nano board type uses a 2k bootloader. And even when you select upload using a programmer
the dumb Arduino IDE still wants to reserve the room for the bootloader even though it is erased and
overwritten.
You will need to create a new board type.

Here is a new board type for you.
I'm not sure if it fully works as I don't have a "Arduino as ISP" setup to test it.
(I use a USBASP or AVR dragon for ISP programming).
This entry will need to go in the boards.txt file down in:
{installdir}/hardware/arduino

sfunGLCD.name=SparkFun Serial GLCD using arduinoisp

sfunGLCD.upload.using=arduinoisp
#sfunGLCD.upload.protocol=arduino
sfunGLCD.upload.maximum_size=16384
#sfunGLCD.upload.speed=115200

sfunGLCD.bootloader.low_fuses=0xff
sfunGLCD.bootloader.high_fuses=0xdd
sfunGLCD.bootloader.extended_fuses=0x04
sfunGLCD.bootloader.path=optiboot
sfunGLCD.bootloader.file=optiboot_atmega168.hex
sfunGLCD.bootloader.unlock_bits=0x3F
sfunGLCD.bootloader.lock_bits=0x0F

sfunGLCD.build.mcu=atmega168
sfunGLCD.build.f_cpu=16000000L
sfunGLCD.build.core=arduino
sfunGLCD.build.variant=eightanaloginputs

While I defined the fuses and bootloader for the optiboot bootloader,
the bootloader won't be used when programming and you don't need to
program one.

Once you add this to the boards.txt file, you have to restart the IDE.
Then after you select this board, you can now use the [->] "upload" button
to upload the code and it will automatically try to talk an "Arduino as ISP" programmer
to do the uploading.
(That is what the upload.using line sets up).
If you want to use a different programmer then you will need to modify the upload.using line.

--- bill