Support in the CORE is almost there.
Issue 728 was applied, which did most everything. Issue 736 will finish it off.
There is no talk of adding VARIANTS to the official release. But we don't need variants in the release, the hardware extensions mechanism is fine for that.
What does that mean?
How can you support the original Sanguino and the Bobduino without variants?
Are you saying that this 1284p core will be hard coded to say the "standard" variant
and that the other 2 pin mappings have to ship their own core?
I think you're confused about what is a core and what is a variant. Review the boards.txt file. The advantage of having 1284P in the core is that we won't need to ship separate core files. So boards.txt can simply point to the Arduino core.
uno.build.core=arduino:arduino
Not hardly. I'm fully aware of how each mechanism works.
I understand the value in adding 1284p support to the mainline official "arduino" core as it
means users no longer have to locate and install their own separate core to get 1284p support.
What you haven't addressed is how to support multiple variants of the 1284 processor (which might use different pinouts)
once 1284p support is in the arduino core
because there is still the issue is that if a given core supports multiple variants of a single processor
type then there can be issues if the pin mappings are different and the pin mapping
information is needed at compile time.
For example in the analogRead() function there are some assumptions being made as to how to
map digital pins to analog pins/channels based on processor type.
These assumptions may not be correct depending on the given variant for that processor type
and how it defines its digital pin mappings.
While you can add support for 1284 to the common Arduino core, unless there are
defines to indicate more than just the processor type, mapping code like what is in
analogRead() can potentially fail.
Another alternative (which I think is better) and what is already used in the mighty-1284p core
is to create the needed mapping macros in the variant files.
So rather than having to use ifdefs with magic Arduino Pin#s in functions like
what is in analogRead() today that is used
to convert from a digital pin # to an analog pin #/channel, a single
macro function would be called which would work regardless of the processor or variant.
This is much better than trying to depend on processor type which does not work
in all cases - which is what we are seeing with the 1284p and its potential variants.
analogRead() can use the digitalPintoAnalogPin() macro
but I would not implement it using ifdefs in the analogRead() function as it is done
today in the mighty-1284p core.
I think it would be much better to create the digitalPintoAnalogPin() macro for *all* variants
in the core and eliminate ifdefs related to dititalPinToAnalogPin().
That way any code (not just analogRead() ) that needs this same functionality
can also have the information and use it and not have to mess with having to create ifdefs with magic number
calculations for when it is not there.
I don't see the value of sometimes having the macro and sometimes not having it.
Unless I'm missing something,
At the present time if I look at wiring_analog.c and analogRead() on git hub and
the proposed patch in issue #736, I don't see how that can support multiple variants
of the same processor that use different digital pins on the analog pins.
It looks like if a boduino variant and its pinouts were used then ananlogRead() would
fail to properly map the digital pins to analog pins.
Can't we just force all the arduino cores to have a digitalPinToAnalogPin() macro
and be done with it? That way each variant defines the needed pin information and nobody
has to ever monkey if ifdefs and magic pin numbers to do pin conversions like what is being
done in analogRead().
All the pin number "magic" is in the variant files.
The core code remains simple, clean, and easy to read.
--- bill
