A6, A7, PIN_A6, PIN_A7 exist when there are not 8 analog pins

[bperrybap]

The standard variant always creates the defines PIN_A6 and PIN_A7 and the constants A6 and A7 even when there are not 8 analog inputs.

The variant eightanaloginputs exists to declare that the h/w as 8 analog inputs so why not use that in the standard variant to disable the extra two inputs when they don't exist.
It only requires a slight tweaking of the files.

i.e.
In eightanalog inputs pins_arduino.h

#define NUM_ANALOG_INPUTS           8
#include "../standard/pins_arduino.h"

And in the standard pins_arduino.h

// assume 6 analog inputs if not told 8 by another variant file including this file
#ifndef NUM_ANALOG_INPUTS
#define NUM_ANALOG_INPUTS 6
#endif

// define additional symbols when there are 8 analog iputs
#if (NUM_ANALOG_INPUTS == 8)
#define PIN_A6 (20)
#define PIN A7 (21)
static const uint8_t A6 = PIN_A6;
static const uint8_t A7 = PIN_A7;
#endif

That way they only exist when they should and sketch could actually use something like
# ifdef PIN_A6

to determine if there is an analog pin A6 or not.
Same for A7

[matthijskooijman]

Sounds good to me. Care to submit a PR?

[bperrybap]

PR meaning pull request?
I'll come back with a pull request after I've had a chance to test it.

[bperrybap]

off of what branch? master or ide-1.5.x
I can't view the network graph since there are so many forks.

[sandeepmistry]

Please branch off of master.

[SpenceKonde]

How will this change impact people who bootload nano/pro mini boards as Unos? This is a fairly common practice, since the Uno bootloader is strictly better, so some thought should be given to it's impact on these users... It seems like it would needlessly break sketches and would force people onto third party hardware libraries if they want to use 8 analog inputs with the good bootloader - and the benefit isn't clear to me.

[bperrybap]

@SpenceKonde,
I just went and took a close look at the boards.txt file to see how it would affect things.
It is a bit of wreck for AVR based boards. So I can see why you are concerned as I'm sure that people are using incorrect board types to get around issues in the boards.txt file for certain boards, especially those boards that were originally using the older ATmegaBOOT bootloader which is larger and runs at a slower baud rate.

While all the AVR based boards are all using avrdude and "arduino" protocol for the upload,
there are multiple bootloaders and baud rates being used.
Sure you can expect some slower baud rates with slower AVRs or even with 3v parts, however, in some cases the fuses and variables which indicate the bootloader size are not all correct either.
For example:
"Arduino Mini" uses the optiboot bootloader at 115200 baud but then sets the fuses and variables indicating that the bootloader is 4k in size. So while you get the faster uploads you still loose that extra space in the bootloader area.

So yeah, there are multiple issue here and the "fix" for incorrectly creating A6 and A7 symbols on boards where they don't exist is not as simple as correcting the symbols to only show up for the eightanaloginputs boards particularly when considering backward compatibility of these work around use cases for using optiboot.

There does not seem to be an easy fix for this.
All AVR boards that either didn't use optiboot or were incorrectly using optiboot like "Arduino Mini" would need to be updated.

The issue with simply updating all the board types to now use optiboot is that the baud rate is different than the non optiboot bootloader and so older or existing board would not be able to be uploaded until they had a new bootloader installed - this is not a valid option.

One way to handle this would be to add a menu field for those boards to select the bootloader for those boards.
(optiboot vs ATmegaBOOT)
That way the user could select it and the proper bootloader and fuses would be used for burning and the proper baud rate would be selected for uploading.
This would also eliminate the need for having to use the incorrect board type for uploads.

Then and only then , could the the A6 and A7 symbols be eliminated for the non eightanaloginputs boards.

So the real issue seems to be how to solve using optiboot for the older the AVR boards as that is a much bigger and definite real-world issue.

arduino.cc developers?
I'm curious as to your thoughts providing a better way for the older AVR boards to be able to use optiboot and perhaps even the ability to select the bootloader type for those boards.