v3 dec 2011 GLCD on 1284p with Arduino 1.0

Right here we go :slight_smile:

Installed latest version of the ManiacBug 1284P stuff and ......

Restarted IDE.

I was given a choice of lots of new 1284P options and chose the first one "Mighty 1284P 16MHz with Optiboot"

Re-programmed the bootloader using AVR ISP Mk2

Uploaded my sketch and no difference so....

Tried GLCDdiag and...... it compiles now !!

Here is the output:

Walking 1s data test
 Compare error: 0 != 1
 Compare error: 0 != 2
 Compare error: 0 != 4
 Compare error: 0 != 8
 Compare error: 0 != 10
 Compare error: 0 != 20
 Compare error: 0 != 40
 Compare error: 0 != 80
TEST FAILED
--------------------------------------------------------------------
Reported Arduino Revision: 1.0
--------------------------------------------------------------------
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:8(PIN_D0) CSEL2:9(PIN_D1)
 RW:10(PIN_D2) DI:11(PIN_D3) EN:12(PIN_D4)
 D0:0(PIN_B0) D1:1(PIN_B1) D2:2(PIN_B2) D3:3(PIN_B3)
 D4:4(PIN_B4) D5:5(PIN_B5) D6:6(PIN_B6) D7:7(PIN_B7)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(8,0x1, 9,0x0) CHIP1:(8,0x0, 9,0x1)
Data mode: byte
--------------------------------------------------------------------
Diag Loop: 2

I'm not sure that I have the right pin outs now.

It looks like it is NEARLY ready to go....

There is absolutely no display but I have LEDs on ports 0-7 and these are flashing with the diag sketch whilst the LCD is flickering slightly. It just looks like the control lines are mixed up

Next update...

Whilst running diag:

Data lines have LEDs and these flash in turn

Connecting an LED across the data pins gives this result.

pin 8 = CSEL1 - flashes
pin 9 = CSEL2 - flashes
pin 10 = RW - flashes
pin 11 = DI - flashes
pin 12 = EN - flashes

When I started the above a couple of pins didn't seem to be working but when I disconnected the LCD from that pin and connected the LED it did work so all flashing and no other outputs are changing at all.

%99+ of all issues getting the glcd up and working is simple wiring errors.
Often it is the control and data wiring, but another common error
is the potentiometer wiring. And occasionally the wrong data sheet
is used and nearly everything is wrong which can cause the power
connections to be wrong.
(Wrong power connections or severely incorrect pot wiring can instantly
damage a glcd module)

There is no need to use anything but the diag output at this point.
(no need to hook up leds, scope, analyzer etc...)
Everything you need can be determined from the diag output.

There are two potential issues here.

  • Arduino Pin mapping.
  • glcd to AVR wiring.

You should ensure that the pin mapping is correct first.
Look at the diag output and each pin.
You will see an Arduino pin # followed by an AVR port/pin in PIN_Pb format
where P is the port and b is the bit.
Verify that each Arduino pin # is being properly mapped to the correct AVR port and bit #
for the processor you are using.

Then look at the output and make sure that your wiring matches the printout.
You are currently using port D for the control lines and B for the data lines.
Just make sure you have wired up the glcd the way diags reports.
The reported arduino pin #s are irrelevant with respect to getting the wiring correct.
All that mattes is the PIN_Pb values. So look at those and make sure
you have wired up each glcd pin function to the specified AVR port and pin
reported by diags.

So my guess at this point is that your glcd wiring does not match
the pin connections that the diag sketch is reporting or
the potentiometer is wired incorrectly creating a short,
or the incorrect datasheet was used to determine the glcd pin connections.


The way the mapping works, even if the Arduino pin mapping is wrong, glcd always
still uses what it reports in the PIN_Pb values.

So if say pin 24 should map to PORTA bit 0 but instead was incorrectly mapped to PORTA bit 7,
and glcd diags reports PIN_A7, then PORT A bit 7 is the exact port and bit being used by the library.

So in the end all that really matters is that the glcd wiring matches the PIN_Pb pins reported
by the diag sketch. The Arduino pin mapping only affects how the pin numbers you specify
in the the glcd pin configuration files get mapped to AVR ports and pins.
glcd does not use any Arduino or core code to access pins.
It simply uses a pin mapping to get some information (if pins are specified using Arduino pin #s),
Then, it runs as fast as possible away from anything Arduino and uses the Atmel information
and raw port access to do everything.

If you want 100% certainty and avoid any/all the Arduino pin number BS/non-sense, then
you can always use PIN_Pb format to specify your pins in the glcd configuration files.
When using PIN_Pb format, glcd uses none of the Arduino supplied or core provided files
for any of the pin mapping. It uses only the atmel supplied header files.

For example, instead of using Arduino pin 0 on a 1284P, you could use PIN_B0 to specify the pin
on PORT B bit 0.

--- bill

Thanks for the reply, will look at it when I get home.

I know the data pins are right because my board design has 8 LEDs on that port and you can see GLCDdiag turning them on in sequences.

It has to be the control lines or software!

cowasaki:
Thanks for the reply, will look at it when I get home.

I know the data pins are right because my board design has 8 LEDs on that port and you can see GLCDdiag turning them on in sequences.

It has to be the control lines or software!

It is unlikely to be software.
There has never been any issues with the low level i/o in glcd.
(Even as far back as the early betas 2 years ago)
The low level logic and Arduino pin mapping code is the same no matter which AVR processor is used.
There have been a few issues when people have tried to add their own
pin mappings for new processors, (like early on for the mega2560)
but that isn't an issue with the glcd software or with the low level i/o.
It is a pin mapping issue and is immediately obvious from looking at the diag output.

glcd does not use any Arduino code or core code to talk to the pins
so there isn't really anything in the way once the correct mapping is in place.

It still could be a data wiring issue. Say if the glcd is mis identified
and the wrong glcd pinout is used. Then while the glcd software is using the correct
pins on the AVR for the glcd data lines, the AVR pins are not connected to
to the proper pins on the glcd.

A terribly mis-wired contrast pot can also cause problems.

In 2+ years I've only seen two cases where the problem wasn't
a wiring issue. In those cases, it was bad glcd modules.
But both of those bad glcds were actually do to miswiring.
One was due to mis-wiring power pins, and the other by mis-wiring the pot.

Common causes of mis wiring are incorrect glcd pinout (using wrong data sheet).
mis reading the pins on the Arduino board - common on Arduino mega boards.
getting the glcd pins backwards. (Mis identifying pin 1).
Occasionally people get RST and RS confused so they end up hooking
up the DI pin to the glcd RESET pin and tying RS to Arduino RESET, or some other AVR pin.

Occasionally people mis wire glcd RST (reset line) and tie it to gnd rather than VCC
which holds the glcd in reset.

--- bill

bperrybap:

cowasaki:
Thanks for the reply, will look at it when I get home.

I know the data pins are right because my board design has 8 LEDs on that port and you can see GLCDdiag turning them on in sequences.

It has to be the control lines or software!

It is unlikely to be software.
There has never been any issues with the low level i/o in glcd.
(Even as far back as the early betas 2 years ago)

--- bill

That's good to here, thanks.

Well the data lines really do look correct. Having run GLCDdiag on a 1280 with the same GLCD (so I know it works :)) I am recognising the shape of the graphics that did go on the display appearing on the LEDs. So its down to the control lines. Also if the control lines WERE ok and the data faulty then I think that GLCDdiag would probably find that.

Anyway I will continue to work it out.......

If there was some way of making CSEL1 go pulse on and off whilst every other line was held low then CSEL2 then DI etc it would be an easy task to trace it.

If you want a second set of eyes to look it over,
post a photo of the back of the GLCD so I can see the part number
then get a clear photo of the wiring.

And I'll see if I can spot anything.

It is pretty unusual get past the RESET/BUSY test in initialization if the wiring is wrong.
Normally that fails and the diags don't even make it to the walking 1s data test.

It kind of looks like the AVR is reading nothing but 0 on the data bus.
This can happen if the glcd module is being held in reset.

--- bill

Ok....

To avoid any confusion and so that any assumptions I have made are obvious I am including all the information I am using in order to allow people to post a reply

Pin outs for 1284P (as per Maniac Bug's page - this is the bootloader etc I am using)

Info leg +---/---+ leg Info
(D 0) PB0 1 ---------
(D 1) PB1 2 ---------
INT2 (D 2) PB2 3 ---------
PWM (D 3) PB3 4 ---------
PWM/SS (D 4) PB4 5 ---------
MOSI (D 5) PB5 6 ---------
PWM/MISO (D 6) PB6 7 ---------
PWN/SCK (D 7) PB7 8 ---------
RST 9 ---------
VCC 10 ---------
GND 11 ---------
XTAL2 12 ---------
XTAL1 13 ---------
RX0 (D 8 ) PD0 14 ---------
TX0 (D 9) PD1 15 ---------
RX1 (D 10) PD2 16 ---------
RX1 (D 11) PD3 17 ---------
PWM (D 12) PD4 18 ---------
PWM (D 13) PD5 19 ---------
PWM (D 14) PD6 20 ---------

Config file

(note the slight change from earlier as I was using port B for data and port D for control but PD0 & PD1 are RX0 & TX0 so moved to port C)

/*
 * ks0108_Sanguino.h - ATmega644 specific configuration for Arduino GLCD library
 *
 * Use this file to set io pins
 *
 * The configuration below uses a single port for data 
 * and has the same wiring as the Sanguino config from the previous ks0108 library 
 *
*/

#ifndef GLCD_PIN_CONFIG_H
#define GLCD_PIN_CONFIG_H

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

/*********************************************************/
/*  Configuration for assigning LCD bits to Arduino Pins */
/*********************************************************/
/*
 * pins used for Commands
 */

#define glcdCSEL1    18     // CS1 Bit   // swap pin assignments with CSEL2 if left/right image is reversed
#define glcdCSEL2    19     // CS2 Bit
#define glcdRW       20   // R/W Bit
#define glcdDI       21     // D/I Bit 
#define glcdEN       22     // EN Bit

#if NBR_CHIP_SELECT_PINS > 2
#define glcdCSEL3    23   // third chip select if needed
#endif

#if NBR_CHIP_SELECT_PINS > 3
#define glcdCSEL4    22   // fourth chip select if needed
#endif

/*
 * Data pin definitions
 * This version uses pins 0-7 for LCD Data 
 */
#define glcdData0Pin    0
#define glcdData1Pin    1
#define glcdData2Pin    2
#define glcdData3Pin    3
#define glcdData4Pin    4
#define glcdData5Pin    5
#define glcdData6Pin    6
#define glcdData7Pin    7


#endif //GLCD_PANEL_CONFIG_H

CURRENT GLCDdiag output

--------------------------------------------------------------------
Reported Arduino Revision: 1.0
--------------------------------------------------------------------
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:18(PIN_C2) CSEL2:19(PIN_C3)
 RW:20(PIN_C4) DI:21(PIN_C5) EN:22(PIN_C6)
 D0:0(PIN_B0) D1:1(PIN_B1) D2:2(PIN_B2) D3:3(PIN_B3)
 D4:4(PIN_B4) D5:5(PIN_B5) D6:6(PIN_B6) D7:7(PIN_B7)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(18,0x1, 19,0x0) CHIP1:(18,0x0, 19,0x1)
Data mode: byte
--------------------------------------------------------------------
Diag Loop: 2
Initializing GLCD
GLCD initialization Failed: BUSY wait Timeout (status code: 1)
--------------------------------------------------------------------

These are my connections:

GLCD Arduino/Pot/Res Colour line
1 na na Ground
2 na na VCC
3 Centre of 10K pot green Contrast
4 21 (leg 27) white DI
5 20 (leg 26) blue R/W
6 22 (leg 28) orange EN
7 0 (leg 1) orange Data 0
8 1 (leg 2) blue Data 1
9 2 (leg 3) green Data 2
10 3 (leg 4) white Data 3
11 4 (leg 5) blue Data 4
12 5 (leg 6) orange Data 5
13 6 (leg 7) white Data 6
14 7 (leg 8 ) orange Data 7
15 18 (leg 24) yellow CSEL0
16 19 (leg 25) green CSEL1
17 N/C na RESET
18 Right of Pot white Contrast
19 330 ohm to VCC na Backlight
20 na black Backlight GND
  • left of pot to ground (black)

Pictures of my setup as it is currently:

The GLCD 12864J-4 displays I am using

The contrast pot

The display works on a 1280 shield I made

The whole setup (done prior to installing the 8 way data lead and moving the control lines)

Close-ups

and one with the LCD removed, just so that it is more clear.


This is my current position. GLCDdiag is running now and I can see the string of LEDs lighting up in sequence but nothing is on the screen.
I did have a fault this morning with it using an old config file for the 1284P but sorted that now.

I have also tried connecting the reset on the panel (pin 17) to the reset on the Arduino but this has not effect.

I have also tried connecting the contrast control as - GLCD pin 3 going to the opposite side of the pot to GND and GLCD pin 18 going to the sweep as I have seen on some other pages but it had no effect other than swapping the direction of the contrast control so I reverted to the normal setup. If I adjust the contrast all the way I can see the pixels.

I have also tested the continuity of all the control lines from the 1284p legs to the GLCD pads and they all are ok.

I have also now made an 8 way pin to pin data bus which replaced the 8 separate wires for the data and tested the continuity from the 1284P's legs to the pads on the GLCD and this is also ok.

Tested the 5 control lines whilst GLCDdiag is running using an LED and all 5 lines pulse at various points.

Wow.
That has to be by far the best information I've seen for helping diagnose a glcd problem.
It will take a little bit to review it, but there is definitely enough information here
to figure out what the issue is.

A quick note on your glcd pinout -
you didn't mention that you had two different displays.

--- bill

bperrybap:
Wow.
That has to be by far the best information I've seen for helping diagnose a glcd problem.
It will take a little bit to review it, but there is definitely enough information here
to figure out what the issue is.

A quick note on your glcd pinout -
you didn't mention that you had two different displays.

--- bill

I have a box load of different displays as I bought a job lot from China. Most are normal LCDs but I thought that both of these were standard type B displays. I hope I am right or that might explain some things. I will just double check now......

I thought that I would give you every bit of information that I possibly could in order to make sure that it was possible to find the answer :slight_smile:

Just checked the data sheets and they are both type B GLCDs {I got rid of the others :)}

01 - VSS
02 - VDD
03 - V0
04 - D/I
05 - R/W
06 - E
07 - 0
08 - 1
09 - 2
10 - 3
11 - 4
12 - 5
13 - 6
14 - 7
15 - CS1
16 - CS2
17 - RST
18 - VEE
19 - LED+
20 - LED-

Just starting to look at it.
One thing I noticed right off the bat is the reset line. glcd pin 17.
On most glcds you cannot leave that disconnected.
It must be high for normal operation. On some glcds you can simply tie it to vcc.
Others need a pulse on it to reset the module to a sane state
thats why it is often connected to the Arduino reset line.

For now the best would be to allow the glcd library to control it.
You can do that by using another AVR pin.
You need to create a define for glcdRES in the pin configuration file.
(I just noticed that the Sanguino pin configuration does not have a sample entry
that is commented out for this like all the other pin config files. I'll get the fixed for the next release).
Just add the define and let the glcd library control it.

A quick note on the pot.
The pot should be hooked up as:

leg ---- GND (or VCC) doesn't really matter
wiper --------------------------------------------------------------------- Vo/Contrast
leg ----- Vee

The pot acts as voltage divider between the negative voltage of Vee and gnd/vcc.
The actual voltage needed to set the pixels is usually slightly negative but under
extreme temperatures it may need to be slight above ground and that is why
you may seem some variation on where one of the legs is hooked.
At room temperature gnd or vcc can be used. Using gnd will waste slightly less power.


Now for the BIGGIE.......

It looks to me like all 20 glcd pins in the bread board setup are wired backwards. DOH!
i.e. pin 20 should be on the left and pin 1 is on the right.
The wiring on the shield looks ok as I can see the current limiting
resistor on pin 19 (second pin on from the left) but in the breadboard setup all the glcd connections
appear to be reversed.

It's usually the simple stuff that trips things up.
Thats where the 2nd pair of eyes helps.

--- bill

bperrybap:
Just starting to look at it.
One thing I noticed right off the bat is the reset line. glcd pin 17.
On most glcds you cannot leave that disconnected.
It must be high for normal operation. On some glcds you can simply tie it to vcc.
Others need a pulse on it to reset the module to a sane state
thats why it is often connected to the Arduino reset line.

For now the best would be to allow the glcd library to control it.
You can do that by using another AVR pin.
You need to create a define for glcdRES in the pin configuration file.
(I just noticed that the Sanguino pin configuration does not have a sample entry
that is commented out for this like all the other pin config files. I'll get the fixed for the next release).
Just add the define and let the glcd library control it.

A quick note on the pot.
The pot should be hooked up as:

leg ---- GND (or VCC) doesn't really matter
wiper --------------------------------------------------------------------- Vo/Contrast
leg ----- Vee

The pot acts as voltage divider between the negative voltage of Vee and gnd/vcc.
The actual voltage needed to set the pixels is usually slightly negative but under
extreme temperatures it may need to be slight above ground and that is why
you may seem some variation on where one of the legs is hooked.
At room temperature gnd or vcc can be used. Using gnd will waste slightly less power.


Now for the BIGGIE.......

It looks to me like all 20 glcd pins in the bread board setup are wired backwards. DOH!
i.e. pin 20 should be on the left and pin 1 is on the right.
The wiring on the shield looks ok as I can see the current limiting
resistor on pin 19 (second pin on from the left) but in the breadboard setup all the glcd connections
appear to be reversed.

It's usually the simple stuff that trips things up.
Thats where the 2nd pair of eyes helps.

--- bill

I've built at least 4 devices with GLCDs and they've all worked straight off, never had a problem before.

I can't believe I had the entire connector wired backwards {sorry need a screaming smilie}

Yes it really does help having a second set of eyes and also having all the information to hand. I'm a mod on a photography forum and you would be amazed how many questions we get with "Whats wrong with this image" and they've shrunk it and removed all the EXIF data. I was trying to do the opposite by giving you a complete information overload.

I have never had to do anything with the reset line yet but will look at that once I have reversed the reversed wiring.

Seriously thanks for taking the time, I will report back shortly.

THANK YOU. IT IS NOW WORKING.

I did add the reset control line in but once it was working I pulled it and restarted and it is still working so luckily it's one of those that didn't need it.

I am well pleased now......

There is still the issue of how to handle the different Arduino pin mappings for the different
mighty-1284p variants.

It is critical that code that does pin mapping know the specifics of the target being built
and today that simply is not possible because the core and variant information is not
available to the code being compiled.

As example, the code I have in the glcd library that updates the 8 data pins
talking to the glcd is 800X faster updating the 8 pins
when it can use an 8 bit port access vs having
to use 8 individual digitalWrite() operations.
While setting the AVR pins to talk to the glcd is only a portion of the overall overhead
it is still very noticeable in that it can lower the overall performance by as much 20x
which is very noticeable when trying to do rapid updates to the glcd.

The only way to do these kinds of optimizations is to
detect this at compile time is by having a mapping table
and the only way to have a proper mapping table is to know which core and variant
you are building.

Maybe you can push on the mighty-1284p code maintainers about the need
for this kind of information for i/o intensive libraries.

---- bill

bperrybap:
There is still the issue of how to handle the different Arduino pin mappings for the different
mighty-1284p variants.

It is critical that code that does pin mapping know the specifics of the target being built
and today that simply is not possible because the core and variant information is not
available to the code being compiled.

As example, the code I have in the glcd library that updates the 8 data pins
talking to the glcd is 800X faster updating the 8 pins
when it can use an 8 bit port access vs having
to use 8 individual digitalWrite() operations.
While setting the AVR pins to talk to the glcd is only a portion of the overall overhead
it is still very noticeable in that it can lower the overall performance by as much 20x
which is very noticeable when trying to do rapid updates to the glcd.

The only way to do these kinds of optimizations is to
detect this at compile time is by having a mapping table
and the only way to have a proper mapping table is to know which core and variant
you are building.

Maybe you can push on the mighty-1284p code maintainers about the need
for this kind of information for i/o intensive libraries.

---- bill

ManiacBug is talking about the 1284P becoming part of the main Arudino build so hopefully we will get a standardisation then and a system that stops a lot of the issues. GLCD working is just one of a few issues I was having along with uploading of sketching via serial FTDI and SDA/SLA comms with RTC etc. I can see Bob's call for using the same pins in order to get shield compatibility but at the moment I think there are maybe 4 or 5 alternatives. If the 1284P is not accepted into the standard core soon it is likely it will be too late as lots of hardware is built along the opposing standards.

I will post about this too, the 1284P is too good a chip to go to waste.

I hadn't really looked much at the "Sanguino" until now.
I really like the 1284P. That is a nice chip. It is WAY better than a m328, which
I never really liked because of the way Atmel assigned the pins.
You can't get an 8 bit port out of it if you want to use a crystal and the serial port.

As far as Arduino pin # mapping goes for 644/1284P and support in the glcd library.
It is possible to tell the difference between the 3 variants in the mighty-1284p core.
It is VERY ugly but it can be done.

You can look at the result of analogInputToDigitalPin(0)
If it is 31 then you using the "avr_developers" pin mapping.
If it is 24 then you are using the "standard" pin mapping.
If it is 21 then you are using the "bobduino" pin mapping.

While I prefer the "standard" variant pin mapping and wish the others would go away,
I'll add all three when I add in 1284p support to the glcd library.
It will make for long pin mapping macro, since it has to handle all three variants
but it is easy to do.

And while this can be done, I still want say VERY LOUDLY, that there needs to be
a consistent way for the board, core, and variant to be known at compile time
by the code being compiled.

--- bill

Hello all,

In my zeal to use the 1284P with a "type B" GLCD (JHD12864E), I have made this board.

Can anyone please review this and comment / suggest changes?

However, please note, because of size constraints, the PCB can be only 4"(W) x 3"(H).

Thanks,
Madhu.

1284p with GLCD.sch (1.18 MB)

1284p with GLCD.brd (153 KB)

All,

As much as I hate to do this, Please comment and post your suggestions.

thanks,
madhu.