Two minor fixes, add missing include and provide pin definitions for A0 to A7

[hlovdal]

No description provided.

[ianfixes]

I googled the name of those pins and found a file from @PaulStoffregen :
https://github.com/PaulStoffregen/cores/blob/master/teensy3/pins_arduino.h

Is there a larger effort in defining pins that we need to make here? (I won't delay merging this, I'll just open some issues)

[hlovdal]

Teensy appears to be a Arduino compatible ARM Coretex board with 34 I/O pins. So most proper Arduino hardware targets will have less, but I do not feel that there is any problem in overcommitting on providing possible non-existing pin definitions in the test environment. I will add and rebase the branch.

[hlovdal]

One question though. The pins have different numerical values depending on which hardware target, and some of them are conflicting, e.g. A20 is either 31 or 39 in the pins_arduino.h linked above.
And this is also the case for other pin definitions like

#define PIN_WIRE_SDA         (2)

in ~/.arduino15/packages/arduino/hardware/avr/1.6.209/variants/leonardo/pins_arduino.h vs

#define PIN_WIRE_SDA        (18)

in ~/.arduino15/packages/arduino/hardware/avr/1.6.209/variants/standard/pins_arduino.h

Do we need to keep a 1-to-1 consistency with all hardware targets? That will be a lot of work, or could I just create an enum with consecutive values (possibly starting on a non-compatible value like 100 just to avoid the situation that some of the pin definition are the same as the real hardware while some are not, and at least be consistent in that none are)).

[ianfixes]

I'm still figuring out how this review thing works. I thought you would have seen these comments 7 hours ago with my other comment, but apparently not.

[ianfixes]

I'm assuming that I was breaking compilation (somewhere) without this. Can you describe where the trouble was?

[ianfixes]

But only on some platforms, right?

[matthijskooijman]

Most platforms have such definitions. Maybe this can be controlled using a NUM_ANALOG_PINS (which would be good to define in any case, along with NUM_DIGITAL_PINS, since those are at least defined for AVR-based boards: https://github.com/rlcamp/ArduinoCore-avr/blob/4c9f899f8eef12989903e474beea3a71a90f511c/variants/standard/pins_arduino.h#L28-L29)

[ianfixes]

It sounds like you understand my hesitation here, and I think you're asking the right questions.

Do we need to keep a 1-to-1 consistency with all hardware targets?

No. We just need to make sure that the mocks will work if you stay consistent (i.e. if within the library we refer to A20 and within the unittest we do something like assertEqual(A20, myLib->somePin), it should always work, and not give a 31 =/= 39 assertion error).

I do not feel that there is any problem in overcommitting on providing possible non-existing pin definitions in the test environment

It depends. One of the features offered by this library is the ability to unittest across Arduino hardware platforms, so I need to be somewhat careful that the test environments are accurate. (E.g. a library would break if it was doing #ifdef A20 to determine available hardware features.) I doubt that people are using A20 in particular for their macros, so that's probably fine. But that's how I'm approaching this.

The sort of pattern I'm trying to support is this one: https://github.com/adafruit/Adafruit-WS2801-Library/blob/master/Adafruit_WS2801.h#L59