TARGET_STM: FW driver files refactor proposition

[jeromecoutant]

Summary of changes

Hi

In order to make easier driver files maintenance for ST Cube delivery,
And to help each customer to develop his own board with a different chip as the one used for NUCLEO (ST board),
I tried to simplify and improve the procedure of the copy from Cube FW delivery to mbed-os github.

I started with the STM32G0 family which doesn’t impact many customer yet.
Goal is to use scripts for coming STM32G4 and STM32L5, and then for all families.

What has changed:

• in the family level (targets/TARGET_STM/TARGET_STM32G0/), “device” name is renamed into STM32Cube_FW
  => I think it is more explicit

Then in order to make it again more explicit, I propose to copy:

• files from STM32Cube_FW_G0_Vx.x.x\Drivers\CMSIS (ST Cube FW delivery) to TARGET_STM32G0\STM32Cube_FW\CMSIS
• files from STM32Cube_FW_G0_Vx.x.x\Drivers\STM32G0xx_HAL_Driver to TARGET_STM32G0\STM32Cube_FW\STM32G0xx_HAL_Driver
• what ST Cube FW calls "template" files to TARGET_STM32G0\STM32Cube_FW

Now on the the sub family level (targets/TARGET_STM/TARGET_STM32G0/TARGET_STM32G0XXxx)

• Previously, only the sub family needed by the ported target MCU was created
  ==>Now all sub families are automatically created, customers only have to create their own target inside

• “device” directory was not used and then removed

• all TOOLCHAIN_xxx files are available (aligned with https://os.mbed.com/docs/mbed-os/v5.14/porting/porting-bootstrap.html) for all sub families

Conclusion:

• File copy from ST Cube FW to mbed-os is simplified and with minimal patches
• When customer would like to port a his own board, MCU level is already available even if there is no previous board available. Second step would be to create his own peripheral pins, but it could be very easy thanks to the already available script:
  https://github.com/ARMmbed/mbed-os/blob/master/tools/targets/STM32_gen_PeripheralPins.py

Impact of changes

Migration actions required

Documentation

---

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

@ARMmbed/team-st-mcd
@MarceloSalazar @bulislaw @0xc0170

---

[ciarmcom]

@jeromecoutant, thank you for your changes.
@bulislaw @0xc0170 @MarceloSalazar @ARMmbed/mbed-os-maintainers please review.

[0Grit]

@ARMmbed/team-embeddedplanet

[MarceloSalazar]

Just a friendly reminder for @ARMmbed/mbed-os-maintainers to review ;-)

[0xc0170]

One question: commit 57f144e removes 2 SDPX identifiers. I assume this is because drivers do not provide this neither (was actually just in Mbed OS) ? It would be nice if they have SDPX identifiers as well (would help with checking licenses).

The rest looks fine to me

[jeromecoutant]

I assume this is because drivers do not provide this neither

Yes, files in STM32Cube_FW are the one from ST Cube delivery. No change.

[0xc0170]

I scheduled CI

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts