SMT32 - Ports konfigurieren, Frage zur C-Syntax

[Unregistriert]

Jetzt hab ich mal aus Spaß einfach die letzten beiden Zeilen meines Vorposters stumpf in die main-Funktion kopiert. Wider Erwarten kommt keine Fehlermeldung was mich jetzt wiederum zu der Frage führt: Brauch ich die GPIO-Dateien um die Pins wackeln zu lassen? (Offenbar ist dem ja aber so.) Wenn ich die GPIO-Bibliothek dafür nicht brauche, wofür sind die dann gut?

Edit:
Gemeint ist natürlich die stm32f4xx_gpio.h.

Habe mich vielleicht ein bisschen unklar ausgedrückt:

Die stm32f4xx_gpio.h brauchst Du nur, wenn Du die - meiner Meinung nach abgrundtief schlechte - ST-Library nutzt. Dann musst Du diesen ganzen Unsinn mit dem Strukturen-Füllen machen.

Wenn Du aber die Register direkt beschreibst, dann kannst Du die ganzen anderen Includes weglassen. Ausschließlich die Definitionen aus der stm32f446xx.h sind nötig, damit Du die Register und Bits mit Namen ansprechen kannst.
Für den reinen Cortex-Kern kannst Du noch die CMSIS-Header einbinden.

Bei meinen Projekten mache ich es grundsätzlich so:
Von ST nutze ich:
- stm32f446xx.h
- Die CMSIS-Includes (also die core_cm4.h includen)
- startup_stm32f446xx.s (Hier stehen die Deklarationen für die Interrupthandler drin sowie der Assemblercode für die Initialisierung der statischen Variable, etc.)

Das war es auch schon.
Die Initialisierung der MCU mache ich komplett selber.
In der startup_stm32f446xx.s wird zuerst die Funktion SystemInit aufgerufen, danach dann die Funktion main.

In der von mir erstellten Funktion SystemInit initialisiere ich die MCU. Also zuerst aktiviere ich die Caches, konfiguriere den Prefetch und die Waitstates.
Anschließend konfiguriere ich die PLLs und schalte auf die entsprechende Taktquelle (meistens HSE, entweder extern -> Nucleo oder Quarz) um.

Ob man dann die Peripherie wie GPIOs, Timer, Systick, etc. in der SystemInit konfiguriert oder erst später, ist dann Geschmackssache.

[White_Fox]

Ah ja...vielen Dank, jetzt ist mir Einiges schon viel klarer, ein paar Feagen hab ich aber noch.

Was ist eigentlich die genaue Funktion des Output-Speed-Registers? Ich werd da aus dem Datenblatt nicht schlau, kann aber auch daran liegen daß ich immer noch mehr oder weniger in meiner AVR-Denke drinhänge und imemr wieder staune, um welchen Mist man sich beim ARM kümmern muß.
Muß ich das Speed-Register eigentlich beschreiben oder wird sich auch so etwas tun?

Ich muß ja, soweit ich das mitbekommen habe, den Port noch irgendwie an einen Bus anbinden. Nach was richtet man sich da, woher weiß ich wie ich da den Port am besten wo anbinde? Wie geht man da vor allem vor, wenn man etwas mehr Peripherie verwendet?

Kann meinen Code leider nicht testen, weil ich Embedded Studio nicht mit dem J-Link zusammenkriege.
J-Link Commander hat aber seltsamerweise keine Probleme mit dem J-Link zu quatschen.

#include <stdio.h>
#include <stdlib.h>
#include <stm32f446xx.h>

/*********************************************************************
*
*       main()
*
*  Function description
*   Application entry point.
*/
void main(void) {
GPIOA->MODER |= (GPIO_MODER_MODER5_0);    //A5 => Ausgang
GPIOA->OTYPER |= (GPIO_OTYPER_OT_5);      //A5 0> OpenDrain
GPIOA->PUPDR &= ~(GPIO_PUPDR_PUPDR5);     //A5 ohne Pullup-Pulldown
}

[Unregistriert]

Der Output-Speed ist für die Schaltflanken der IOs zuständig.
Er kontrolliert also die Slew-Rate (also die Anstiegs- und Abfallzeit der Flanken).
Je größer die Anstiegszeit, desto größer sind die abgestrahlten Störsignale. Daher sollte man den Output Speed nur so schnell wie nötig konfigurieren.

Das Speed-Register musst Du übrigens nicht beschreiben, nach dem Reset ist die Default-Einstellung 00 (also Low speed). Nur Port B ist da eine Ausnahme.

Die Komplexität hat übrigens nichts mit dem ARM-Kern zu tun. ST hätte auch Simpel-Peripherie wie beim AVR an den Cortex anbinden können. Aber das wäre doch Verschwendung

Was Du mit "Bus-Anbinden" meinst, verstehe ich nicht. Der Port läuft nach dem Reset sofort (bis auf die paar Ausnahmen wie JTAG, etc.). Du musst nur den Takt für den entsprechenden Port einschalten, wie auch für jede andere Peripherie.
Also z.B. für Port A:

RCC->AHB1ENR |= ( RCC_AHB1ENR_GPIOAEN );

Danach kannst Du dann ganz normal Bits setzen oder zurücksetzen:

GPIOA->BSRR |= GPIO_BSRR_BS_0;

oder

GPIOA->BSRR |= GPIO_BSRR_BR_0;

Oder meinst Du das Umlegen der Peripherie-Funktionen auf andere Pins über das AFR-Register?

Ah ja...vielen Dank, jetzt ist mir Einiges schon viel klarer, ein paar Feagen hab ich aber noch.

Was ist eigentlich die genaue Funktion des Output-Speed-Registers? Ich werd da aus dem Datenblatt nicht schlau, kann aber auch daran liegen daß ich immer noch mehr oder weniger in meiner AVR-Denke drinhänge und imemr wieder staune, um welchen Mist man sich beim ARM kümmern muß.
Muß ich das Speed-Register eigentlich beschreiben oder wird sich auch so etwas tun?

Ich muß ja, soweit ich das mitbekommen habe, den Port noch irgendwie an einen Bus anbinden. Nach was richtet man sich da, woher weiß ich wie ich da den Port am besten wo anbinde? Wie geht man da vor allem vor, wenn man etwas mehr Peripherie verwendet?

Kann meinen Code leider nicht testen, weil ich Embedded Studio nicht mit dem J-Link zusammenkriege.
J-Link Commander hat aber seltsamerweise keine Probleme mit dem J-Link zu quatschen.

#include <stdio.h>
#include <stdlib.h>
#include <stm32f446xx.h>

/*********************************************************************
*
*       main()
*
*  Function description
*   Application entry point.
*/
void main(void) {
GPIOA->MODER |= (GPIO_MODER_MODER5_0);    //A5 => Ausgang
GPIOA->OTYPER |= (GPIO_OTYPER_OT_5);      //A5 0> OpenDrain
GPIOA->PUPDR &= ~(GPIO_PUPDR_PUPDR5);     //A5 ohne Pullup-Pulldown
}