Fix STM32 remapped GPIO data

[salkinium]

The remapped pins were duplicated inside the GPIO list, which lead to conflicting data.
The remapped pins should only be part of the package, not the GPIO data.

[chris-durand]

The remapped pins should only be part of the package, not the GPIO data.

Is this really what we want? We would like to have a gpio_A11.hpp header generated even when it is a remap pin. An STM32F042F6 has a Pin A11 with all the associated hardware functions although it is not always physically accessible on the package. This is exactly what the device file should describe, which hardware is present. Now we have to add some additional complexity inside the gpio driver to add them back in the modm driver lbuild file.

[salkinium]

Ah, I may have misunderstood something here, let me check the raw data.

[salkinium]

Yeah, I think your right. This is wrong, because the GPIOs are filtered by the package id, and now I've just removed them.

There is an issue with the merging algorithm, which doesn't work correctly in some complex cases where just one device has something, and the other do not.

[salkinium]

I can revert these changes, but then it's just broken in other ways, so I guess I have to fix this merging issue, which is completely unrelated. This issue is also holding up #35.

[salkinium]

Ah, no this is an issue in the raw data, there are simply multiple PA9 pins on different pin positions at the same time? (from STM32G071K(6-8-B)Tx.xml)

	<Pin Name="PA9" Position="19" Type="I/O">
		<Signal Name="DAC1_EXTI9"/>
		<Signal Name="I2C1_SCL"/>
		<Signal Name="RCC_MCO"/>
		<Signal Name="SPI2_MISO"/>
		<Signal Name="TIM15_BK"/>
		<Signal Name="TIM1_CH2"/>
		<Signal Name="UCPD1_DBCC1"/>
		<Signal Name="USART1_TX"/>
		<Signal IOModes="Input,Output,Analog,EVENTOUT,EXTI" Name="GPIO"/>
	</Pin>
	<Pin Name="UCPD1_DBCC1" Position="19" Type="MonoIO" Variant="PINREMAP">
		<Signal Name="UCPD1_DBCC1"/>
	</Pin>
	<Pin Name="PA10" Position="21" Type="I/O">
		<Signal Name="I2C1_SDA"/>
		<Signal Name="SPI2_MOSI"/>
		<Signal Name="TIM17_BK"/>
		<Signal Name="TIM1_CH3"/>
		<Signal Name="UCPD1_DBCC2"/>
		<Signal Name="USART1_RX"/>
		<Signal IOModes="Input,Output,Analog,EVENTOUT,EXTI" Name="GPIO"/>
	</Pin>
	<Pin Name="UCPD1_DBCC2" Position="21" Type="MonoIO" Variant="PINREMAP_10_12">
		<Signal Name="UCPD1_DBCC2"/>
	</Pin>
	<Pin Name="PA11 [PA9]" Position="22" Type="I/O">
		<Signal Name="ADC1_EXTI11"/>
		<Signal Name="COMP1_OUT"/>
		<Signal Name="I2C2_SCL"/>
		<Signal Name="I2S1_MCK"/>
		<Signal Name="SPI1_MISO"/>
		<Signal Name="TIM1_BK2"/>
		<Signal Name="TIM1_CH4"/>
		<Signal Name="USART1_CTS"/>
		<Signal Name="USART1_NSS"/>
		<Signal IOModes="Input,Output,Analog,EXTI" Name="GPIO"/>
	</Pin>
	<Pin Name="PA9 [PA11]" Position="22" Type="I/O" Variant="PINREMAP">
		<Signal Name="DAC1_EXTI9"/>
		<Signal Name="I2C1_SCL"/>
		<Signal Name="RCC_MCO"/>
		<Signal Name="SPI2_MISO"/>
		<Signal Name="TIM15_BK"/>
		<Signal Name="TIM1_CH2"/>
		<Signal Name="USART1_TX"/>
		<Signal IOModes="Input,Output,Analog,EVENTOUT,EXTI" Name="GPIO"/>
	</Pin>
	<Pin Name="PA12 [PA10]" Position="23" Type="I/O">
		<Signal Name="COMP2_OUT"/>
		<Signal Name="I2C2_SDA"/>
		<Signal Name="I2S1_SD"/>
		<Signal Name="I2S_CKIN"/>
		<Signal Name="SPI1_MOSI"/>
		<Signal Name="TIM1_ETR"/>
		<Signal Name="USART1_CK"/>
		<Signal Name="USART1_DE"/>
		<Signal Name="USART1_RTS"/>
		<Signal IOModes="Input,Output,Analog,EXTI" Name="GPIO"/>
	</Pin>
	<Pin Name="PA10 [PA12]" Position="23" Type="I/O" Variant="PINREMAP_10_12">
		<Signal Name="I2C1_SDA"/>
		<Signal Name="SPI2_MOSI"/>
		<Signal Name="TIM17_BK"/>
		<Signal Name="TIM1_CH3"/>
		<Signal Name="USART1_RX"/>
		<Signal IOModes="Input,Output,Analog,EVENTOUT,EXTI" Name="GPIO"/>
	</Pin>

[salkinium]

Whyyyy, ST?!?

[salkinium]

What I think ST means here, is that when you remap these pins:

• Pos. 19 is connected to the UCPD1_DBCC1 alternate function.
• Pos. 21 is connected to the UCPD1_DBCC2 alternate function.
• Pos. 22 is connected to PA9, but without the UCPD1_DBCC1 AF.
• Pos. 23 is connected to PA10, but without the UCPD1_DBCC2 AF.

BUT, there seems to additionally be some kind of variant dependency as well:

The devices housed in 64- and 48-pin packages provide 2-port USB-C Power Delivery. The devices housed in 28/32-pin packages come in two variants - “GP” with a single-port limited USB-C Power Delivery and “PD” with 2-port USB-C Power Delivery.

[chris-durand]

UCPD1_DBCC1 is not an alternate function, it's an additional function. The mux control works differently. It's not in the alternate function list:

Haven't figured out yet how to configure it, though.