MKS Robin Nano V3 + STM32F4x0Vx Variant

[rhapsodyv]

Requirements

MKS Robin Nano V3 board (to be released)

Description

This PR add support for MKS Robin Nano V3 board to marlin, and add a generic F4x0Vx variant.

After this get merged, I will submit more 3 PR, related to this board: support for thumb drive, multi media support for Marlin, msc support for STM32.
Because of the new future PRs, this variant could be changed to better work with the new features.

Benefits

New board. And using STM32.

[rhapsodyv]

We should study/think a way to change the generic variant using PINS file data, when copying it to PIO. It would allow us to use generic variants and avoid a lot of similar looking folders.

[thinkyhead]

We should study/think a way to change the generic variant…

Does PlatformIO provide a hook for that? Hmm….

[sjasonsmith]

We should study/think a way to change the generic variant…

Does PlatformIO provide a hook for that? Hmm….

I believe there might be a way to override the variant folder, rather than copying things into the framework as we do now.
We might be able to have a pre script that actually generates a variant in the build folder and uses it from there.

While we are at it we could generate constants for the pins so we can do better build-time checking of things!

[rhapsodyv]

A variant (for STM32duino) has basically a few roles:

1. Add the ldscript.ld
   This file is nearly always the same for the target MCU. When it is edited, is for very specific cases, or someone if "fixing" a bug on the wrong place.... This file is even generated by the STM32 tools.

2. Do some system initialisation
   This is very standard too. There're some exceptions, like chitu, that needs specific init code to handle some stock bootloader issues.

3. Define pins values
   Also very standard. Can vary if our variant is targeting more than one MCU serie.

Now, begin the part that we normally customize:

4. Configure some modules from the framework
   We configure some flags and enable/disable some modules for the current framework. This can have some variation for the same mcu, because one board can support Usb Serial and another board don't.
   >> Solution: This could be achieved adding -DMODULE in the env, or even using BOARD_CUSTOM_BUILD_FLAGS, if two very different boards are using the same env.. (that is unlikely)

5. Define timers
   We set the TIMER_TONE, TIMER_SERVO, TIMER_SERIAL.
   >> Solution: This could be achieved adding -DTIMER_SERIAL=6 in the env (some envs already do it), or even just set in right on the PINs file. If it's a board setup, I think that should stay in the pins file.

6. Define lists of pins linked to MCU functions
   And here is the trickiest part. We are talking about this type of definition on PeripheralPins.c:

#ifdef HAL_SPI_MODULE_ENABLED
WEAK const PinMap PinMap_SPI_MISO[] = {
{PA_6,  SPI1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_SPI1)},
//  {PB_4,  SPI1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_SPI1)},
{PB_4,  SPI3, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_SPI3)},
// {PB_14, SPI2, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_SPI2)},
{PC_2,  SPI2, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_SPI2)},
{PC_11, SPI3, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_SPI3)},
{NC,    NP,    0}
};
#endif

This is used for two things:
a) Discover which is the function of a PIN. For example, ask which is the SPI port for PC2. So we need make sure that the pins that we are using for some function are in the list of that function. For example: in that sample above, PB14 will not properly work if we try use it as Hardware SPI (at least not if we just use the framework code).

b) Initialise the pins of a function with some default parameters. It's done automatically by the framework. For example: if we use OTG, the framework will loop over all PINs on PinMap_USB_OTG_FS array and it will set the parameters FOR ALL PINS in the list, even if aren't using all for OTG in our board.

WEAK const PinMap PinMap_USB_OTG_FS[] = {
  // {PA_8,  USB_OTG_FS, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF10_OTG_FS)}, // USB_OTG_FS_SOF
  // {PA_9,  USB_OTG_FS, STM_PIN_DATA(STM_MODE_INPUT, GPIO_NOPULL, GPIO_AF_NONE)}, // USB_OTG_FS_VBUS
  // {PA_10, USB_OTG_FS, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_PULLUP, GPIO_AF10_OTG_FS)}, // USB_OTG_FS_ID
  {PA_11, USB_OTG_FS, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF10_OTG_FS)}, // USB_OTG_FS_DM
  {PA_12, USB_OTG_FS, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF10_OTG_FS)}, // USB_OTG_FS_DP
  {NC,    NP,    0}
};

If PA8 and PA10 isn't commented out, the framework would set they to PULL UP, etc... And it could break our code if we are using PA8/PA10 for another thing, like endstops.

This is the reason we need to comment out some pins on those lists.

To solve that (6), we will need make a clever script. It must get all pins used by the current board, match the pin usage with those function arrays, and detect what should be commented out. It's not a hard task, now that our python know everything about the board pins. But it could be a challenge to get this fully working.

@sjasonsmith can correct me if I say something wrong, or complete if I miss something.

BTW: sorry by the long text/analysis