Consider changing x7 pinmapping, which is particularly strange

[SpenceKonde]

This pin mapping is rather strange, and afaik, everyone whose used this core with the x7 has complained to me about it.

I propose renumbering the pins so that the arduino pin number matches the PCINT number. So the numbers will start at physical pin 1, PA0, as 0, and go down that side to PA7 on physical pin 10 as pin 7, then starting from the other side with arduino pin 8 mapped to PB0.

Only awkward bit is that if a crystal is used, that would take 12 and 13, but there'd still be a 14.

// ATMEL ATTINY167
//
//                   +-\/-+
// RX   (D  0) PA0  1|    |20  PB0 (D  8)
// TX   (D  1) PA1  2|    |19  PB1 (D  9)
//     *(D 2) PA2  3|    |18  PB2 (D  10)
//      (D  3) PA3  4|    |17  PB3 (D  11)*
//            AVCC  5|    |16  GND
//            AGND  6|    |15  VCC
// INT1 (D 3) PA4  7|    |14  PB4 (D  12)
//      (D 5) PA5  8|    |13  PB5 (D  13)
//      (D 6) PA6  9|    |12  PB6 (D  14)* INT0
//      (D 7) PA7 10|    |11  PB7 (D 15)

For easy reference, current mapping is:

// ATMEL ATTINY167
//
//                   +-\/-+
// RX   (D  0) PA0  1|    |20  PB0 (D  4)
// TX   (D  1) PA1  2|    |19  PB1 (D  5)
//     *(D 12) PA2  3|    |18  PB2 (D  6)
//      (D  3) PA3  4|    |17  PB3 (D  7)*
//            AVCC  5|    |16  GND
//            AGND  6|    |15  VCC
// INT1 (D 11) PA4  7|    |14  PB4 (D  8)
//      (D 13) PA5  8|    |13  PB5 (D  9)
//      (D 10) PA6  9|    |12  PB6 (D  2)* INT0
//      (D 14) PA7 10|    |11  PB7 (D 15)

[ApexMoEng]

Concerning that this is a large issue with this chip, as long as it is documented and highlighted, this could be beneficial. Since when I first programed the chip, I issued pin numbers just like the first example. It seems intuitive this way.

Possible problem areas that come to mind:

1. The Arduino Uno pins for MOSI MISO, and CLK, are 11, 12, and 13 respectively. Which is likely why the pins on the ATTiny are in those odd position. So if I were to # define SCK 13 in an UNO program, it would migrate to a ATTiny program well.
   With this new mapping, it wouldn't. I don't know if that would effect many users, but it might.
2. Does this affect harware SPI vs software SPI, if the pins arn't mapped to the right "Arduino Uno" numbers?

I guess in the end, as long as it doesn't break anything currently working, I am for the change.

[SpenceKonde]

1. Aaaah..... that's why they did it! I'm not sure this is a good reason for it, since not even Arduino's official boards do such acrobatics (for ex, the Mega, where SPI is also on different pins) to keep the numbers the same. Sketches should not #define MISO/MOSI/SCK - those constants are defined in the core (or they often are), so that a sketch can determine from that which pins they are.

2. hardware SPI doesn't care what the pin numbers are, it overrides the pin functionality. It's not like the STM32 chips where you have to also set the pins to AF mode. Software SPI should use whatever pins you tell it to, right? I have not used software SPI.

[ApexMoEng]

I don't redefine the core constants, I meant more like... I create my own constant called "SPICLOCK" and define it as 13. That way if I copy/pasted my code into a new compiler or uploaded to a new chip, most of the code is constant.
digitalWrite(SPICLOCK, LOW); etc.
-> GCC writeSPI(SPICLOCK, 0);

Yeah, software is whatever you tell it. I had to bit bang my own SPI code and just told each pin to output the right signals. My concern came from the library I am using right now, for the CC3000. In their example program they tell you to use hardware SPI, and don't allow you to specify the pin locations. They even have a note saying:

// Use hardware SPI for the remaining pins
// On an UNO, SCK = 13, MISO = 12, and MOSI = 11

Which kinda makes me concerned to change it, without thinking too hard about what that means.
I wouldn't want their library to start using PB3/PB4/PB5 for example.

But if this is simple paranoia and hardware SPI takes care of that then it should be fine, or if the pin mapping on affects digitalWrite()/digitalRead().

[SpenceKonde]

As I read that (and looking at the code), what they mean is that you need to use the hardware SPI pins, and, if you're using an uno, those are the pins they're on. You shouldn't need to specify the pins, I don't think.

In any event - there is now another submenu when x7 is selected to choose the pinmapping :-)

Let me know what I screwed up, I'm sure I missed something. I also found and corrected a few issues in the pin mapping in general)