AVR-gcc mehrere Source-Dateien

[John L (Gast)]

Hallo! Ich hab ein C-Projekt, wo ich die UART-Funktionen in eine 
separate Source-Datei (uart.c/uart.h) ausgelagert habe. IDE ist 
Microchip Studio 7.

Das ganze klappt aber nur, wenn ich die meisten Include-Dateien aus der 
main.c nochmals in der uart.c inkludiere. Selbst für die Header-Datei 
mit den Prototypen muss die <inttypes.h> nochmals eingebunden werden, 
damit ein Funktions-Prototyp mit (u)intXY_t-Datentypen wie z.B.

void uart_puti(int16_t value);

ohne Error kompiliert.

Da stellt sich mir die Frage, ob das nicht auch den Maschinencode 
aufbläht durch doppelt/dreifach eingebundene Includes?

Weitere Frage: sollte man ISRs mit mehreren "volatile extern"-Variablen 
auch auslagern oder ist das bad practice?

[Rolf M. (rmagnus)]

John L schrieb:
> Hallo! Ich hab ein C-Projekt, wo ich die UART-Funktionen in eine
> separate Source-Datei (uart.c/uart.h) ausgelagert habe. IDE ist
> Microchip Studio 7.
>
> Das ganze klappt aber nur, wenn ich die meisten Include-Dateien aus der
> main.c nochmals in der uart.c inkludiere. Selbst für die Header-Datei
> mit den Prototypen muss die <inttypes.h> nochmals eingebunden werden,
> damit ein Funktions-Prototyp mit (u)intXY_t-Datentypen wie z.B.void
> uart_puti(int16_t value);
> ohne Error kompiliert.

Ja. Deswegen gibt es ja Header-Dateien.

> Da stellt sich mir die Frage, ob das nicht auch den Maschinencode
> aufbläht durch doppelt/dreifach eingebundene Includes?

Nein. In den Headern stehen ja normalerweise nur Informationen für den 
Compiler, die später im Programm gar nicht drin sind.

> Weitere Frage: sollte man ISRs mit mehreren "volatile extern"-Variablen
> auch auslagern oder ist das bad practice?

Ich würde die ISR in das File stecken, in dem auch die dazugehörige 
Hardware behandelt wird.

[John L (Gast)]

Danke!
Noch ne Frage, ich habe einige GPIO-Funktionen (Nur Register 
Lese/Schreib-Operationen) zuvor in der main.c mit [i]inline[/i] 
deklariert, um nicht immer Rücksprünge etc. im Programmablauf zu 
erzeugen und effizienteren Code zu haben.
Inwieweit lassen sich diese Funktionen in eine andere Source-Datei 
auslagern, sodass der Funktionsinhalt trotzdem inline in den 
Maschinencode kommt?

[Le X. (lex_91)]

Wird schwierig.
Mit LTO (Link-time-optimization) könnte das klappen, aber nur wenn die 
zu schreibenden Register/Werte zur Compilezeit bekannt sind.
Dann kann der Compiler/Linker auch Sourcefile-übergreifend optimieren.

Ansätze, GPIO-Zugriffe in Funktionen zu kapseln gibt es viele.
Leider sind sie in der Regel ineffizienter als direkt die Register mit 
Bitmanipulation zu beschreiben.
Aber wie gesagt, in bestimmten Konstellationen ist es möglich dass der 
resultierende Code genauso effizient ist.

Du musst auf jeden Fall den generierten asm-Code überprüfen.

[Oliver S. (oliverso)]

gcc ignoriert das Keyword inline sowieso, und inlined nur, was er selber 
für richtig hält. Zwingen müsstest du ihn schon per 
__attribute__((always_inline)).

Dein Problem löst -flto.

Damit kennt der Compiler zur Compilezeit alle Sourcen, und kann alles 
inlinen, egal, wo es steht.

Oliver

[Jörg W. (dl8dtl) (Moderator)]

Oliver S. schrieb:
> Damit kennt der Compiler zur Compilezeit alle Sourcen, und kann alles
> inlinen, egal, wo es steht.

Nicht ganz.

Zur Compilezeit alle Quellen würde gehen, wenn man sie alle auf einmal 
auf der Kommandozeile angibt und dann -fwhole-program benutzt.

-flto compiliert und linkt erst einmal normal, schickt danach aber noch 
einmal den Compiler über das Ergebnis mit dem Ziel, Dinge zu 
vereinfachen, die sich beim getrennten Compilieren so nicht erkennen 
ließen.

[Oliver S. (oliverso)]

Jörg W. schrieb:
> -flto compiliert und linkt erst einmal normal,

Jein. Der erste Schritt auf Sourcedateiebene erzeugt GIMPLE-Code, und 
der wird dann final über alle Dateien wirklich compiliert.

Oliver