Where to start STM32H7 support

[tecnologic]

Hi all,

will get my H7 Nucleo tomorrow. Is there a small demo already? Wanted to start some coding over the holidays. HRPWM and DFSDM in one core . If DFSDM is the same as in the F7 i will make a HAL component out of my F7 code as a proposal to start with, even if nobody else uses these interfaces.

regards

Tec

[Giovanni]

There is a demo but it is just a startup that brings you to an empty main, I am working on HAL, RT and NIL do not require work and could already run but it is a bit pointless without an HAL.

Giovanni

[tecnologic]

Thanks Giovanni,

thats more than i expected. Then i start by porting GPIO driver and UART. Or if there are some hints where to start to contribute?

regards

Tec

[Giovanni]

Hi,

We need the clock tree first, then PAL and serial, then everything else, the "everything else" part will require all the help I can get

Most drivers will require a new revision, especially those using DMAs. PAL should be GPIOv2, probably the only one I will not need to touch.

Clock tree will be a bit different than usual probably, I wist to introduce "configurations", there will be a part statically configured (just like now) and another part that will be configurable at runtime, this means that some clock will be calculated at runtime depending on current settings and drivers will require an API to get the clock frequency on a specific clock point (currently all values are calculated at compile time).

In general, the current idea is:
- The state of PLLs and oscillators will be statically configured in mcuconf.h.
- The clock sources for peripheral will be statically configured in mcuconf.h.
- AHB, APB and CPU clocks will be configurable at runtime in order to allow frequency scaling.
- (tentative) add some support for halt/stop/sleep modes but it looks very complex.

Some details may change, I am still deciding things.

Giovanni

[Giovanni]

Update, clock tree is almost done. I had to change it completely compared to previous STM32s but it is much more elegant because RCC is now "orthogonal", it is more complex but easier to understand and work with.

I just hope they don't change it yet again on next devices...

Giovanni

[alex31]

H7 support is a nice Christmas gift, thank you Giovanni !

Alexandre

[Giovanni]

Well, now the LED is flashing and this is about how far it goes for Christmas.

All drivers will have to be reworked or modified, several drivers will have to be written from scratch.

Giovanni

[tecnologic]

Hi Giovanni,

i just setup my toolchain and a test project and the LED blinks! Nice job. I suppose u already started with the usart? When i have time tomorrow, i will have a look after the timers as a start. The normal TImers seem to be standard ones, for HRTIM i think an driver is needed.

Regards

Tec

[Giovanni]

Hi,

Serial should be next, I will work on that tomorrow, USARTv2 *should* work but it does not take advantage of the new FIFO mode (it should solve the performance limits of the serial driver hopefully).

If you could give a try to timer-related drivers it would be great.

Note that the HAL does not exports yet the clock frequencies macros for drivers, you may use temporary definitions in the makefile.

Giovanni

[tecnologic]

I think there is a need to change the clock naming convention for the new clock tree. I activated TIM1 as GPT and ran in the problem for the driver, the clock source. Before the clock sources where from APB1 and APB2, but for the H7 the sys_ck is the clock source. As a hack some thing like

Code: Select all

#define STM32_TIMCLK1            (STM32_HCLK)
#define STM32_TIMCLK2            (STM32_HCLK)


But according to the RCC Clock Enable Bits the Timers are hocked up to APB2/APB1.

And i have a first Fix

Code: Select all

#define rccDisableTIM1(lp) rccDisableAPB2(RCC_APB2ENR_TIM1EN, lp)
should be
#define rccDisableTIM1() rccDisableAPB2(RCC_APB2ENR_TIM1EN)