SPI library: can't accept pin numbers with _ALTx in constructor

[akasona]

Version2 core introduced pin numbers with _ALTx (ex. PB5_ALT1) and I can use SPI3 with pins PB5:MOSI, PC11:MISO and PC10:SCLK in this way:

SPIClass SPI_3rd;// set pin numbers later.

SPI_3rd.setMOSI(PB5_ALT1);
SPI_3rd.setMISO(PC11);
SPI_3rd.setSCLK(PC10);
SPI_3rd.begin();
SPI_3rd.setClockDivider(SPI_CLOCK_DIV16);
SPI_3rd.transfer(0x10);// any data

But I can't:

SPIClass SPI_3rd(PB5_ALT1, PC11, PC10);// passing all pin numbers.

SPI_3rd.begin();
SPI_3rd.setClockDivider(SPI_CLOCK_DIV16);
SPI_3rd.transfer(0x10);// any data

When I call transfer(), the program keeps waiting TXE here.
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/libraries/SPI/src/utility/spi_com.c#L443

Probably the problem is:
The constructor takes pin numbers as uint8_t, so I pass PB5_ALT1 (= PB5 | ALT1), but mosi's value still equals PB5.

SPIClass(uint8_t mosi, uint8_t miso, uint8_t sclk, uint8_t ssel = (uint8_t)NC);

Versions:

• OS: Windows 10 Pro
• PlatformIO IDE: 2.3.2
• VSCode: 1.57.0
• platform-ststm32: 14.0.0
• STM32 core version: 2.0.0

Board:

• Nucleo L476RG

[akasona]

The setXXXX() methods take uint32_t types, so they keep ALTx bits.
I have tried the SPIClass constructor fix to take uint32_t pin numbers, and it looks going good.

akasona@28258a9

[fpistm]

Hi @akasona
This is correct, this library has kept uint8_t to kept API compatibility with Arduino API.
I guess now it is safe to change the type to uin32_t, it should be the same for Wire.

[akasona]

Thank you @fpistm
I see it's a compatibility trap.

We can make our products with setXXXX() methods, so it's not critical.
But I hope other people can avoid this trap. It's so hard to find what happened!

[fpistm]

@akasona
I've made the update.
enjoy

[akasona]

Thank you @fpistm. Nice work!