Wohin mit CMSIS und STM Periphery Lib?

[Masl (Gast)]

Ja, Titel sagt eigentlich alles.

Ich benutze arm-none-eabi-gcc unter unixoiden Systemen, momentan bin ich 
bestrebt, mein Discovery mit der GNU Toolchain zum laufen zu bringen 
(eigenes makefile et.)
Da die CMSIS + die STM-Lib ja eigentlich eher eine Sammlung von 
Funktionen denn eine "richtige" Library sind dachte ich, ich pack das 
Zeug ins Projektverzeichnis. Auch weil dort .c und .s Dateien dabei 
sind, die ja mitkompiliert werden.

Gestern hatte ich aber einen Fehler, der mich einige Zeit aufgehalten 
hat:
Beim Versuch, das c-File mit der System_Init (system_xxxxx.c" Funktion 
zu kompilieren fand der gcc einige Header nicht, die definitiv vorhanden 
waren.
Ein Blick ins c-File zeigte, dass Header aus der CMSIS per <> anstatt "" 
eingebunden werden.
Habs mal testweise abgeändert, jetzt passts.

Allerdings frage ich mich, was die Idee dahinter ist. Sollten diese 
Header eher ins Installationsverzeichnis des Compilers? Kommt mir 
komisch vor. Es kann aber auch ned Sinn sein, wild in den von STM 
ausgelieferten Sourcen zu editieren.
Wo legt ihr bei euch die CMSIS und STM Lib ab?

Viele Grüße!

[Juergen (Gast)]

Sowas kommt am Besten jeweils in ein eigenes Unterverzeichnis unter 
Thirdparty im Projekt.

Dann musst du nur noch dem Compiler mit Hilfe der Option -I erklären, 
dass er seine Includes da suchen soll, und dem Linker mit -L wo die 
Libraries sind.

Nur wenn man selbst daran Änderungen macht (häufig bei system_xxx.c der 
Fall) kopiert man das zu den eigenen Sourcen.

[Masl (Gast)]

Ah ok, dann werd ich das im Makefile per -I lösen.
Mir kamen eben die <> komisch vor, das riecht immer so nach 
Compilerverzeichnis.

[Dr. Sommer (Gast)]

Masl schrieb:
> Allerdings frage ich mich, was die Idee dahinter ist. Sollten diese
> Header eher ins Installationsverzeichnis des Compilers?
Wat? Nur weil das eine Library ist die in den Compiler werfen?? Wenn du 
ein UNIX wie Linux benutzt schau doch mal in den Ordner /usr/include. Da 
sind 1.000.000 Header-Dateien von allen möglichen Libraries, die alle 
per <> #includiert werden, sich aber nicht im Compiler-Verzeichnis 
befinden... Es werden dann per -I bzw. -L (für /usr/lib) die Pfade 
angegeben.

Masl schrieb:
> Mir kamen eben die <> komisch vor, das riecht immer so nach
> Compilerverzeichnis.
Nö, nur nach "gehört nicht direkt zu dieser Source".

Dem UNIX-Prinzip folgend müsstest du die Header theoretisch nach 
/usr/include/irgendwas packen, die Sourcen vorkompilieren und die 
Library Files (.a) nach /usr/lib/irgendwas werfen. Allerdings ist es bei 
so Embedded Zeug nicht immer so praktisch, vorkompilierte Libraries 
einzubinden, da man ja öfters mal Compiler-Optionen ändert o.ä. und dann 
die Library manuell neucompilieren müsste.

Daher ist das wohl tatsächlich am praktikabelsten:
Juergen schrieb:
> Sowas kommt am Besten jeweils in ein eigenes Unterverzeichnis unter
> Thirdparty im Projekt.
Ich würds wohl lieber "librarys" nennen, denn es können ja auch 
Libraries von einem selber drin sein...
Es ist zwar ein bisschen blöde dass man die Sourcen dann in jedes 
einzelne Projekt rüberkopieren muss und beim Finden eines Bugs die alle 
korrigieren muss, aber leider sind die Alternativen auch nicht besser.

Masl schrieb:
> Auch weil dort .c und .s Dateien dabei
> sind, die ja mitkompiliert werden.
Die .s Dateien sind startupcodes, die darfst du aber nicht einfach alle 
mitassemblisieren... Da musst du den einen richtigen finden und 
verwenden (oder gleich einen eigenen schreiben). Schlauerweise sind in 
den Archiven für die Standard Peripheral Library immer noch jede Menge 
Müll drin wie Examples, Projekt Templates etc., die muss man immer erst 
rauswerfen bevor man drauf los kompiliert.