Improve backwards compatibility

[ghent360]

In the Marlin project the code makes heavy use of the preprocessor. It is horrid practice, but a lot of code has been written that way.

One bad case fails, when the pins are defined as enum.

#define FAN_PIN PA0
#define FAN2_PIN PB1

#if FAN_PIN == FAN2_PIN
//stuff
#else
// other stuff
#endif

If the pins are defined using an enum structure the #if always succeeds, because it treats the PA0 and PB1 value both as "undefined" which evaluates to 0.

Making the pin aliases as #defines is quite unsightly, but avoids such compatibility issues with the AVR core.

[hasenbanck]

Why don't you use simply the arduino pin numbers as pin numbers in your pin definition for your board? That's how I did it in my HAL / board definition for my F7 project.

[ghent360]

The Arduino pin numbers are not the most intuitive numbering scheme - at least to me.
The point is to make these aliases more useful across the board.

[hasenbanck]

I'm not against this change, but only want to comment that in Marlin, the overwhelming majority of boards / HALs use the arduino pin numbering. Only the few experimental STM32 boards (using the other arduino cores) and the SMOOTHIEBOARD are using vendor specific aliases. AVR, SAM3X8E, MK64FX, LPC1768 and all LPC1769 board except SMOOTHIEBOARD are using the arduino numbering.

[fpistm]

This change should be safe as enum is not typedef.
And about this one:
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/cores/arduino/pins_arduino.h#L28
Do you think it should be converted also ?

[ghent360]

I was looking at the Dxx pins, but they don't seem to be in use much. In most cores these are not defined at all. For example in ./variants/robot_control/pins_arduino.h there are defines for D0..D5 and these are defined as TKD0..TKD5, which in turn are static const uint8_t TKDx = ??;

In short I don't think these would be a problem, they are not defined in the avr code, so there is not backwards compatibility risk.

We can rename them for code consistency, but I would propose the same scheme you have for the analog pins, so if you have 25 digital pins in one variant only D0..D24 are defined and DMAX is 25.

[fpistm]

I've also checked and as I thought this does not change anything as the toolchain optimization remove useless code, so I will not change that.

[fpistm]

This PR replaced by #356
Note that I leave the Dx definition as it is.

[fpistm]

Review done in #356

[fpistm]

Close this one as #356 has been merged.
Thanks @ghent360 for your work 👍