Hallo zusammen,
gibt es beim GCC eine Möglichkeit, per Präprozessor-Direktive zu
erkennen, ob für einen Cortex M0, M3 oder M4 kompiliert wird?
Beim Keil-Compiler wird durch die Toolchain __CORTEX_M0, __CORTEX_M3,
__CORTEX_M4 definiert, beim GCC nicht.
Gibt es beim GCC entsprechendes, oder läuft es darauf hinaus, eine
entsprechende Präprozessorvariable selbst definieren zu müssen?
Oder anders gefragt: Wie stellt ihr fest, welche Intrisics für die
Ziel-Plattform zur Verfügung stehen? Wie wählt ihr die richtige
Header-Datei aus?
Walter T. schrieb:> Oder anders gefragt: Wie stellt ihr fest, welche Intrisics für die> Ziel-Plattform zur Verfügung stehen? Wie wählt ihr die richtige> Header-Datei aus?
Die Trennung nach M0/M3/M4... deckt ja nur einen winzigen Teil der
Unterschiede von Chip zu Chip ab, jeder braucht seine eigenen
Definitionen für die Hardware. Also gibt es hier ein Verzeichnis pro
Chip. Bei allen M0-Chips steht da eine Kopie von "core_cm0.h" drin, bei
den M3-Chips eine von "core_cm3.h"... Die Kopie heißt hier aber immer
"asm.h".
Im Makefile wird das passende Chip-Header-Verzeichnis mit der Option
"-I" angegeben und in den Quellen steht immer "asm.h".
So quasi das Gegenteil von deinem Wunsch ist wahrscheinlich möglich. Ein
Quell-Datei kann angeblich die gcc-Option "-mcpu" umschalten:
https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html
Im Grunde steckt doch alles in den CMSIS-Core Headern drin, auf denen
jeder Hersteller dann seine ominösen Libraries aufbaut. Hast du z.B.
einen STM32F446, dann wird (zumindest indirekt) irgendwo per #include
eine "stm32f4xx.h" eingebunden. Dieser Header bindet dann wiederum je
nachdem welcher #define für das eigentliche Device gesetzt ist einen
spezifischeren Header ein. Für den F446 ist es "stm32f446xx.h" und hast
du einen F407, dann ist es "stm32f407xx.h". In diesen
(Device-spezifischen) Header-Dateien wird der passende Header für den
Cortex-M Kern eingebunden, das heißt in diesem Beispiel (egal ob F407
oder F446) jeweils "core_cm4.h". In dieser "core_cm4.h" gibt es dann
direkt ein
1
#define __CORTEX_M (4U)
Wie genau die #defines für die anderen Cortex-M sind kannst du jeweils
in der "core_cmX.h" herauslesen. Jedenfalls wird diese "core_cmX.h" ganz
automagisch indirekt über den Device-Header eingebunden und das ist
(soweit ich weiß) immer der Fall, nicht nur bei ST.
Das stimmt zwar - aber wie nützt das?
Wie würdest Du die Defines und Includes einer *.C- und der zugehörigen
*.H-Datei machen, die als "mathematische Library" Funktionen, die in
Integer/Float32 gerechnet werden, zur Verfügung stellt?
Wenn ich für den Cortex M4 kompiliere, will ich die sättigenden
Operationen und die Multiply-Accumulate natürlich nutzen, wenn ich für
Windows kompiliere, soll natürlich der Ersatzcode für die M0/M3 zum
Einsatz kommen.
Im Wesentlichen läuft das ja darauf hinaus, den richtigen Header zu
includieren. Danach kann ich fallweise prüfen, ob die Intrinsics, die
ich für eine Operation brauche, definiert sind und Ersatzcode
bereitstellen (der GCC scheint ja die Idiome [noch?] nicht zu erkennen).
Walter T. schrieb:> Wenn ich für den Cortex M4 kompiliere, will ich die sättigenden> Operationen und die Multiply-Accumulate natürlich nutzen, wenn ich für> Windows kompiliere, soll natürlich der Ersatzcode für die M0/M3 zum> Einsatz kommen.
Du willst also wissen, ob es gesättigte Arithmetik gibt, findest aber
die dafür richtige Abfrage nach exakt dieser Feature per
__ARM_FEATURE_SAT seltsam und bevorzugst die falsche Frage nach dem
Core?
In einer bunten IDE klickst du irgendwo den gewünschten µC an. Die
deklariert dann das Makro.
Wenn du zu Fuß unterwegs bist, musst du es selber setzen. Egal, ob mit
Keil oder GCC. Der Compiler kann deinen µC nicht erraten. Oder du nimmst
den spezifischen Header für genau den µC. Da steckt es i. d. R. auch
drin.
Seher schrieb:> In einer bunten IDE klickst du irgendwo den gewünschten µC an. Die> deklariert dann das Makro.> Wenn du zu Fuß unterwegs bist, musst du es selber setzen. Egal, ob mit> Keil oder GCC. Der Compiler kann deinen µC nicht erraten. Oder du nimmst> den spezifischen Header für genau den µC. Da steckt es i. d. R. auch> drin.
Egal ob IDE oder makefile, der Compiler will schon wissen ob er M3 oder
M4 Code erzeugen soll. ARM ist nur bedingt gleich ARM.
Carl D. schrieb:> Egal ob IDE oder makefile, der Compiler will schon wissen ob er M3 oder> M4 Code erzeugen soll.
Was verstehst du daran nicht?
Seher schrieb:> Der Compiler kann deinen µC nicht erraten.
A. K. schrieb:> Du willst also wissen, ob es gesättigte Arithmetik gibt,
Das auch - aber das war nicht meine Frage, weil es sich einfach
herausfinden läßt. Meine Frage bezog sich darauf, den richtigen Header
einzubinden.
Carl D. schrieb:> der Compiler will schon wissen ob er M3 oder> M4 Code erzeugen soll. ARM ist nur bedingt gleich ARM.
<Klugscheissmodus>
Es geht um Cortex und nicht reinen ARM. Code für den M0 ist ohne
Änderung auf einem M3 oder M4 lauffähig. Das ist ein Entwicklungsprinzip
der ARM-Company. Frag sie mal.
</Klugscheissmodus>
Walter T. schrieb:> Das stimmt zwar - aber wie nützt das?>> Wie würdest Du die Defines und Includes einer *.C- und der zugehörigen> *.H-Datei machen, die als "mathematische Library" Funktionen, die in> Integer/Float32 gerechnet werden, zur Verfügung stellt?
Sorry, ich hatte die Frage nicht richtig verstanden. Was ich geschrieben
habe ist für deine Anwendung natürlich quatsch. Die passendste Antwort
hat denke ich Markus direkt zu Beginn gegeben.
Thread beobachten
Seitenaufteilung abschalten