STM32 Header

[dünnwandiger Trog (Gast)]

Ich suche Headerfiles für ein paar STM32. Die CMSIS kompatiblen Header 
kann man ja hier herunterladen

https://github.com/modm-io/cmsis-header-stm32

aber ich möchte, wie auch in diesem Thread besprochen

Beitrag "STM32 Header Files"

nicht diese ganzen struct-Dinger, sondern es wäre mir am liebsten, wenn 
ich einen Headerfile hätte, der wirklich nur "nackte" Register 
beschreibt, also statt mit structs so arbeitet:

...
#define PWR_CR (*(volatile uint32_t*)0x40007000)
#define PWR_CSR (*(volatile uint32_t*)0x40007004)
#define RCC_CR (*(volatile uint32_t*)0x40023800)
#define RCC_PLLCFGR (*(volatile uint32_t*)0x40023804)
#define RCC_CFGR (*(volatile uint32_t*)0x40023808)
#define RCC_CIR (*(volatile uint32_t*)0x4002380C)
...

und so weiter. Also ohne überlagerte Strukturen.
Ich glaube, fertig findet man so etwas nicht, daher frage ich mich, wie 
ich am einfachsten aus den vorhandenen STM32 Headers diese andere 
Struktur bauen könnte. Ich habe überlegt, mit GNU M4 das irgendwie 
umzuformatieren, aber meine Programmierkenntnisse reichen dazu nicht 
aus. Auch habe ich überlegt, die SVD Files zu nehmen und zu .h zu 
konvertieren, aber in dem oben verlinkten Thread habe ich gelesen, dass 
man sich auf die SVDs nicht verlassen soll.

Also wie komme ich am einfachsten zu einem vernünftigen Header?
einen für den STM32F407 habe ich schon, der so formatiert ist. Ich habe 
aber keine Ahnung mehr, woher ich diesen habe.

[A. B. (Gast)]

Das wird spätesten dann recht unpraktisch, wenn es von irgendeiner 
Funktionseinheit mehr als ein Exemplar gibt. Bei der RCC, nun gut, da 
ist's immer nur eine.
Aber ein Dutzend Definitionen für Timer1, Timer3, ... ist doch etwas 
nervig?!

[so isses (Gast)]

Wer keine Arbeit hat der macht sich welche schrieb im Beitrag #7013622:
> Wie kann man sich
> das Leben nur so schwer machen?

Das machen die Leute die noch keine Ahnung haben und sonst noch
nichts mit diesen Controllern gemacht haben. Die fallen später
bei umfangreicheren Projekten automatisch rein und kehren dann
reuemütig zu irgendeiner Sammlung vorgefertigter Header-Dateien
zurück.

[Bauform B. (bauformb)]

dünnwandiger Trog schrieb:
> Die CMSIS kompatiblen Header kann man ja hier herunterladen

ST ist seit geraumer Zeit auch selbst bei github
https://github.com/STMicroelectronics/STM32Cube_MCU_Overall_Offer

Und was die structs angeht, meine erste Reaktion auf diese riesigen 
CMSIS Header war genau wie deine: das ist ja grauenhaft, das muss doch 
einfacher gehen. Nach ein paar Irrwegen habe ich jetzt für jedes Modul 
ein eigenes kleines File, z.B.:

// wwdg.h

// Copyright (c) 2017 STMicroelectronics. All rights reserved.
// Source: stm32l412xx.h by MCD Application Team

// Converted 2020-03-26 11:20:41

#pragma once
#include <stdint.h>

// Window WATCHDOG

typedef volatile struct wwdg_struct {

// 0x00  WWDG_CR  WWDG Control register
   uint32_t  T       :  7; //  0  T[6:0] bits (7-Bit counter (MSB to LSB))
   uint32_t  WDGA    :  1; //  7  Activation bit
   uint32_t          : 24;

// 0x04  WWDG_CFR  WWDG Configuration register
   uint32_t  W       :  7; //  0  W[6:0] bits (7-bit window value)
   uint32_t  WDGTB   :  2; //  7  WDGTB[1:0] bits (Timer Base)
   uint32_t  EWI     :  1; //  9  Early Wakeup Interrupt
   uint32_t          : 22;

// 0x08  WWDG_SR  WWDG Status register
   uint32_t  SR;    //  1; //  0  Early Wakeup Interrupt Flag
} wwdg_struct;
_Static_assert (sizeof(wwdg_struct) == 12, " wwdg_struct: bad size");

static wwdg_struct * const WWDG = (wwdg_struct *)0x40002c00;

Dass hier kein #define auftaucht ist kein Zufall. Dank der struct mit 
Bitfeldern gibt es in allen meinen STM32-Headern kein einziges #define 
mehr.

Auch, wenn es einmal viel Fleißarbeit war, am Ende haben sich die 
structs als wirklich brauchbare Lösung rausgestellt.

[utzutr (Gast)]

das sollte man mal auftrennen

also die registerzugriffe über structs sind in summe nur ein pointer
das tut nicht weh ..
der Cortex M ist bei pointern sogar schneller als einzelne load&tore 
zugriffe

was man nicht zwingend brauch und der schmerz bei ganz vielen ist sind 
die structs der HAL
diese stukturen liegen schön im RAM und verbrauchen speicher ...

Die kann man aber vermeiden indem man die CMSIS ganz normal nutzt ..
aber ohne HAL

es bleibt dann nur ein zugriff über lokale pointer variable

[PittyJ (Gast)]

Bauform B. schrieb:
> // Window WATCHDOG
> typedef volatile struct wwdg_struct {
> // 0x00  WWDG_CR  WWDG Control register
>    uint32_t  T       :  7; //  0  T[6:0] bits (7-Bit counter (MSB to
> LSB))
>    uint32_t  WDGA    :  1; //  7  Activation bit
>    uint32_t          : 24;
> // 0x04  WWDG_CFR  WWDG Configuration register
>    uint32_t  W       :  7; //  0  W[6:0] bits (7-bit window value)
>    uint32_t  WDGTB   :  2; //  7  WDGTB[1:0] bits (Timer Base)
>    uint32_t  EWI     :  1; //  9  Early Wakeup Interrupt
>    uint32_t          : 22;
> // 0x08  WWDG_SR  WWDG Status register
>    uint32_t  SR;    //  1; //  0  Early Wakeup Interrupt Flag
> } wwdg_struct;
> _Static_assert (sizeof(wwdg_struct) == 12, " wwdg_struct: bad size");
> static wwdg_struct * const WWDG = (wwdg_struct *)0x40002c00;
> Dass hier kein #define auftaucht ist kein Zufall. Dank der struct mit
> Bitfeldern gibt es in allen meinen STM32-Headern kein einziges #define
> mehr.

Ich bleibe da schön bei der HAL. Für den Watchdog waren nur ca 4 Aufrufe 
der HAL-Funktionen nötig. Die machen genau das, was ich brauche. Die 
Sache war nach 2 Stunden implementiert und getestet.
Da interessieren mich die Register überhaupt nicht. Ich will mich nicht 
mit Bits rumschlagen, wenn das STM schon für mich erledigt hat. An 
welcher Adresse der Watchdog liegt? Keine Ahnung, will ich nicht wissen. 
Das gibt dann höchstens Zahlendreher.

Mein H743 hat 1 MByte Ram. Da können auch mal 12 Byte für die HAL 
verschwendet werden.
Aber ich bekomme schnell eine funktionierende Lösung ohne viel 
Debugging.