Here a neat small "Hello-Word LED Blinky".
This works nicely and I think any normal person can understand this quite straight forward, especially any person with STM32F4 programming background.
For this to run, you need only this main.c and the assembly file starter startup_stm32h743xx.s, which of course always is needed... .
Just one large surprise: If you compile this, this mini mini main.c still will need a compilation time of some minutes in Keil ... .
So I tried to remove the include file "stm32h7xx_hal.h", and use only the stm32H743xx.h ... you can do this if you put in 5-10 define lines from the hal environment ... .
But big surprise: Then still compilation time in the range of minutes!
Not only the Cube-MX environment is too much for such a large chip as STM32H7 (it might have its advantages for the 1000 lower pin / register count devices ... I do not want to ride it completely to the wall ... but I must admit that I hate it).
Even STM32H743xx.h in far too large.
If you look at the STM32H743xx.h, you will see quite many gimmicks in this file, which for any reasonable controller programmer are just ridiculous.
For example the following things:
- STM32F4xx.h mainly defines only the Masks for the important register bits.
- STM32H743xx.h puts a "_Msk" at andy of such Mask values, and additionally defines the "Bit-Position define" with ending "_Pos". How ridiculous is this? Convering the mask to the BitPosition is a simple makro (btw the POSITION_VAL makro with __rbit, __clz is a neat way to do this). To make it worse, for many masks they also define the mask value again without "_Msk" suffix ... presumably for compatibility with STM32F4 code (which makes quite a bit of sense of course.
- STM32H743xx.h really defines such named register names for nearly EVERY bit ... also bits and registers which are very seldom used... . Even for the 17 UR Register in the SYSCFG they define between 3 and 6 bit names for every register ... but these are USER registers ... hey, how rediculous is this ... . And of course it would be much nicer to have them in array form aUR[17] in the SYSCFG... in STM32F4xx.h usually arrays are used... the STM32H743xx.h seemed to dislike arrays, quite bizarre... .
- STM32H743xx.h to my opinion further defines MUCH TOO MUCH. I think such a header file is completely fine, if it defines all important stuff, mainly the impotant numbers (base addresses + interrupt numbers), and some futher stuff which is used in many source modules (GPIO, RCC, general Timers, NVIC, DMA, CRC, Debug, EXTI, ADC perhaps also some more important interfaces with not too many registers as SPI, I2C, USART, DAC). But mayn other modules (especially those with myriads of registers) really better should be defined in special .h files ... (except the base addresses... all "dangerous" numbers please better in one file).
So I ended up making my own small header file now (just copied the IRQn table line 64...216, the peripheral memory map 1949...2288 ... and then some important things about GPIO and RCC so far ... this gets then cumbersome ... the typedef table 2288...2558 I think also can just be copied completely ... the compiler will protest for missing typedefs only when they are actually used, not in the define lines.. ).
After this with my own header filee MySTM32H743.h, all runs quite nicely. My slime Blinky-Main.C then compiles and builds in a sub-second snap... . So lucky again :).
I hope that STM could consider to present a SlimSTM32Fxx.h file version, so that I do not have to do this myself further.
Further one BIG issue: The STM32H7 SVD files in the component packs of Keil-ARM compiler are defect, they have some clear errors, but also further, at least these packs to not install correctly. This is VERY annoying espeically for beginners, the "System Viewer" in Debugger not working ... this really is a mess ... please clear this STM (at Keil ARM page it says, that these SVD files are supplied by the "Silicon company").
And one SMALL issue but anyway nerving: In the reference Manual PDF STM32H7x3, chapter 11.4.1, Page 495, description of GPIO-MODER register, it says under the bit table, "00: Input mode (reset state)" - this is a relict from STM32F4 ... this NO MORE is "reset state"... For my Blinky main.c. this costd me several hours searching ... (as I first set the MODER bits with "|=", as I was used from STM32F4).
And one further SMALL request to the forum people:
- Please allow easy search / lookup exclusivley in STM32H7 thread
- Please allow more than 20 messages to be displayed on one screen (optionally 50 / 100 or even more, smaller font then please)
- Please allow that the first 3 message lines are shown together with the message title .. .
- Please HIDE the Email address in the message list display ... for God sake please use only the alias names ... please understand that electronics development for many companies is a very confidential and secret "future definistion business"... . It is a scary idea, that the competition might find such blogs when googling for the Email names!
And here last but not least my neat main.c for LED blinking on Nucleo-H743ZI: (you also need the startup_stm32h743xx.s .. but these 2 files are complete then):
#include "MySTM32H743xx.h" // see text above ... STM32H743xx.H is too large / cumpersome, needs minuites compile time
long lDebug; // better gloabel, so that the compiler does not optimize the for delay loop away...)
int main(void)
{
// switch on GPIOB module for 3 user LEDs (LD1: PB0, LD2: PB7, LD3: PB14
RCC->AHB4ENR |= RCC_AHB4ENR_GPIOBEN_Msk;
// important "=", not "|=" as you would possibly do in STM32F4 ...
// (the reset states are 11 for MODER in STM32H7 - they were 00 in STM32F4...)
GPIOB->MODER = GPIO_MODER_MODER0_0 |
GPIO_MODER_MODER7_0 |
GPIO_MODER_MODER14_0;
for(;;){
GPIOB->ODR = 0;
for( int i= 0; i< 10000000; i++)
lDebug++;
GPIOB->ODR = GPIO_ODR_ODR_0 |
GPIO_ODR_ODR_7 |
GPIO_ODR_ODR_14;
for( int i= 0; i< 10000000; i++)
lDebug++;
}
}
