Variant PINs definitions - static const VS define

[rhapsodyv]

Hi!

Is there any reason for variant.h to use the static const uint8_t Ax instead of the #define PIN_Ax (PIN_Ay + 1), when defining pins?

Example from this variant:

Arduino_Core_STM32/variants/Generic_F4x7Vx/variant.h

Line 32 in 3c414ec

#define PA0 A0 // | 0 | A0 (ADC1) | | UART4_TX | | | |

#define PA0 A0
#define PA1 A1
#define PA2 A2
#define PA3 A3  

This makes PA0 = static const uint8_t A0, so we can't use PA0 in a preprocessor directive, like #if MY_UART_PIN = PA0...

The variant could be written this way:

#define PA0 PIN_A0
#define PA1 PIN_A1
#define PA2 PIN_A2
#define PA3 PIN_A3  

This will make PA0 = *integer*, directly, thus allowing it to be used in any #if.

Note that all pins in the variant are defined as direct integer, only those related to analog that aren't:

#define PA8  8
#define PA9  9
#define PA10 10
#define PA11 11

I can send a PR with this change, I just want to know if there's any reason for that.

Thanks!

[fpistm]

AFAIK there is no specific reason.
I will change in the generic variant generation in #1091

[rhapsodyv]

That's good!

Another improvement would be add some important defines with #ifndef.

For example, timers are defined this way:

#define TIMER_TONE              TIM6
#define TIMER_SERVO             TIM7
#define TIMER_SERIAL           TIM5

But, sometimes we can use servo on TIM7 or tone on TIM6. So, we need to copy and edit the variant for it too.

In resume, we at Marlin, need to local copy variants for these reasons (I'm taking care of the stm32duino support/variants):

• Change pins to use compile constant instead of runtime constant (the original question)
• Allow timers override
• Allow PIN_WIRE_SDA and PIN_WIRE_SCL override

I'm not aware of any other reason we need copy and change the variants.

If we can incorporate the changes in the stm32duino defaults, it would be very helpful.

Do you want me to provide a PR changing the actual variants? Or can you just re-generate all?

Thanks!

[fpistm]

TIMER_SERIAL is not a standard core definition.
For other #1091 already consider this. Same for all other definitions (SPI, I2C, Serial,...).
At this time no PR is required while the #1091 is not ended and merged. It will cover most of the case.
Note that the new generic system will not generate automatically specific variant only the generic one.