Ich suche das Referenzmanual (STM32F4), in dem die GPIOX-Adressen und die assoziierten Register definiert sind. Also, was ist z.B. GPIOB_BASE? Danke und Gruß Christoph
Danke. Sehr umfangreiches Dokument (fast 2000 Seiten). Das soll keine Kritik sein, im Gegenteil.
Christoph K. schrieb: > Danke. Sehr umfangreiches Dokument (fast 2000 Seiten). Das soll keine > Kritik sein, im Gegenteil. Kannst du vielleicht mal etwas Kontext geben um was es dir nun genau geht und warum du gerade DAS wichtigste Dokument zur STM32F4 Entwicklung nicht findest und warum es jetzt um dessen Umfang geht? Ich komm da grad nicht ganz mit. Nochmal zur Eingangsfrage: GPIOB_BASE ist doch eine Struktur aus der StdPerihpLib, welche die Basisfunktionen der GPIO Register enthält. Es gibt auch TIMER_BASE usw. Das ist IMO keine Sache die das Datenblatt direkt erklären würde. Das Datenblatt erklärt aber die einzelnen Register, welche in GPIOB_BASE verwendet werden. Es gibt auch ein Manual zur StdPeriphLib und sicher auch zur HAL. Eventuell würde DAS deine Frage besser beantworten.
Gast
#6437796
GPIOB_BASE findet man auch nicht im RM sondern im CMSIS Header zu dem jeweiligen µC, für den F407 z.B. hier: https://raw.githubusercontent.com/STMicroelectronics/STM32CubeF4/master/Drivers/CMSIS/Device/ST/STM32F4xx/Include/stm32f407xx.h
Vergiß erst mal meine Bemerkung zum Umfang des Dokuments. Ich suche die Adresse des GPIO, das für die Programmierung der I/O-Pins von Port B (aber auch allgemein) zuständig ist. Ich will PB10/PB11 als UART3 konfigurieren. Den Wert von GPIOA_BASE=0x40020000 habe ich in einem Assemblerbeispiel gefunden. Aber diese Adressen müssen doch in einem elementaren Dokument zu finden sein. Laß es meinetwegen 2000 Seiten groß sein.
Christoph K. schrieb: > Den Wert von GPIOA_BASE=0x40020000 habe ich in einem Assemblerbeispiel > gefunden. Aber diese Adressen müssen doch in einem elementaren Dokument > zu finden sein. Laß es meinetwegen 2000 Seiten groß sein. In verlinkten Dokument findest du alle Register samt Adressen. GPIOA_BASE ist aber kein Register, sondern die Basisadresse für alle GPIOA Register. Also das 1. dieser Register sozusagen. Seite 287 zeigt dir alle GPIO Register samt Adressen (als Offset von der Basisadresse). Auf Seite 65 findest du alle Register samt Adressen. Dort findest du auch deine GPIOA Basisadresse. Siehe Bild.
Angehängte Dateien:
-
gpio.PNG
(64 KB)
Gast
#6437826
Die Quelle für die Namen und die Strukturen sind die DFP von Keil: https://www.keil.com/dd2/pack/
Johannes S. schrieb: > Die Quelle für die Namen und die Strukturen sind die DFP von Keil: > https://www.keil.com/dd2/pack/ Danke (allen). Ich möchte keinerlei Softwarepaket hinzuziehen, sondern rein mit den Herstellermanuals (ST) arbeiten.
@cyblord: Seite 65 von welchem Dokument?
Christoph K. schrieb: > @cyblord: Seite 65 von welchem Dokument? Im von mir verlinkten Reference Manual.
Cyblord -. schrieb: > Christoph K. schrieb: >> @cyblord: Seite 65 von welchem Dokument? > > Im von mir verlinkten Reference Manual. Danke. Hatte das falsche Dokument offen. Gefunden.
Christoph K. schrieb: > Johannes S. schrieb: >> Die Quelle für die Namen und die Strukturen sind die DFP von Keil: >> https://www.keil.com/dd2/pack/ > > Danke (allen). Ich möchte keinerlei Softwarepaket hinzuziehen, sondern > rein mit den Herstellermanuals (ST) arbeiten. Das ist hochgradig albern. Du sollst kein "Softwarepaket hinzuziehen", sondern das CMSIS [1] Headerfile #includieren, das deinem C Compiler die IO-Register deines µC und die Bits darin namentlich bekannt macht. [1] Cortex Microcontroller Software Interface Standard Dieser Standard wurde extra deswegen etabliert, damit man die diversen Cortex µC portabel programmieren kann. Und jeder µC-Hersteller (und oft auch die Produzenten der IDE/Toolchain) stellt die zur Verfügung. Natürlich kannst du dir diese typedefs und #defines auch selber in dein eigenes Headerfile schreiben oder - schlimmmer noch - die entsprechenden Hardware-Adressen hartcodiert in dein Programm schreiben. Nur warum? Um dann jeden Fe ler und Fipptehler erst selber suchen und finden zu dürfen? Gibt es irgendeinen Grund (abgesehen von NIH) das alles selber machen zu wollen? Oder gar zu müssen?
Gast
#6438668
"hochgradig albern" Ich will nicht die Diskussion schon wieder lostreten, ob Assembler oder C. In diesem Falle benutze ich ein C. Aus ganz zwingenden Gründen benutze ich Assembler. Ich glaube, ich ändere mal meinen Namen, damit sich in Zukunft solche Bemerkungen erübrigen. Natürlich schreibe ich die Konstanten in einen File, den ich inkludiere.
Gast
#6438676
benutzt_aus_zwingenden_Gründen_assembler schrieb: > In diesem Falle benutze ich ein C. Aus ganz zwingenden Gründen benutze > ich Assembler. Ja und? Was hindert dich daran, die CMSIS mit Assembler zu verwenden?
Gast
#6438680
ein=kein
Gast
#6438692
Zunächst mal analysiere ich gerade ein vorhandenes Paket, das jemand anderes geschrieben hat. Da muß ich die Gegebenheiten so hinnehmen, wie sie sind. Starte ich eigene Entwicklung, werde ich es sicher so machen, daß ich die CMSIS Nomenklatur verwende, die sich ja wohl deckt mit den Namen, die in der Hardware-Dokumentation verwendet werden. Aber um die Programmierung zu verstehen, möchte ich mich möglichst nah an der Hardware und der HW-Dokumentation "entlanghangeln".
Gast
#6438703
benutzt_aus_zwingenden_Gründen_assembler schrieb: > Aber um die Programmierung zu verstehen, möchte ich mich möglichst nah > an der Hardware und der HW-Dokumentation "entlanghangeln". Die CMSIS Core Bibliothek hindert dich nicht daran, da sie fast ausschließlich aus den Adressen der Register besteht. Viel mehr ist da nicht drin.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.