next topic »

[Reply #15 on:]

I'm not sure why they originally mapped digital pins 24-31 backwards on PORT A.

I suspect it was more for ease of the trace layout for the PCB. The original Sanguino was a pretty compact PCB, and being the first to port a 644 to the arduino platform they really didn't have any rules or examples to have to go by I would think?

 The whole arduino idea of abstracting I/O pin numbers has always been a two headed coin, with  a classic performance Vs ease of use trade-off.

I do hope this all has a happy ending as I'm looking forward to populating my soon to own 1284TH board that Bob created. He seems to be having difficulty at the moment getting a functioning bootloader to work.

Well that doesn't make sense to me. The arduino pin to AVR port/bit mappings can be arbitrary so it really should
be totally unrelated to a any particular board layout.
I can understand flipping the traces going to a header on a board layout as they go to a header
to allow an inverted set of pins with respect to the port,
but I still don't understand the need to reverse the arduino pin number ordering from the other 3 ports.

I'm sure it will be working in short order.
The diag sketch code using 1284P compiles just fine for me with Arduino 1.0.
But I'm not using Windoze.

My suspicion is that since cowasaki is not seeing a string of warnings related to progmem when he compiles
on his Windoze machine,
that the Arduino 1.0 release for linux is different than the Windows version.
And perhaps somebody dinked with the PROGMEM definition on the windows version
to remove the warnings which can break certain uses of PROGMEM.

I'm about to try running 1.0 on a doze to see how it works with glcd diag there.

--- bill

[Reply #16 on:]

Well, I'm not sure where to go now.
I downloaded a fresh Arduino 1.0 for windows, a fresh glcd v3 RC3 library, and a fresh version
of maniacbugs Sanguino package.
After two minor edits for 1284P support (glcd/include/arduino_io.h and glcd/config/ks0108_Panel.h)
the glcd diag sketch compiles fine with XP.

I can't test it as I don't have a 1284P/Sanguino setup.

When verbose mode is turned on there are lots of warnings though.

The binary created on linux is 32 bytes smaller than the one on XP.
Not sure if the compilers are the same revisions since the linux Arduino package
does not include the compiler tools.


--- bill

[Reply #17 on:]

ok,
There is lots of recent stuff going on in maniabug mighty-1284p git repository.
From things like re-ordering pins (especially the analog pins)
to modifying progmem definitions.

These have the potential to break things like the glcd library.

Looks to me like if your 1284P hardware package is older than 3 days that you should
get a fresh copy.
Then to avoid the pin mapping issue with the other/older Sanguino support packages
stay away from using PORT A. (Arduino digital pins 24-31) at least until you get the
glcd up and working.

--- bill

[Reply #18 on:]

Hmm.....  Who said anything about Windows ???  I'm running a Mac   I only use a Windows machine for AVR Studio for bootloading with the AVR ISP Mk2

I had not tried changing the numbers in the Sanguino and will try that today.

The bootloader and software I am using is weeks old, am I best updating this?

[Reply #19 on:]

Hmm.....  Who said anything about Windows ???  I'm running a Mac   I only use a Windows machine for AVR Studio for bootloading with the AVR ISP Mk2

My bad there. I just saw the spaces in the paths and assumed windows.
(spaces are a really bad thing in names...)

I had not tried changing the numbers in the Sanguino and will try that today.

But the first priority still needs to be to get the diag sketch compiling.

The bootloader and software I am using is weeks old, am I best updating this?

I definitely say yes, so we are all looking at the same code.
Plus, there have been many changes around the mapping of pins in the A PORT
and with respect to progmem re-declarations since then.

--- bill

[Reply #20 on:]

Hmm.....  Who said anything about Windows ???  I'm running a Mac   I only use a Windows machine for AVR Studio for bootloading with the AVR ISP Mk2

My bad there. I just saw the spaces in the paths and assumed windows.
(spaces are a really bad thing in names...)

I had not tried changing the numbers in the Sanguino and will try that today.

But the first priority still needs to be to get the diag sketch compiling.

The bootloader and software I am using is weeks old, am I best updating this?

I definitely say yes, so we are all looking at the same code.
Plus, there have been many changes around the mapping of pins in the A PORT
and with respect to progmem re-declarations since then.

--- bill

Right well I've built it on a new breadboard as the old one was a little wobbly - no effect

Changed the pin outs so they run on from the data lines:



#define glcdCSEL1   8 // 24     // CS1 Bit   // swap pin assignments with CSEL2 if left/right image is reversed
#define glcdCSEL2   9 // 25     // CS2 Bit
#define glcdRW      10 // 26     // R/W Bit
#define glcdDI      11 // 27     // D/I Bit
#define glcdEN      12 // 28     // EN Bit

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

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

#define glcdData0Pin    0
#define glcdData1Pin    1
#define glcdData2Pin    2
#define glcdData3Pin    3
#define glcdData4Pin    4
#define glcdData5Pin    5
#define glcdData6Pin    6
#define glcdData7Pin    7

I have used another 1284P and re-programmed the bootloader using the AVR ISP Mk2 - something I could not do before Arduino v1.0

GLCDdiag still does not compile at all

Next job is to install the newest 1284P Maniac code....

[Reply #21 on:]

Right here we go

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:

Code:

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.

[Reply #22 on:]

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

[Reply #23 on:]

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.

[Reply #24 on:]

%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

[Reply #25 on:]

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!

[Reply #26 on:]

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

[Reply #27 on:]

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.

[Reply #28 on:]

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

[Reply #29 on:]

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	|---------|	40	PA0 (AI 0 / D24)
(D 1) PB1	2	|---------|	39	PA1 (AI 1 / D25)
INT2 (D 2) PB2	3	|---------|	38	PA2 (AI 2 / D26)
PWM (D 3) PB3	4	|---------|	37	PA3 (AI 3 / D27)
PWM/SS (D 4) PB4	5	|---------|	36	PA4 (AI 4 / D28)
MOSI (D 5) PB5	6	|---------|	35	PA5 (AI 5 / D29)
PWM/MISO (D 6) PB6	7	|---------|	34	PA6 (AI 6 / D30)
PWN/SCK (D 7) PB7	8	|---------|	33	PA7 (AI 7 / D31)
RST	9	|---------|	32	AREF
VCC	10	|---------|	31	GND
GND	11	|---------|	30	AVCC
XTAL2	12	|---------|	29	(D 23) PC7
XTAL1	13	|---------|	28	(D 22) PC6
RX0 (D 8 ) PD0	14	|---------|	27	TDI (D 21) PC5
TX0 (D 9) PD1	15	|---------|	26	TDO (D 20) PC4
RX1 (D 10) PD2	16	|---------|	25	TMS (D 19) PC3
RX1 (D 11) PD3	17	|---------|	24	TCK (D 18) PC2
PWM (D 12) PD4	18	|---------|	23	SDA (D 17) PC1
PWM (D 13) PD5	19	|---------|	22	SCL (D 16) PC0
PWM (D 14) PD6	20	|---------|	21	PWM (D 15)

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)

Code:

/*
 * 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

Code:

--------------------------------------------------------------------
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.