Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

This is the first of three PRs to replace #7123
The next will add support for 120 MHz STM32L4 parts - L4P, L4Q, L4R and L4S.
The last one will add ST Microelectronics development board support for some of the new parts.

@projectgus Thanks for the review and helpful comments.

I agree using STM32L4 in many places would simplify things and improve readability. I did that in my previous PR in some places. I looked for precedent from other commits and thought listing all parts was preferred . However with so many parts it is messy. When I first started I thought there might be newer parts coming with different features, but now I think that is unlikely. ST have moved on with newer families like G4 and I think L4 is stable. I will review your suggestions when I get a chance.

I also wanted to be careful not to touch anything that affects other families due to the amount of testing, especially for families I am not familiar with and don't have dev boards for. I will still consider your suggestions.

I'm happy to update all the linker scripts for parts with 2K sectors. It's a bit more complicated for parts with non uniform sectors sizes. I have another PR coming for them. It reduces the FS cache to 48K, moves the stack into CCRAM, increases the heap size and the FS by using more sectors. I would do the non uniform linker scripts in that PR. I have been using this for years, but it needs a bit of cleanup and a big rebase first.

Sounds good. Feel free to ignore any/all of the suggestions which might impact other chips, I will make a note to take a look at them later on. (I think I can write a script that builds all of the stm32 boards and verifies no differences in the binaries, and then get stuck in cleaning up macros without fear...)

I'm happy to update all the linker scripts for parts with 2K sectors. It's a bit more complicated for parts with non uniform sectors sizes. I have another PR coming for them. It reduces the FS cache to 48K, moves the stack into CCRAM, increases the heap size and the FS by using more sectors. I would do the non uniform linker scripts in that PR. I have been using this for years, but it needs a bit of cleanup and a big rebase first.

That sounds great to me, if you're up for it!

thought listing all parts was preferred

On this, @dpgeorge may disagree, but I think what's happened is most source files have gradually grown from only a few chips supported to a lot of chips now, without it necessarily being the intention to list them all out.

We've had good luck cleaning up the esp32 port to use capability-based macros rather than listing every chip, but that's an order of magnitude fewer chips with a lot less differences so I'm not sure how viable it will turn out to be on stm32.

(To be clear, this is not a problem I'm suggesting you should tackle in this PR - except for maybe the few places where the lines were growing by a large proportion.)

Another possible way to simplify the long list of parts would be to define family sub groups in mpconfigboard_common.h, eg:

#if defined(STM32L431xx) || \
    defined(STM32L432xx) || defined(STM32L433xx) || \
    defined(STM32L442xx) || defined(STM32L443xx)
#define STM32L43
#endif

There are only six sub groups of STM32L4 compared with over twenty individual parts. The main differences between parts in a sub group are USB, LCD and crypto support.