v3 dec 2011 GLCD on 1284p with Arduino 1.0

Has anyone got the above working?

I wrote a quick program which tested and worked on the 1280 then switched to the 1284p. The program is running because it sends serial data back to the IDE and flashes an LED.

I am using a type B GCLD as per Arduino Playground - GLCDks0108

I am using the chip pin outs as per the file ks0108_Sanguino.h ie:

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

#if NBR_CHIP_SELECT_PINS > 2
#define glcdCSEL3    29   // third 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 changed the file "arduino_io.h"

#elif defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega1284__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644P__)  
// Sanguino or other ATmega664/1284 controller
#define digitalPinToPortReg(P) \
    (((P) >= 0 && (P) <= 7)   ? &PORTB : \
	(((P) >= 8 && (P) <= 15)  ? &PORTD : \
 	(((P) >= 16 && (P) <= 23) ? &PORTC : &PORTA)))
#define digitalPinToBit(P) \
     (((P) >= 0 && (P) <= 23) ? (P%8) : (7-(P%8)) )
//#error "ATmega664 has not been tested"
#else	
#error "Arduino pin mapping not defined for this board"
#endif

Changing the above file stopped the compiler falling out with the error "Arduino pin mapping not defined for this board" and sets the definitions above as per 644p which is included (the 1284p in pin compatible).

Now I suspect it is not working as I am missing something which calls the file "ks0108_Sanguino.h" when it detects a 644p (which it isn't because I'm using a 1284p) but as yet I have not been able to trace it.

Also tried changed the part of ks0108_Panel.h that selects the pin outs

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
#include "config/ks0108_Mega.h"      // config for mega 1280/2560 board
#elif defined(__AVR_ATmega644P__)  || defined(__AVR_ATmega644__)   || defined(__AVR_ATmega1284__)   || defined(__AVR_ATmega1284P__)           
#include "config/ks0108_Sanguino.h"  // config for Sanguino or other ATmega644/p board
#elif defined(__AVR_AT90USB646__) || defined(__AVR_AT90USB1286__) || defined(__AVR_ATmega32U4__)// Teensy
#include "config/ks0108_Teensy.h"    // config for Teensy and Teensy++  
#else
#include "config/ks0108_Arduino.h"   // config file for standard Arduino using documented wiring 
#endif

The processor type is controlled which board you select, which is
controlled by the boards.txt file under {arduino_installdir}/hardware

So you are saying that your glcd sketch worked on the 1280 and when you swapped out the 1280 chip
for a 1284 chip it no longer works?

I have not looked at the Arduino pin mapping for the 1284/1284p but
If the 1284 pin mapping is exactly the same as the 644 then what you did should work.
(It looks like you cloned the 644 pin mappings for your 664 and 1284 pin mappings)

Getting the pin mapping correct (it must match what the core code uses)
is critical as the glcd library does not use the Arduino core functions
like digitalWrite()/digitalRead() as they are too slow.

The best way to diagnose this is to run the diag sketch and see what pins the library is using.
Look at the serial output and you will see the port and bit numbers being used for each pin
in the configuration file.
If they don't match the port and bit numbers for the Arduino pin on a 1284 (or whatever AVR you are using)
then the pin mapping you created is incorrect.

The diag serial output will show everything that is needed to diagnose any potential
pin mapping issues.

--- bill

The 664P is totally pin compatible with the 1284P. I attached it as per the pin connections shown in post 1.

I ran a for/next loop through pins 0-31 to get their location on the 1284P

glcdData0Pin 0 = 1284P pin 1
glcdData1Pin 1 = 1284P pin 2
glcdData2Pin 2 = 1284P pin 3
glcdData3Pin 3 = 1284P pin 4
glcdData4Pin 4 = 1284P pin 5
glcdData5Pin 5 = 1284P pin 6
glcdData6Pin 6 = 1284P pin 7
glcdData6Pin 7 = 1284P pin 8

glcdCSEL3 29 = 1284P pin 35
glcdEN 28 = 1284P pin 34
glcdDI 27 = 1284P pin 33
glcdRW 26 = 1284P pin 32
glcdCSEL2 25 = 1284P pin 31
glcdCSEL1 24 = 1284P pin 30

At the moment the screen just lights up but nothing happens after that.

If I try and run the GLCD diag program it will not compile but returns this error:

libraries/glcd/fonts/SystemFont5x7.h:48: error: System5x7 causes a section type conflict

BUT

THAT file is included with the files that are used when I compile for the GLCD test which compiles fine !

Re-running the same program on a 1280 works without issue......

I'm still not quite sure about the different processor types you are trying to use.
It sounds like you may have some processor type issues in your core code or boards.txt files that need to
be resolved as well. 664 vs 644 vs 1284 ?

The 664P is totally pin compatible with the 1284P. I attached it as per the pin connections shown in post 1.

The questions isn't whether the 664P and 1284P are pin compatible with each other, it is whether
the Arduino pin to port/bit mappings of the 664, 664P, 1284, and 1284P are the same as the Arduino pin
to port/bit mappings of the 644/644P since the mappings you added for 664/664P/1284/1284P processors matches the
original 644/644P mappings.

Also, the way you edited the files, if you use a 664 or 664P chip you get the
Arduino pin mappings you defined but you will use the glcd pin configuration file
which is normally used for the standard arduino board (ks0108_Arduino.h) and not the glcd pin configuration file for
Sanguino (ks0108_Sanguino.h) while the 1284/1284P will use the Sanguino glcd pin configuration file (ks0108_Sanguino.h)

(That does and can be made to work, but it seems very odd to do it that way)

And the glcd library will no longer compile with a 644 or 644P.

I ran a for/next loop through pins 0-31 to get their location on the 1284P

glcdData0Pin 0 = 1284P pin 1
glcdData1Pin 1 = 1284P pin 2
glcdData2Pin 2 = 1284P pin 3
glcdData3Pin 3 = 1284P pin 4
glcdData4Pin 4 = 1284P pin 5
glcdData5Pin 5 = 1284P pin 6
glcdData6Pin 6 = 1284P pin 7
glcdData6Pin 7 = 1284P pin 8

glcdCSEL3 29 = 1284P pin 35
glcdEN 28 = 1284P pin 34
glcdDI 27 = 1284P pin 33
glcdRW 26 = 1284P pin 32
glcdCSEL2 25 = 1284P pin 31
glcdCSEL1 24 = 1284P pin 30

I'm not sure what this pin information is.

If I try and run the GLCD diag program it will not compile but returns this error:

libraries/glcd/fonts/SystemFont5x7.h:48: error: System5x7 causes a section type conflict

Are there any other errors?

.... when I compile for the GLCD test which compiles fine !

What do you mean by "the GLCD test"?

The top priority needs to be get the included diag sketch building so you can see the diagnostic output.

--- bill

bperrybap:
I'm still not quite sure about the different processor types you are trying to use.
It sounds like you may have some processor type issues in your core code or boards.txt files that need to
be resolved as well. 664 vs 644 vs 1284 ?

The 664P is totally pin compatible with the 1284P. I attached it as per the pin connections shown in post 1.

The questions isn't whether the 664P and 1284P are pin compatible with each other, it is whether
the Arduino pin to port/bit mappings of the 664, 664P, 1284, and 1284P are the same as the Arduino pin
to port/bit mappings of the 644/644P since the mappings you added for 664/664P/1284/1284P processors matches the
original 644/644P mappings.

Also, the way you edited the files, if you use a 664 or 664P chip you get the
Arduino pin mappings you defined but you will use the glcd pin configuration file
which is normally used for the standard arduino board (ks0108_Arduino.h) and not the glcd pin configuration file for
Sanguino (ks0108_Sanguino.h) while the 1284/1284P will use the Sanguino glcd pin configuration file (ks0108_Sanguino.h)

(That does and can be made to work, but it seems very odd to do it that way)

And the glcd library will no longer compile with a 644 or 644P.

I ran a for/next loop through pins 0-31 to get their location on the 1284P

glcdData0Pin 0 = 1284P pin 1
glcdData1Pin 1 = 1284P pin 2
glcdData2Pin 2 = 1284P pin 3
glcdData3Pin 3 = 1284P pin 4
glcdData4Pin 4 = 1284P pin 5
glcdData5Pin 5 = 1284P pin 6
glcdData6Pin 6 = 1284P pin 7
glcdData6Pin 7 = 1284P pin 8

glcdCSEL3 29 = 1284P pin 35
glcdEN 28 = 1284P pin 34
glcdDI 27 = 1284P pin 33
glcdRW 26 = 1284P pin 32
glcdCSEL2 25 = 1284P pin 31
glcdCSEL1 24 = 1284P pin 30

I'm not sure what this pin information is.

If I try and run the GLCD diag program it will not compile but returns this error:

libraries/glcd/fonts/SystemFont5x7.h:48: error: System5x7 causes a section type conflict

Are there any other errors?

.... when I compile for the GLCD test which compiles fine !

What do you mean by "the GLCD test"?

The top priority needs to be get the included diag sketch building so you can see the diagnostic output.

--- bill

By "the GLCD test" I meant GLCDdiag

There were no other errors when I tried to compile GLCDdiag

If the 644P is pin compatible with the 1284P and I add "or 1284P" onto the test for the 644P then it should be right! Shouldn't it?

cowasaki:
If the 644P is pin compatible with the 1284P and I add "or 1284P" onto the test for the 644P then it should be right! Shouldn't it?

Yes, but that isn't what you did.
You changed things to add 664 processor types in some places and left 644 types in others.
But I can't really tell completely what you did as you haven't shown the full arduino_io.h file you only
showed a small portion of the file.
(i.e. I can't tell if you changed the 644 to 664 and added 1284
or whether you left the 644 entry and created a new entry for the 664/1284 parts)

From the little I can see, the changes in arduino_io.h do not seem to be consistent with changes in ks0108_Panel.h
so depending on which "Sanguino" processor you define, things can be using different glcd library config
files (which probably have different Arduino pins defined) or not compile at all.

And again, it isn't about being "pin compatible", which to me implies electrical pin compatibility,
it is about how the Arduino pin numbers within the core
code for that processor are mapped to the processor ports and bits within the ports.

From looking at the Sanguino site, the processor used a 644p.
In the previous posts you mention 664 several times, which is also why I asked about the
processor types and core code.

Where are you getting your Arduino 1.0 Sanguino core code from?
The code I saw referenced on the official Sanguino site was only for Arduino 0018 or 0023.
( Google Code Archive - Long-term storage for Google Code Project Hosting. )

And it only has support for 644P and 1284P.
If you use 644, 1284, 664 or 664P the core code will default to using Arduino pin mappings
for the m328.

Or are you using some other Arduino core for your 664/1284 ?

--- bill

Sorry for any typos!

I have changed the THREE occurrences of checks for the 644 & 644P to 644, 644P, 1284P & 1284

Nothing else has been changed in the library at all.

The pin-outs that I am using came from the Sanguino config file and match those in the latest version of the GLCD manual which includes the 644

and.....?

Is the glcd diag sketch still having compile problems?
If so, post the entire command/error/warning sequence that comes to the
IDE screen when you turn on verbose output.

Which Sanguino core are you using?
Can you provide a link to the core you are using on your 1.0 Arduino?

--- bill

GLCDdiag does not compile, the status bar changes to "Error compiling." and the only report is :

/Users/....../libraries/glcd/fonts/SystemFont5x7.h:48: error: System5x7 causes a section type conflict

With verbose output turned on we get:

/Applications/Arduino v1/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega1284p -DF_CPU=16000000L -DARDUINO=100 -I/Applications/Arduino v1/Arduino.app/Contents/Resources/Java/hardware/mighty-1284p/cores/standard -I/Applications/Arduino v1/Arduino.app/Contents/Resources/Java/hardware/mighty-1284p/variants/standard -I/Users/darren/Documents/Arduino version 1/libraries/glcd /var/folders/gr/_kg3f7_1489__66thsjhwfd40000gn/T/build7583886440353136810.tmp/GLCDdiags.cpp -o/var/folders/gr/_kg3f7_1489__66thsjhwfd40000gn/T/build7583886440353136810.tmp/GLCDdiags.cpp.o
/Users/darren/Documents/Arduino version 1/libraries/glcd/fonts/SystemFont5x7.h:48: error: System5x7 causes a section type conflict
/Users/darren/Documents/Arduino version 1/libraries/glcd/include/gText.h:171: warning: 'FontRead' defined but not used

The core I am now using is the ManiacBug created one which is referred to here : Arduino on ATmega1284P | maniacbug

ok, got it.

That is very strange.

Do all the glcd library example sketches have problems building?
If you change the board in the IDE to some other board like "uno" does it work?

Have you made any patches/changes to any Arduino 1.0 files?
Any changes to the PROGMEM definition?
(There are some out there that attempt to remove C++ warnings)

I'll have to install that Sanguino software and try it later tonight to see what is going on.

--- bill

bperrybap:
ok, got it.

That is very strange.

Do all the glcd library example sketches have problems building?
If you change the board in the IDE to some other board like "uno" does it work?

Have you made any patches/changes to any Arduino 1.0 files?
Any changes to the PROGMEM definition?
(There are some out there that attempt to remove C++ warnings)

I'll have to install that Sanguino software and try it later tonight to see what is going on.

--- bill

No problems compiling any other GLCD sketches but they don't actually display anything

No changes to ANY arduino files within the program folder. We heavily modified the previous version to get it to work but when version 1.0 came out I was too busy with other things and ManiacBug had done it all so I've used his stuff. It just installs a folder inside the Arduino folder and the extra boards appear at the end of the list.

I have made the Arduino.h mods to a couple of libraries to get them to compile under v1.0 but these are not involved in this GLCD application so are untouched.

No changes to PROGMEM definition

I think that ManiacBug created the 1284P files from scratch rather than modifying the Sanguino ones. The pin outs accepted for Sanguino are the same as the ones ManiacBug used as far as my testing has shown. I created a sketch that simple flashed each numbered digital port and then re-compiled and up-loaded it before testing the output and they all work and are all as expected.

I really could do with getting the GLCD working with the 1284P as the alternative requires going to surface mount and although I have the equipment for that now I am not very well practiced with it's use and am likely to do some damage before I get very good at it

Many many thanks for all the help

Oh it can and will be made to work, no worries there.

One thing I noticed is that there are two sets of pin mappings for Sanguino in that core you provided.
There is a "standard" variant and a "avr_developers" variant.

They do not map the Arduino pins the same for the AVR pins on port A
which is Arduino pins 24-31.

One maps 24-31 on bits 0-7 (pin 24 is bit 0) and the other maps them backwards
where pin 24 is bit 7.

While the "standard" variant in the core you are using
uses what I would consider a more reasonable/normal
mapping (Arduino pin 24 is bit 0), it does not match all the other Sanguino pin mappings,
I've seen in the past - which IMO mapped the A port backwards on the digital pins.

The implementation of this variant stuff in Arduino 1.0 is total CRAP. It is a stupid way of doing things.
In real development environments, this kind of stuff is handled with defines which then
are used in conditional compilation and can even include different header files.
As it is now, the only entity that "knows" the variant is the IDE and since it only
uses it to alter the include path on the command line, nobody else can know which variant was
selected.

There are times when you really want and need to know this kind of information,
in particular if you are trying to share common core code across multiple "variants".
An example might be different board layouts that use the same processor etc...
They should have provided for some kind of defines to indicate the core and the
variant being used.

Some implementations like Teensy define their own defines but it really should be handled
in a common way for all cores.

But trying to get the Arduino developer team to make any changes, even when it solves
their own issues, is like beating your head on a brick wall.
They just don't "get it".

Anyway this is a nightmare for the glcd library because, it can only "see" the processor type,
it cannot see the variant which in this case alters the Arduino pin mapping.
Because of this, the glcd library cannot create/compensate for the proper pin mapping.

I bring this up because as soon as the glcd diag code compiles, the Arduino pin mapping you
created will be wrong.
The glcd library includes an Arduino pin mapping for the 644 which was based on Arduino pins 24-31
being mapped to bits on port A in reverse order; pin 24 is port A bit 7 and pin 31 is bit 0

The Arduino pin mapping you created for the 1284/1284P used the original Sanguino 644 pin mappings
which Arduino pin 24 maps to PORT A bit 7, but you selected
the "standard" board vs the "avr-developers.com pinouts ..." board which
maps Arduino pin 24 to PORT A bit 0 and pin 31 to bit 7
so the pin mapping in glcd/include/arduino_io.h does not agree with the pin mapping
used in the "standard" variant.

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

There are a few options for handling this, but the main thing you need to do is ensure that if you use PORT A
for the glcd pins, (Arduino pins 24-31) that the mapping in glcd/include/arduino_io.h matches
the pin definitions used in the core code.

--- bill

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 ( Contact Support ). As you can see 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.

retrolefty:

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

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

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

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?

cowasaki:
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