Support for Nucleo STM32F746ZG board

[ostrelkov]

Summary

I have added support for Nucleo-144 STM32F746ZG board from ST Microelectronics.

This PR fixes/implements the following features

• support for NUCLEO-F746ZG

Explain the motivation for making this change. What existing problem does the pull request solve?

Validation

• Blink
• digitalWrite
• digitalRead
• I2C by i2cdetect example
• SPI on MAX7219 led matrix driver module
• 3 user leds blink (LD1, LD2, LD3)
• user button

Code formatting
I have ran astyle.

[ABOSTM]

Hi @ostrelkov
Thanks for this PullRequest,
there is already an ongoing PR for NUCLEO_F756ZG #963;
and I updated it to support also NUCLEO_F746ZG, as both are very similar and can use the same variant.
So I tried to merge both PR (idea is to abandon this one)
Major differences are PeripheralPins.c: some choice of pin is not always the same, also I keep for now HSI as PLL source.
So can you have a look at #963 and tell us if it match your needs ?

[ostrelkov]

Hi Alexandre

I had saw PR #963 for NUCLEO_F756ZG.
Yes, you are right that NUCLEO_F756ZG and NUCLEO_F746ZG are very similar.
But not only these boards.
As written in https://www.st.com/resource/en/data_brief/nucleo-f756zg.pdf
these products are compatible:
NUCLEO-F207ZG, NUCLEO-F303ZE,
NUCLEO-F412ZG, NUCLEO-F413ZH,
NUCLEO-F429ZI, NUCLEO-F439ZI,
NUCLEO-F446ZE, NUCLEO-F722ZE,
NUCLEO-F746ZG, NUCLEO-F756ZG,
NUCLEO-F767ZI, NUCLEO-H743ZI,
NUCLEO-H753ZI, NUCLEO-L496ZG,
NUCLEO-L4A6ZG, NUCLEO-L4P5ZG,
NUCLEO-L4R5ZI.

When I ported NUCLEO_F746ZG, I used NUCLEO_F207ZG as template.

As I see from variants/NUCLEO_F756ZG/variant.h this port has less functionality then my port.
I do not have NUCLEO-144 F756ZG board to test it. But its look like only LEDs and button work in NUCLEO_F756ZG.

I tested my NUCLEO_F746ZG port with LEDs, button, I2C, SPI, Ethernet examples.
So if you are going to base on NUCLEO_F756ZG PR then you will need add corresponding pins and HAL modules.
As result you will get my "variants.h" code.
Probably you can use my PR as base and add NUCLEO_F756ZG specific code.

Moreover many ported NUCLEO-144 boards use HSI clock (see please:
variants/NUCLEO_F207ZG/variant.cpp
variants/NUCLEO_F756ZG/variant.cpp
variants/NUCLEO_F767ZI/variant.cpp
and others).
It is not mistake, but HSE clock usage is more correct. (as recommended in https://github.com/stm32duino/wiki/wiki/Add-a-new-variant-(board) ).
So I used external crystal in differ from NUCLEO_F756ZG.

Of course, I am ready to test merged version of NUCLEO_F756ZG and NUCLEO_F746ZG.

With best regards,
Oleg.

[ABOSTM]

Hi @ostrelkov,

Yes, you are right that NUCLEO_F756ZG and NUCLEO_F746ZG are very similar.
But not only these boards.

NUCLEO_F756ZG and NUCLEO_F746ZG are not only boards compatible but also chipset compatible: they both have the same clock tree, they have the same peripheral on the same pin, they use the same HAL ... this is why we can use the same variant. It is not the case for the other boards you mentioned.

As I see from variants/NUCLEO_F756ZG/variant.h this port has less functionality then my port.

No, they both support I2C, SPI, ..., But as we use default generic I2C/SPI pins (see https://github.com/stm32duino/Arduino_Core_STM32/blob/master/cores/arduino/pins_arduino.h) it is not necessary to overload those pin definition in the variant.

So if you are going to base on NUCLEO_F756ZG PR then you will need add corresponding pins and HAL modules.

No: There is a number of modules already defined by default: see https://github.com/stm32duino/Arduino_Core_STM32/blob/master/cores/arduino/stm32/stm32yyxx_hal_conf.h

It is not mistake, but HSE clock usage is more correct.

I checked wit @fpistm, and even if in the past, we used HSI for such Nucleo board (as user may separate STLink part of the board which provide the clock for HSE Bypass),
it is ok to use HSE. So I updated #963 to use HSE.

Of course, I am ready to test merged version of NUCLEO_F756ZG and NUCLEO_F746ZG.

It is very kind of you

[ostrelkov]

Hi, Alexandre

Yes, I understood you.
I didn't know that so many modules is defined by default.

If you need my participation, let me know.

With best regards,
Oleg

[ABOSTM]

Hi Oleg,
If you can use the PR #963, and tell us if it matches with your needs. The choice of commented lines in PeripheralPins.c is partially arbitrary, so there is room for negotiation 😃

[fpistm]

@ostrelkov
any feedback on the choice of commented lines in PeripheralPins.c ?
Anyway it could be updated later or customized to fit your needs as it is a weak array.

[ostrelkov]

Hi, all

I tested proposed PR today. All peripheral devices works properly (tested I2C, SPI, LEDs, button, Ethernet).

[ABOSTM]

Hi @ostrelkov ,
Thanks for your feedback.
So we can close this PR as replaced by #963