Some confusion around the ordering/mapping of the pins in the variant.cpp PinName array

[TwoArmsTwoLegs]

Hi all,
I've been setting up a variant for 48 pin STM32L02CZT.
I'm getting the wrong ordering of pins somewhere in the variant files.
I've ordered variant.cpp PinName array by the physical pins on the chip from pin 1 on the datasheet, but addressed PA_0 (physical pin 10) is coming out at PC_13 (physical pin 1). Clearly that's not the strategy.

I understand that the defines in variants.h index the elements of the variants.cpp array, so clearly elements have to be correctly addressed between the index and the array. Does it matter more than that?
Is there a separate mapping from PY_X naming and PX naming?
For example pin PA_0 is physical pin 10. How do I know which variants.h PX that should be? My Naive understanding says that PA_0 should be PA0. but I'm not sure now.

Confused and grateful.

[.rpv]

Hi, so yes, the pin naming stuff it's really over complicated.... so the Px_XX (example: PA_0) are the "real" pin names, those are defined within the CORE, all others are just an AKA: numerical pins and the PxXX (PA0) names, but the Px_XX cannot always be used, it will depend on the functions (digitalRead, analogRead, ...).

Now, with the naming logic on the variant, the digitalPin[] array on the variant.cpp file will include the Px_XX names, it should be sorted as the physical (NOT the physical pin of the MCU) position on the board (not really mandatory) but the analog pins should be equal/above the number of analog pins available (defined by NUM_ANALOG_INPUTS and NUM_ANALOG_FIRST on variant.h), so if you board doesn't comply with this order just invert the order otherwise the analogRead() will be unusable.

The variant.h names:

Code: Select all

#define PA8    0
#define PA9    1
#define PA10   2
#define PA11   3

will refer to the digitalPin[] array, so in this case PA8 it's index 0 of the array:

Code: Select all

const PinName digitalPin[] = {
//PX_n, //Dx
	//.with.the.USB.on.the.bottom.and.left-to-right-to-top.naming;
	// left.side
	PA_8,
	PA_9,
	PA_10,
	PA_11,

Check this variant, it's for the STM32F030K6 MCU, it's a pretty simple board and on this case I had to invert the order of the pins to comply with the NUM_ANALOG_FIRST>=NUM_ANALOG_INPUTS condition.

As you see the pysical pin of the MCU it's not relevant on the variant.

[fpiSTM]

FYI, @.rpv
The analog restrictions has been removed you can define them in any order you want and not in a contiguous way.

[.rpv]

FYI, @.rpv
The analog restrictions has been removed you can define them in any order you want and not in a contiguous way.

Awesome

[TwoArmsTwoLegs]

Oh man, I must have another problem then. Blink sketch on PA0 blinks on the correct pin (MCU pin 10), while Blink sketch on PA_0 blinks on MCU pin 2 (PC13).
Surely PA0 should always be correct if I'm understanding you right, while PA_0 should be the one that might be misconfigured? but I'm experiencing the reverse.
Superficial testing seems to show that the PX_Y pins are shifted, but not uniformly. PB0 blinks correctly at MCU pin 18, but PB_0 blinks incorrectly at MCU pin 19.

That doesnt make *any* sense.

variant.cpp

Code: Select all

// Pin number
const PinName digitalPin[] = {
	
			//1 VDD
	PC_13,	//2
	PC_14,	//3
	PC_15,	//4
	PH_0,	//5
	PH_1,	//6
			//7 NRST
			//8 VSSA
			//9 VDDA
	PA_0,	//10 
	PA_1,	//11
	PA_2,	//12
	PA_3,	//13
	PA_4,	//14
	PA_5,	//15

variant.h

Code: Select all

*----------------------------------------------------------------------------
 *        Pins
 *----------------------------------------------------------------------------*/

					//1 VDD
	#define PC13 0	//2
	#define PC14 1	//3
	#define PC15 2	//4
	#define PH0 3	//5
	#define PH1 4	//6
					//7 NRST
					//8 VSSA
					//9 VDDA
	#define PA0 5	//10 
	#define PA1 6	//11
	#define PA2 7	//12
	#define PA3 8	//13
	#define PA4 9	//14
	#define PA5 10	//15

FYI, @.rpv
The analog restrictions has been removed you can define them in any order you want and not in a contiguous way.

Gratitudes from the those in the present and those in the future. It was/is a very unintuitive restriction, though I'm sure with good reason.

[fpiSTM]

PYn is the pin number while PY_n is the PinName.
Arduino API use pin number: D0, 0 or PC13 in your case as it is defined as 0.
The pin numberr is used to know which PinName is used and represent the index in the digitalPin array.
The PinName represent the GPIO port and GPIO pin in a single value:

PA_0 = (PortA << 4) + 0x00,

https://github.com/stm32duino/Arduino_C ... ames.h#L16

So if you do digitalWrite(PA0, HIGH) then it will get PA_0 at index 5 in the array.
But using digitalWrite(PA_0, HIGH) then It will get PC_13 at index 0 because PA_0 is equal to 0....

Some API can use PinName but they are not standard Arduini API.

[TwoArmsTwoLegs]

Ah! So actually it *is* working as expected?
And for most situations I'll be addressing with pin number (PXY) not pin name (PX_Y)?

I don't know why I got it into my head that the correct way to address pins is via pin name.
Probably just unlucky with my choice of example code.

[fpiSTM]

Yes, all is fine

[TwoArmsTwoLegs]

Ah Amazing.
Thank you both for sharing your experience.

[fredbox]

You can use PY_n instead of PYn as long as you use pinNametoDigitalPin(). See viewtopic.php?p=1682#p1682. There are a few non-Arduino functions that take the pin name instead of the number.