STM32 : set all PinMap structures as weak

[jeromecoutant]

Description

This allow custom overwrites.

Status

READY

[0xc0170]

We should use MBED_WEAK that toolchain header file provides. But first a question: What is the use case for having them over-writable ? They define all MCU pins, is there anything missing?

[jeromecoutant]

OK to use MBED_WEAK.

What is the use case for having them over-writable ?

I can see 2 cases:

• this was introduced by @helmut64 in Support the STM NUCLEO_L433RC-P board #5591
  Goal was to introduce an "official" board, but to use a custom board.

• the second point could be for issues like Serial using PA_11 & PA_12 stops working when using the default serial pins (PA_2 or PA_3) as analog or digital in/outs. #5930
  In the pinmap structures, we have commented several pin lines for several reasons. But some customers could have some different reason. So he can now easily redefine the structure.

[0xc0170]

For custom boards that might have more pins available, or some differencies. This might be a valid reason to extend API or provide functionality that instead of weak linking, set pinmap arrays, default ones provided? We shall think about it

@SenRamakri @bulislaw @c1728p9 Can you review this addition ?

[helmut64]

I believe declaring this as weak (as I started on the L433) series is a fair tradeoff. This is adding more flexibility for custom target boards. In general this allows to use more pins as GPIOs, however it is not perfect because special pin functionality e.g.: UART, SPI, Timer, interrupt vectors, etc are not enabled because the target device does not know about it. E.g.: See serial_device.c in the STM target folder.

My opinion is, that the weak solution is great for developers, they get access to more pins and can optimise their hardware pin design to use mbed for their target boards. Most engineers and students are can easily handle the mbed online system, however adding a new target is out of reach for most developers.

Making it perfect (with all features) is a super large task, and some MCU vendors (Atmel) don’t keep up their mbed support anyways. I recommend this little change with a great benefit.

[jeromecoutant]

Compilation issue should be solved
Thx

[cmonr]

@jeromecoutant Could you rebase this PR so that we can start CI? Thanks!

[jeromecoutant]

Could you rebase this PR so that we can start CI?

Done

[0xc0170]

/morph build

[0xc0170]

@helmut64 Thanks for details 👍

LGTM. Be aware that for all these platforms, if mbed 2 lib is used, it wont be functional until we make these peripheral pins definitions into own object file.

[mbed-ci]

Build : SUCCESS

Build number : 988
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5936/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 681
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5936/

[mbed-ci]

Test : SUCCESS

Build number : 810
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5936/810