Add generic F412Rx pinout variant

[MCUdude]

Follow the exact same pinout and peripheral mapping style as all the other generic F4 pinouts do.

[fpistm]

Thanks again for this new variant.

[MCUdude]

I do have a few more F4 variants before all "low pin-count" F4's are supported.
I would also like to add proper support for generic F103's as well, at least the ones with 64 pins or less. Is this something you'll merge if I submit a PR?

If yes: There do already exist a pinout variant called Generic_F103Rx. The pin style for this isn't very generic at all (very Arduino'ish), and it would great if I was allowed to "reformat" this to match the generic F4 style a bit more. I could also make sure all supported variants were listed in the tools menu, not just a few favorized ones like it is today. What du you think?

[fpistm]

Well I guess the Generic F103 could be reformatted as currently no other specific boards use it as a base except the VCC_GND but it is already int he right format I guess.

[MCUdude]

... but it is already int he right format I guess.

sorry, I didn't quite catch this part

[fpistm]

... but it is already int he right format I guess.

sorry, I didn't quite catch this part

No you are right for other Generic F103 variant only the Zx has the right generic format.

[MCUdude]

BTW when do you plan to release 1.9.0? I was hoping to add most of the planned new variants before a new release

[fpistm]

In the coming weeks...
As soon as possible as there are several fixes for I2C and HardwareTimer.

[MCUdude]

OK. I should be able to create Generic_F412Cx, Generic_F4x3Rx and Generic_F4x3Cx then.

[fpistm]

No worries, they will be other release 😉
You already had a huge number of Generic variant. This is impressive 🥇
Thanks to you several user could test quickly their boards.
One question:
I think you already answer it but don't remember it: why you add all those Generic variant?

[MCUdude]

I think you already answer it but don't remember it: why you add all those Generic variants?

I don't think I've actually answered this. First, I hope it's OK, even though it requires some review work from your side?

Usually, when it comes to "Arduino support" for standalone chips must hardware packages like this one are usually board related rather than chip related. If you're building a commercial product you don't care about development boards, you care about the chip in use. STM32s have become quite cheap, especially if you source them from China (LCSC.com has some great prices).

Many of the lower-spec chips with less memory are usually cheaper, but they are rarely supported by Arduino hardware packages because you'll usually never find cheap chips on development boards. The vendor wants to sell you the best chip they can offer., ST included (with their Nucleo boards).

With my work, a user may just select whatever STM32(F4) he wants to use, and it will just work with this hardware addon. This is GREAT if one is building a commercial product, which I'm not doing.

Bottom line, This enables the user to use whatever chip they like in their hobby project or commercial product and still can use Arduino libraries and the Arduino API, but also the ST HAL alongside if necessary. The best of both worlds!

I have much experience with 3rd party Arduino cores, so this task is not very difficult, nor very time consuming for me.

After 1.9.0 is released, I will work together with the PlatformIO developers to get proper support for all new targets there as well 🙂

[fpistm]

Make sense 👍

About that:

After 1.9.0 is released, I will work together with the PlatformIO developers to get proper support for all new targets there as well 🙂

PIO maintainers will add a better integration, see platformio/platform-ststm32#345 (comment)