I think I might be suffering the pins not being nailed down issue with trying to get the GLCD library to work.
I have a board sat here and running Arduino v1.0 using ManiacBug's instructions.
I have started a thread on the issue in the LCD section (http://arduino.cc/forum/index.php/topic,91961.msg690725.html
) but I think it might be down to pins not being where they should be.
Has anyone got GLCD working on ManiacBug 1284p chips ?
Really hoping for official support for this chip...
I touched on this briefly in the GLCD thread above, but in my opinion,
one of the big problems/difficulties with getting new processors and boards
supported is the way the Arduino team has
implemented the development environment with the IDE.
i.e. The IDE has certain knowledge about the target that it does not share
A big problem is that the core and now this new variant information in 1.0
is unknown by anything but the IDE.
There are times when the code being compiled could take advantage of this information
or in some cases actually need to know which core and which variant of that core is being compiled.
Without this kind of information you can get forced into having to duplicate code or entire
directories of code just to be able to build the code slightly differently because of something as trivial
as pin mapping differences between variants of the same core because the core code can't
tell which variant the code is being compiled for.
In the case of the glcd library it needs to be able to know this information to be able to properly
map Arduino pins to direct port i/o pins. As it is today, the glcd library does not have access to anything
but the processor type, which simply is not good enough when there are multiple variations of that core
that have different pin mappings.
glcd needs this because it not only maps Arduino pins to direct port i/o but by being able to look
at the individual Port and bit numbers of each Arduino pin it can tell which of the 8 data lines are adjacent
to each other and in which order and use that information to convert to using nibble and bytes
with direct port writes as well when the chosen pins allow it.
And since this is all this is done at compile time, the glcd code must know the exact pin mapping information
which can only be known if you know the core and variant.
(processor type really isn't needed if you know the core and variant)
Teensy helps solve some of this by defining a few core defines so that it is possible to tell the difference between
Teensy and Leonardo, but if Teensy headers didn't create these core defines, there would be no way to tell them apart.
Since the Arduino to port/bit mappings are different between Teensy and Leonardo, it can be critical
in some cases to know which one you are using.
The solution to all of this is along the lines of what Paul asked for some years ago and that is to
communicate the core (and now the variant) information to the code being compiled.
There needs to be defines for both of these pieces of information that are available to the
modules being compiled so that if needed they can uniquely identify the target.
mpide has some additional/better capabilities than the Arduino IDE that can help in this area.
mpide allows setting per board compiler defines in the board.txt file
There are several different ways that this could be handled.
The exact method of doing it isn't that important, what is more important
is the information itself.
Ideally the cpu/board/core/variant values could each be defined using either
well known names or each assigned to well known define names.
This should be an easy issue to solve and it does not have to involve
waiting for the Arduino team to do anything.
(Core and Variant defines could be added to the variant header files)
If we could get consensus on the information which is only 2-3 define values
(CPU is already defined) and how they should be defined, then all the 3rd party cores
could start to use it in their variant files without having to wait on any support
from the official Arduino code.