There may be some tutorials out there, but I don't know of any.
For now, you'll have to look at the example sketches and the API documentation
to try to get a feel for how things work.

Most of the calls are fairly obvious.
Text areas are a bit novel and may take a bit to get used to, but once
you declare them and initialize them they are pretty easy to use.

One of the things I'm working on that will be in a future release is that
many of the API functions in the HTML documentation will include an
example of how to use the function.



--- bill

Great!
That is a great photo by the way. Probably one of the best I've seen for this.
So many that people post are blurry, have poor lighting, or simply don't capture all the wires.

A couple of things look  odd, and maybe some are picture "tricks" and perhaps
you already fixed them.

The resistor and sharing bread board "holes":
It looks like the resistor is trying to share holes with other wires.
Red wired on the power rail, and a blue wire that goes off to the pot or maybe it is
the red wire in column 40.
While it can physically be done,
it isn't reliable and will have issues, since often the wires are not exactly the same size
so one wire may not get proper connection if any. Best to never do that.

Red Anode wire:
There is a red wire that looks like it goes over to maybe pin 19? (the backlight Anode?)
doesn't look like it is connected to anything. Maybe the resistor actually connects to it instead of the blue wire?
The resistor needs to connect between the Anode and the power rail.
(maybe it does if the resistor is connected to the red wire vs the blue wire)

Vee signal to pot:
It looks like the blue wire that appears to be sharing a wire with the resistor
is not connected to the glcd. Without that connection to Vee, no pixels
will show up.
(Maybe you meant Vee and pin 18 instead of Reset and pin 17 in your post?)


So I'm guessing you have figured out how the rows and power rails are all connected now.
The gap in the middle of the board separates the two columns.
One thing to be careful of is using both power rails. In this case you connected them
but only used one. But suppose you had used them both. For example hooked up
glcd pin 2 or glcd pin 2 to the upper rail instead of the bottom rail. It might not have worked.
This is because you can get what is known as ground bounce. The ground and power levels being
used for the some parts of the glcd would not necessarily be the same as the levels being
used for the signals. This occurs because during signal switching, chips use more power for that
very brief period of time and when they "suck" on the power lines the power lines can momentarily
droop or a ground can momentarily float up.
To cure this you could use some capacitors across the rails.
It is best to use as few rails as possible, disconnect unused rails, and then to keep all the power and ground inputs
as close to each other as possible on the rails. This can help avoid those types of things.

Anyway, glad it is all up and working.

--- bill

Any clue as to what might be going on. Maybe I need to leave it for a while, but it is perplexing that it eventually initialised correctly and then suddenly went back to the initial error, Pedro

I am still using the multi stranded jumper leads until I can fit some solid core wires.

Stranded wires are very difficult to work with.
unless they are the stranded wires with the solid pins on the ends like these:
http://www.ebay.com/itm/65pcs-Multi-Color-Mixed-Breadboard-Jumper-Cables-For-Arduino-Code-Wire-Prototype-/350766025178?pt=LH_DefaultDomain_2&hash=item51ab48c9da

Those types of stranded wires are prefect for this kind of stuff.
If the ends of the wires are stranded and just twisted together,
they are difficult to push into the headers or a breadboard.
If the connections between the wires and the sockets are marginal, all kinds of weird things can happen.
Simply touching or moving something can cause connection issues.
On the female headers like what is on the Arduino board, stray strands can also twist around
and short to the adjacent pin under the plastic header.
I would say never use wires with stranded ends or expect issues.

How long are your wires? Long wires can also cause issues.

As far as initialization goes,
Other than faulty wires/wiring, there is no reason I can think of why tieing glcd reset
to VCC would work, when using the additional pin for s/w reset wouldn't work.
The best solution to guarantee a proper initialization every time is to use the
additional pin for software reset.
If connecting the glcd reset pin to VCC or leaving it disconnected,
then the only way to reset the glcd module is to power it off.
What that means is that in order to start a clean initialization, the board
and glcd must be power cycled.
Without power cycling, a single faulty initialization can lead to seeing things not working because
of something going wrong in the past.

Using the extra pin to allow the library to reset the glcd is the best way
to ensure that the library and the glcd are both starting clean during
initialization. It uses an extra pin which is why it isn't the default.
The next best way is to use the reset pin from the Arduino, but because
of the poor auto-reset circuit on the Arudino, it doesn't work on some
boards.
If tying gcd reset to VCC or leaving it disconnected, the board and glcd
need to be power cycled between tests to ensure the glcd is starting
from a clean uninitialized/power-up state since there is no way
to reset it.

When diags worked, were you seeing the diag images on the display
and can you adjust the pixel intensity by adjusting the contrast pot?
The html documentation included in the library has a section on diags with sample images of what
the display will look like during diags.

Can you post some photos of your setup?
Photos would help.

--- bill

A BUSY timeout means that the library is checking to see if the glcd module is
ready after powering up and after waiting longer than should be necessary,
it wasn't. This is normally due to a wiring issue. (it could be related to the glcd reset pin)
The glcd is more than likely actually ready but because of a wiring issue
the library is not seeing the proper glcd status.

One common error is getting the glcd pins reversed.
From looking at the photos on the ebay link you provided, it appears
that the glcd has pins 1 and 20 labeled. Just make sure to not to accidentally
reverse them when using the header and breadboard.

What kind of wire are you using?
I'm assuming you are plugging the wires into the Arduino headers
and the breadboard. Stranded wire doesn't work very well for this.
Solid core wire is best.

If you want to verify your wiring against the library configuration, look
at the serial diag output.
It displays each function followed by the arduino pin and port information as:
function:ArduinoPin#(portinfo)

You can use this to verify the wiring by looking at the arduino pin# and making sure
that it connects to the glcd pin associated with the designated function as indicated
by the datasheet.
example
DI:17(PIN_C3)
means that Arduino pin 17 must connect to the glcd DI function which according
to the datasheet is glcd pin 4

If you are positive that the wiring is correct, then it may require enabling s/w reset.
This is done by going into the config file and uncommenting the line with the glcdRES
(to uncomment the line remove the comment indicator the two slashes at the beginning of the line)
Then hook arduino pin 19 to the glcd reset pin (glcd pin 17).

--- bill

According to the datasheet, glcd pin 18 is not the reset pin.
glcd pin 18 is Vee which is the negative voltage used to drive the contrast
circuit. It should be hooked up to one leg of the pot.
The glcd reset pin is glcd pin 17.

What code are you uploading?
I highly recommend using the diag sketch as it can offer clues as
to what is going on.
My guess is that something is not hooked up correctly.

For now stick with either of your options #1, or #2  (from your previous post) with respect to the
reset line (just a reminder, reset is glcd pin 17 not glcd pin 18).
I would start with leaving the glcd reset pin disconnected.

First thing,
go back and verify each of the wires between the glcd and the arduino to make sure
that they match the datasheet - that is much better than just going by "type A", or "type B".
Use the datasheet to determine where each wire needs to go.
This is why having the correct datasheet is critical. Without that, it is next to impossible
to get the connections correct.

To verify your arduino connections, look at the datasheet pinout, then look at the table on the wiki.
Using the table on the wike page, focus on 2 columns:
- Arduino 168
- Function

What you do is follow down the data sheet pinout for each of the 20 pins.
Some pins are voltage gnd, vcc, - those are easy.
(connect the backlight pin LEDA to the resistor then to VCC)
There is Vee which connects to 1 leg of the pot.
There are also some special glcd pins like reset, and Vo.
 reset will be left disconnected for now.
 Vo (contrast voltage input) will be connected to the center wiper of the pot.
Then there are the data and control glcd pins that must be connected to Arduino pins.
For each pin on the datasheet that is a data or control pin, look at the wiki table column "Function"
to locate the function, then look left to the "Arduino 168 column"
to see where which Arduino pin the glcd pin should be connected to.


For example, on your sheet you can see that
glcd pin 4 is D/I
Now go down the function column on the wiki table then go left to see that in the Arduino 168 column
that should be hooked up to Arduino pin 17.
a few more exmaples:
glcd pin 14 is DB7 which hooks to Arduino pin 7
glcd pin 16 is CS2 which hooks to Arduino pin 15 (analog 1)

As far as actual connections go, how are you attaching the wires to the glcd module?
soldering them? Soldering a 20 pin header and using a breadboard?

Can you post some clear closeup pictures of your wiring:
- a closeup of the wires connected to the Arduino
- a closeup of the wires connected to the glcd module
- a wider shot that shows everything.
The goal of the photos is to be able to identify where all the wires are going.
If I can see that I can be a second set of eyes to see if anything looks out of place.

It would also help to run the diag sketch and post the output from the serial port here.
That will offer some clues as to what is happening.

--- bill

Thanks Bill,

I will have a look at the wiki/playground page, as that is the latest information, and see what I can work out,

Pedro

The wiki explains a simple workaround.
--- bill

Pedro,
See the KS0108/GLCD playground page. There is quite a bit of information about this issue.
Play close attention to the glcd reset pin wiring, and make
sure to read all the notes about it and troubleshooting when uploading is
not working.

BTW, I don't particularly recommend the pdf file for documentation as it is
not actively maintained anymore.
The included html documentation is better and more complete.
The wiki/playground page has even more up to date notes in it since it is updated after the release.

--- bill

Does the backlight and a simple "hello world"  work?
i.e. if you print some thing simple before the large font stuff, does that work?

When adding an i2c backpack, I've seen 2 main problems that people have encountered.
- Soldering the backpack on backwards/upsidedown (means pin 1 vs pin 16 is backwards)
- getting the constructor incorrect.

Usually it is the constructor that is incorrect.
It might be the i2c address, or it could be the pin mapping used in the constructor
does not match what is used by the i2c backpack
(different boards using different pin mappings between the lcd and the PCF8574 chip)

Are you sure that your your backpack uses the pin mapping used in the constructor?
The best way is get it correct is to either use the pin mappings provided by the vendor of the backpack,
or ohm out the board to figure it out.
If you can't do either of those, you could run the i2clcdguesser sketch I wrote.
You can find a zip of it over in this thread:
http://forum.arduino.cc/index.php?topic=157817.msg1235230#msg1235230

--- bill

Uhhh. Sorry guys.
fm's library that I'm working with has been slightly modified.
I corrected the misspelled "t_backlighPol" in my version of the library and didn't test
my test sketch on a stock release. 

pulsarus,
I updated the sketch in the earlier post to allow it work no matter how
the backlight type is spelled.
Just re-download the test sketch from my previous post and it should compile now.

Sorry about that.

--- bill

Teensy: http://www.pjrc.com/teensy/


It is as small of a pre-built "duino" as you'll find.

--- bill

A0 to A5 should work.
After going back and looking at your code, I can see an issue.
A0, A1, A2, A3, A4 and A5  are defined by an Arduino system header file in pins_arduino.h
You declared them yourself with this line:

Code:

int A0,A1,A2,A3,A4,A5;

I'm not sure how it compiled for you.
Your sample code does not compile for me using Arduino 0.22, 1.0, or 1.04

But by defining those yourself,
they will override the Arduino values. (assuming it compiles)
And since they were not filled in with anything,
they would all default to a value of zero.

Are you sure the code you were using was what you posted,
or that it compiled without any errors?

--- bill

One thing that I noticed is that you also removed a comment from the code
when you modified it:

Code:

* LCD R/W pin to ground

While this has no affect on the actual code,
did you hook up the lcd r/w pin to ground?

--- bill

I think you are misunderstanding how sprintf() works.
 8< - - -
0 will work just fine.

Really? I thought all functions in the printf family use \0 as the string termination character.

Actually, you do have a good point.
It doesn't affect the actual sprintf() or its processing.
However, since the \0 will be stored in the output buffer created by the sprintf()
the function called to process the string will stop early and not output the \0.
That would be the lcd.print() function.

It would work for printf() since printf() would simply output the character
but you are correct that it won't work when using
sprintf() because the \0 character is put in the buffer and that terminates
the C string early.

So I humbly concede to you that when creating a buffer with sprintf() you can't
use the 0 character since the buffer created will create a false end of string
when calling the buffer processing function, lcd.print() in this case.

Sorry, I wasn't thinking. I never use sprintf() anymore on Arduino as I always set up the linkage to
allow printf() to work,  or most of the time use a Printf() macro that sets up the linkage
for vfprintf_P() and automatically convert string literals to progmem strings
and then output the characters directly vs having to buffer them up in a buffer.


--- bill

[No problem, it is actually quite good.]

Hy Bill, first of all please excuse my poor english.
No problem, it is actually quite good.

So i have checked the vee voltage and its around -5v
That is good. It means the Vee power supply is still working.

 and i am not sure i understand what you mean with white pixels on dark background.
Some displays have black pixels on a green/yellow background and some have white pixels
on a dark blue background. I'm assuming yours is white pixels on a blue background.
I was mainly asking to see if the background was lighting up blue

The display blacklight is working i run the diag sketch (output below) but i simply cannot see any output on the display, even if i turn the pot full on each way.
Ok, it is good that the backlight is working.

Code:

Serial initialized
--------------------------------------------------------------------
Reported Arduino Revision: 1.2
--------------------------------------------------------------------
GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
GLCD Lib build date: Mon Dec  5 01:50:07 CST 2011
GLCD Lib build number: 442
Panel Configuration:ks0108
Pin Configuration:ks0108-Sanguino
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
 CSEL1:15(PIN_D7) CSEL2:18(PIN_C2)
 RW:13(PIN_D5) DI:12(PIN_D4) EN:14(PIN_D6)
 D0:19(PIN_C3) D1:20(PIN_C4) D2:21(PIN_C5) D3:22(PIN_C6)
 D4:23(PIN_C7) D5:24(PIN_A7) D6:25(PIN_A6) D7:26(PIN_A5)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(15,0x1, 18,0x0) CHIP1:(15,0x0, 18,0x1)
Data mode:
 d0-d3:bit i/o
 d4-d7:bit i/o
--------------------------------------------------------------------
Diag Loop: 1
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
 Verify error: (84,0) D4!=2B
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): 13.60
--------------------------------------------------------------------
Reported Arduino Revision: 1.2

Ah, I see you are using Sanguino with a 644 part. Interesting.
Were you using Sanguino when it was previously working?
The reason that I ask is that there are multiple 644 boards and Arduino cores out there
with different pinouts/pin mappings. I've not updated the library
to automatically detect which core & mappings are being used.
Also, since I don't have a any of these boards, I've not done
any testing on them so the 644 has had very little testing.

Another thing I noticed is that although diags reported that
it passed, the tests actually did not pass.
Notice the Verify error on the horizontal page test.
You have discovered a bug in the diag program.
Thank You. This is a very good discovery!
I have corrected this bug in diags for the next release.
To fix it in yours.
Go into the diag sketch, and look for this:

Code:

  while(sval++ != eval);
  return(0);

And change it to this:

Code:

  while(sval++ != eval);
  return(errors);

This is in the code twice, so make sure to fix both of them.

The error you have appears to be intermittent.
i.e. it only occasionally fails.
In your case there was one error on the horizontal page test out of thousands of checks.
These kinds of errors are quite rare.
They can be due to wires being too long or having slight connection
problems from things like a bad solder joint, wires not making good connection
in a breadboard or header socket, or wires being twisted together vs soldered.

Check all your wires and make sure they are all making good contact.

Can you try correcting the diag bug and run the diags again for a couple
of loops to see if the problem persists or is consistent.
Also, could you post a couple of clear closeup photos of your board
and lcd wiring and then 1 of everything (board, wiring and lcd module)
so I can take a look at what you have?

--- bill

  sprintf(s,"ABC%c%c%c,abc%c%c%c.", 1, 2, 3, 4, 225, 239); // "ABCÅÄÖ,abcåäö"
  lcd.print(s);
}
(I skipped position 0 in order to be able to use sprintf() without null-terminating the string.)

I think you are misunderstanding how sprintf() works.
sprintf() does not alter the actual format string.
It generates its output on the fly based on the format string and input values.
So if you use a 0, as a input value parameter, it will not alter the actual format string to have a null in it.
0 will work just fine.

That said, you may run into an issue with the Arduino Print class
when using 0 as a naked constant when doing something like:
lcd.write(0);
This is because in C/C++ a naked 0 is an ambiguous type and the Arduino team did
not properly define the Print class to allow lcd.write(0);
to work.
You can either go modify their Print class code or cast the naked 0 to work:
lcd.write((uint8_t)0);

Alternatively, if you don't use a naked constant 0 and use a variable, it will work
with their existing Print class definition.
for example:

Code:

uint8_t CustomChar;

CustomChar = 0;
lcd.write(CustomChar);