wohin mit #define-Configs?

[Michael R. (Firma: Brainit GmbH) (fisa)]

Hallo zusammen,

folgende Frage:

ich hab ein AVR-"Modülchen" namens uart.c/uart.h, sehr simpel, besteht 
im Wesentlichen aus einer uart_init() und einer uart_put(). Da ich die 
fast überall brauche, liegt sie eben in einem eigenen .c/.h-File.

Nun braucht das Ding zwei "Konfigurationsvariablen", einmal die baudrate 
(die ich dann per #include <util/setbaud.h> auswerte) und die Größe des 
Sendepuffers.

nun wäre mir folgendes am liebsten: in der main.c (also quasi dem 
"Hauptprogramm" des AVR) folgendes hinschreiben:

#define BAUD 19200
#define UART_BUFFER_SIZE 64
#include "uart.h"

das geht so natürlich nicht (außer ich hab den C-Code im Header-File, 
was man ja nicht tut), weil die uart.c eine eigene Compile-unit ist.

Ich könnte die Variablen natürlich im Makefile definieren (so wie 
F_CPU), damit stünden diese aber allen modulen zur Verfügung, was zwar 
nicht weiter stört, aber doch irgendwie unschön ist.

weiters könnte ich eine "config.h" erfinden, wo das drinnensteht, und 
diese in der uart.c inkludieren. Reisst mich auch nicht wirklich vom 
Hocker...

Wie macht "man" das am besten? Wie macht ihr das?


Danke, Michi

[Maximeter (Gast)]

Michael Reinelt schrieb:
> das geht so natürlich nicht (außer ich hab den C-Code im Header-File,
> was man ja nicht tut), weil die uart.c eine eigene Compile-unit ist.

Ich verstehe das Problem nicht so ganz. In deiner uart.c ist doch die 
Funktion der UART Schnittstelle implementiert und in der uart.h stehen 
die Prototypen, auf die andere Module zugreifen müssen und vielleicht 
noch ein paar defines. Das ist ja Sinn und Zweck eines Headers, dass nur 
die Schnittstellen definiert sind und man nicht den kompletten Code 
offenlegen muss.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Maximeter schrieb:
> Michael Reinelt schrieb:
>> das geht so natürlich nicht (außer ich hab den C-Code im Header-File,
>> was man ja nicht tut), weil die uart.c eine eigene Compile-unit ist.
>
> Ich verstehe das Problem nicht so ganz. In deiner uart.c ist doch die
> Funktion der UART Schnittstelle implementiert und in der uart.h stehen
> die Prototypen, auf die andere Module zugreifen müssen und vielleicht
> noch ein paar defines. Das ist ja Sinn und Zweck eines Headers, dass nur
> die Schnittstellen definiert sind und man nicht den kompletten Code
> offenlegen muss.

ich verwende das UART-Modul einmal mit 9600 Baud, einmal mit 19200, 
einmal mit 64Byte Buffer, einmal mit 256 Byte. Für jede "Konstellation" 
muss es extra compiliert werden (es wird keine Library).

Natürlich kann ich diese "Konfiguration" in die uart.h schreiben, hat 
aber den Nachteil dass ich dann unterschiedliche uart.h-Files habe.

[Daniel V. (danvet)]

Hmm.. in diesem Fall macht es vielleicht doch Sinn, der UART_Init() zwei 
Parameter mitzugeben: Baudrate und BufferSize.
Baudrate stellt den Takt ein, BufferSize wird dann über malloc() 
bereitgestellt.
Somit kannst du deine Uart.h/c in verschiedenen Projekten verwenden und 
individuell konfigurieren.

[Peter II (Gast)]

Daniel V. schrieb:
> Baudrate stellt den Takt ein, BufferSize wird dann über malloc()
> bereitgestellt.

malloc will man aber sehr oft nicht haben.

Ich würde es im Makefile setzen.

[Michael R. (Firma: Brainit GmbH) (fisa)]

malloc() kommt aus zwei Gründen nicht in Frage: zum einen weil ich es 
nicht haben will :-), und zum zweiten weil die Buffer-Größe zur 
Compile-zeit bekannt und konstant sein muss, damit Optimierungen wie x % 
64 => x & 63 greifen.

Für die baudrate gilt das gleiche: das util/setbaud.h braucht eine 
Konstante zu Compile-Zeit.

Setzen im Makefile ist eh mein Favorit, aber vielleicht gibts was 
klügeres?

[Udo S. (urschmitt)]

Setzen im makefile und ggf. mit #ifndef ... ein Defaultwert falls es 
nicht gesetzt ist.

[Peter II (Gast)]

Michael Reinelt schrieb:
> Für die baudrate gilt das gleiche: das util/setbaud.h braucht eine
> Konstante zu Compile-Zeit.

was man aber ohne Problme ändern könnte. Ob die berechnung zur laufzeit 
gemacht wird spiel hier keine rolle. Es wird ja nicht aller paar ms 
gemacht.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Peter II schrieb:
> Michael Reinelt schrieb:
>> Für die baudrate gilt das gleiche: das util/setbaud.h braucht eine
>> Konstante zu Compile-Zeit.
>
> was man aber ohne Problme ändern könnte. Ob die berechnung zur laufzeit
> gemacht wird spiel hier keine rolle. Es wird ja nicht aller paar ms
> gemacht.

Stimmt, aber setbaud.h ist klein und praktisch, und wenn ich das 
BUFSIZE-Problem gelöst habe, löst sich dieses gleich mit :-)

[Maximeter (Gast)]

Daniel V. schrieb:
> Hmm.. in diesem Fall macht es vielleicht doch Sinn, der UART_Init() zwei
> Parameter mitzugeben: Baudrate und BufferSize.
> Baudrate stellt den Takt ein, BufferSize wird dann über malloc()
> bereitgestellt.
> Somit kannst du deine Uart.h/c in verschiedenen Projekten verwenden und
> individuell konfigurieren.


Genau so würde ich das auch machen. Das ich das komplette System nicht 
kenne wäre ein Compile Switch vielleicht noch eine Möglichkeit. Aber die 
obige Methode finde ich am Saubersten.

Peter II schrieb:
> malloc will man aber sehr oft nicht haben.

Aus welchem Grund? Natürlich zieht man statische Variablen vor wenn es 
möglicht ist und Sinn macht aber in diesem Fall spricht doch nichts 
gegen was dynamisches.

[Peter II (Gast)]

Maximeter schrieb:
> Aus welchem Grund? Natürlich zieht man statische Variablen vor wenn es
> möglicht ist und Sinn macht aber in diesem Fall spricht doch nichts
> gegen was dynamisches.

doch macht es, es wird nicht mehr so gut optimiert. Weil zur compilezeit 
die Adresse nicht feststeht. Also muss jedesmal die Adrese erst aus dem 
Zeiger ermittelnt werden.

[peterguy (Gast)]

Also ich erstelle mir für solche Fälle meist eine zusätzliche Header 
Datei, die in deinem Fall uart_cfg.h heißen würde.
Diese wird dann im jeweiligen Projektverzeichnis abgelegt.