Go Down

Topic: v3 dec 2011 GLCD on 1284p with Arduino 1.0 (Read 5 times) previous topic - next topic

cowasaki

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 : http://maniacbug.wordpress.com/2011/11/27/arduino-on-atmega1284p-4/




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

cowasaki


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

bperrybap

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


retrolefty

#14
Feb 15, 2012, 02:32 am Last Edit: Feb 15, 2012, 02:46 am by retrolefty Reason: 1
Quote
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 ( http://sanguino.cc/hardware ). 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.

Go Up