Hallo,
ich habe mir ein NUCLEO-F767ZI Board mir dem STM32F767ZI zugelegt.
Zur Entwicklung nutze ich Eclipse mit dem GNU MCU Eclipse Plugin sowie
der GNU Arm Embedded Toolchain.
Die Generierung des HEX Files eines leeren Programms in C (nur die main
mit einer Dauerschleife) sowie das Uploaden auf den STM hat mittels der
STM32 ST-LINK Utility auch perfekt funktioniert.
Nun wollte ich einfach mal die LED0 (Port B Pin 0) zum leuchten bringen.
Dafür habe ich mir ein paar Beispiele als Ausgangspunkt im Internet
gesucht.
Z.B.
1
GPIO_InitTypeDef gpio;
2
SET_BIT(RCC->AHBENR, RCC_AHBENR_GPIOEEN);
3
4
// Configure one of the LEDs as a digital output
5
GPIO_StructInit(&gpio);
6
gpio.GPIO_Pin = GPIO_Pin_10;
7
gpio.GPIO_Mode = GPIO_Mode_OUT;
8
gpio.GPIO_Speed = GPIO_Speed_2MHz;
9
GPIO_Init(GPIOE,&gpio);
http://mcuhq.com/30/stm32f3-discovery-board-setup-using-eclipse-on-windows
Nun musste ich aber feststellen, dass alle Beispiele leicht andere
Bezeichnungen der Register und Bits haben als wie diese in meinen Header
Dateien.
Zwei Beispiele:
-Die Member der GPIO_InitTypeDef Struktur hat in den Beispielen immer
Bezeichnungen die mit GPIO_... anfangen.
Bei mir ist die GPIO_InitTypeDef zwar auch in der "stm32f7xx_hal_gpio.h"
Header definiert jedoch fehlt dort das vorgestellte GPIO_...
-Im Beispiel wird GPIO_Pin_10 benutzt.
Bei mir heßt es aber GPIO_PIN_10.
Also müsste ich das Beispiel oben folgendermaßen abändern.
1
GPIO_StructInit(&gpio);
2
gpio.Pin = GPIO_PIN_10;
3
gpio.Mode = GPIO_MODE_OUTPUT_PP;
4
gpio.Speed = GPIO_SPEED_FAST;
5
GPIO_Init(GPIOE,&gpio);
Zu dem oberen Teil
1
GPIO_InitTypeDef gpio;
2
SET_BIT(RCC->AHBENR, RCC_AHBENR_GPIOEEN);
war es mir nicht möglich herauszufinden wie die bei mir heißen.
Könnte mich vielleicht jemand aufklären warum zum Teufel das bei mir
leicht anders benannt ist oder wo ich vielleicht eine Doku zu meinen
Definitionen finde, sodass ich überhaupt irgendwas Programmieren kann.
Es ist einfach total frustrierend und ich komme so überhaupt nicht
voran, wenn ich jedesmal Raten muss wie das bei mir vielleicht umbenannt
wurde.
Leider werden die Bibliotheken bei ST scheinbar von unterschiedlichen
Teams entwickelt. Die Namensgebung von Registern, Funktionen, usw. ist
oft recht... "locker" gehalten und folgt nicht immer dem selben Schema.
Anstatt im Netz nach Beispielen zu suchen wäre es vielleicht nicht
schlecht sich das STM32CubeMX Tool zu saugen und sich dort die
entsprechenden Beispiele bei der F7-Bibliothek anzusehn.
Michael schrieb:> oder wo ich vielleicht eine Doku zu meinen> Definitionen finde, sodass ich überhaupt irgendwas Programmieren kann.
Ganz einfach: Verlasse dich nicht auf Vorgekautes a la
"GPIO_StructInit(&gpio);" und dergleichen.
Verlasse dich lieber auf die Bezeichnungen, die im jeweiligen
Referenzmanual verwendet werden.
Und wenn deine Headerdatei die nicht wiedergibt, sondern einen Sack
anderweitiger Bezeichner einführt, dann verzichte einfach auf so eine
Murks-Headerdatei.
Ich mache das schon seit langem und fahre dabei gut. Aber das mußt du
dir selber abwägen, ob du das, was im RefMan steht, dir selber
extrahierst und dir dein eigenes Zeugs draus machst - oder ob du lieber
tagelang mit irgendwelchen vermurksten Headern von anderer Herkunft dich
herumschlagen willst. Beides kostet Zeit.
Weißt du, ich predige hier schon seit Jahren den Leuten: Seid SELBST
potent, lernt auf eigenen Beinen zu stehen, euren eigenen Weg euch zu
bahnen und eure Muse selber zu bumsen! (anstatt sich hinter den
Rockzipfel irgend einer selbsternannten Amme zu verkriechen)
Manche kapieren das und von denen hört man hier kaum was wieder, weil
sie gelernt haben, ihre Probleme selbst zu lösen - und die anderen
bevölkern weiterhin dieses Forum, aber um die ist es nicht schade.
W.S.
W.S. schrieb:> Michael schrieb:>> oder wo ich vielleicht eine Doku zu meinen>> Definitionen finde, sodass ich überhaupt irgendwas Programmieren kann.>>> Weißt du, ich predige hier schon seit Jahren den Leuten: Seid SELBST> potent, lernt auf eigenen Beinen zu stehen, euren eigenen Weg euch zu> bahnen und eure Muse selber zu bumsen! (anstatt sich hinter den> Rockzipfel irgend einer selbsternannten Amme zu verkriechen)>
Ja, dein Missionarseifer ist hinlänglich bekannt und grenzt zum Teil
beidseitig ans unerträgliche.
Oft hast Du zwar Recht, aber hier hat scheints bei Dir einfach nur etwas
eine offene Schublade bei Dir gefunden.
Es macht überhaupt keinen Sinn, sich seine eigenen Definitionen zu
schreiben, ist nur Tipptraining ohne Sinn und Verstand. Und ausser Dir
hat glaube ich Niemand gelesen, dass der TO hier nur Copy-und-Paste
Übungen ohne Verständnis der Architektur will. Im Gegenteil hat er sich
m.M. nach schon Gedanken darüber gemacht, was die Register und deren
Bits bedeuten. Aber deswegen stundenlang seine eigenen #defines zu
tippen ist nun wirklich so unnötig wie ein Kropf.
> Manche kapieren das und von denen hört man hier kaum was wieder, weil> sie gelernt haben, ihre Probleme selbst zu lösen - und die anderen> bevölkern weiterhin dieses Forum, aber um die ist es nicht schade.>
Meine Güte, was ein Kläffterrier. Man zieht an der Klostrippe, und bei
Dir überschwemmt es irgendwas. Muss doch nun wirklich nicht sein, oder?
@Michael: Ja, ist ein bekanntes Problem. Wo mehrere Ökosysteme
unabhängig voneinander erstellt wurden, gibt es leider auch
unterschiedliche Sichtweisen, Vorlieben und Ansätze. Ist halt so.
Nix abtippen, mach' copy+paste aus dem Reference Manual. Das ist
schließlich die Referenz. Irgendwelche Bibliotheken und schlechte
Beispiele aus dem Internet sind im Zweifelsfall falsch.
Mach' copy+paste aus dem Reference Manual, das musst du ja sowieso
lesen. Keine Angst, auch mit den richtigen Definitionen gibt es noch
genug Bugs ;)
Von STM gibt es die ältere SPL, Standard Peripherial Library und die
neuere HAL, Hardware Abstraction Layer. Ich habe deine Beispiele jetzt
nicht genau verglichen, eventuell hast du Beispiele aus diesen beiden
gefunden. Die SPL ist zwar älter aber trotzdem bei einigen beliebter.
Und davor gab es noch eine FWLib, Firmware Lib.
Das ist SPL:
> GPIO_InitTypeDef gpio;> SET_BIT(RCC->AHBENR, RCC_AHBENR_GPIOEEN);>> // Configure one of the LEDs as a digital output> GPIO_StructInit(&gpio);> gpio.GPIO_Pin = GPIO_Pin_10;> gpio.GPIO_Mode = GPIO_Mode_OUT;> gpio.GPIO_Speed = GPIO_Speed_2MHz;> GPIO_Init(GPIOE,&gpio);
und das ist HAL:
> GPIO_StructInit(&gpio);> gpio.Pin = GPIO_PIN_10;> gpio.Mode = GPIO_MODE_OUTPUT_PP;> gpio.Speed = GPIO_SPEED_FAST;> GPIO_Init(GPIOE,&gpio);
Wie Johannes schon sagte sind SPL und HAL zwei völlig verschiedene
Frameworks von ST. Die SPL wird nicht mehr weiterentwickelt und ist für
L0, L4 und F7 gar nicht verfügbar.
Es gibt für die jeweiligen HAL-Libraries ein User-Manual. Für den F7
wäre es das hier: www.st.com/resource/en/user_manual/dm00189702.pdf
Da findest du dann im Kapitel 26 "GPIO Generic Driver" den Unterpunkt
26.2.2 "How to use this driver".
Adapter schrieb:> Es macht überhaupt keinen Sinn, sich seine eigenen Definitionen zu> schreiben, ist nur Tipptraining ohne Sinn und Verstand.
Nein, man versteht den Controller dann besser. Zudem abstrahiert die HAL
entgegen ihrem Namen nichts, sondern benennt nur Register um. Was die
möglichen Optionen tun, entnimmt man dann, tadaa, dem Refman. Das muß
man also sowieso lesen.
> Meine Güte, was ein Kläffterrier. Man zieht an der Klostrippe, und bei> Dir überschwemmt es irgendwas. Muss doch nun wirklich nicht sein, oder?
Er hat doch recht. Jedesmal "mimimi, ich hab Angst vor Registern, mimimi
die HAL geht nicht wie gedacht". Nein, tut sie auch nicht, weil sie ein
Obfuscation Layer mit dem einzign Zweck des vendor lock-in ist.