Forum: Mikrocontroller und Digitale Elektronik Anfängerfrage C, Konstanten projektweit zur Verfügung stellen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Joern DK7JB .. (moin)


Bewertung
0 lesenswert
nicht lesenswert
Wie stellt man in C (AtmelStudio7/Atmega) am besten projektweit 
Konstanten und einige wenige Variablen zur Verfügung? Also in mehreren 
*.c Dateien verfügbar?
Was ist hier gute Programmierstil?
Kommt alles in eine Variablen_Konstanen.h Datei, die dann von allen *.c 
Dateien eingebunden wird? Oder muss es eine Variablen_Konstanen.c Datei 
sein?
Wie löst ihr solche "Probleme"?
Hierzu helfen mir meine Bücher leider nicht weiter.

von Thomas W. (diddl)


Bewertung
1 lesenswert
nicht lesenswert
Konstanten in H Files am besten als #define


Globale Variable in einem H File als "extern … …" und dann in EINEM C 
File definieren.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ich schreibe sie als #define in eine Header Datei, die von allen *.c 
Dateien eingebunden wird.

Alternativ kannst du die Compiler Option -D (indirekt über die 
Projekteinstellungen bzw. im Makefile) benutzen, das wird typischerweise 
mit F_CPU gemacht.

von Matthias (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die Variablen sollten in einem C-File deklariert werden und dann mittels 
extern qualifier über ein H-file bekannt gemacht werden. Konstanten 
können als Define in das header file. Falls aus Gründen der qualifier 
const verwendet werden muss, verhält es sich wie bei variablen.

Beispiel:

C-File file1.c:
1
unsigned char foo = 0;
2
unsigned char bar = 0;

H-File file2.h:
1
#define MY_LIMIT   10
2
extern unsigned char foo;
3
extern unsigned char bar;

C-File file3.c:
1
#include "file2.h"
2
3
void myFunc1(void)
4
{
5
   foo++;
6
   bar++;
7
}

C-File file4.c:
1
#include "file2.h"
2
void myFunc2(void)
3
{
4
   if(foo > MY_LIMIT)
5
   {
6
      foo = 0;
7
   }
8
   if(bar > MY_LIMIT)
9
   {
10
      bar = 0;
11
   }
12
}

Variablen in Header-Files zu deklarieren ist nicht zu empfehlen, da so 
u.U.  mehrere Variablen mit dem gleichen Namen erzeugt werden können.

Generell ist von der Verwendung globaler Variablen zu vermeiden.

Gruß

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Hat er nicht nach Konstanten gefragt?

Bei meinem Liebling, dem ATtiny13A feilsche ich (zwangsläufig) um jedes 
Byte RAM.

Beitrag #5674193 wurde von einem Moderator gelöscht.
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ach so, hab ich übersehen. Na dann ergänzen sich ja unsere beiden 
Beiträge prima.

Beitrag #5674197 wurde von einem Moderator gelöscht.
Beitrag #5674198 wurde von einem Moderator gelöscht.
Beitrag #5674203 wurde von einem Moderator gelöscht.
von Joern DK7JB .. (moin)


Bewertung
0 lesenswert
nicht lesenswert
Ich vermute, dass  Matthias in seinem Beitrag von (28.12.2018 15:09) 
gemeint hat:

Hier soll doch bestimmt file2.c stehen damit es übersichtlich bleibt
 - oder?
C-File file1.c:
1
unsigned char foo = 0;
2
unsigned char bar = 0;


H-File file2.h:
1
#define MY_LIMIT   10
2
extern unsigned char foo;
3
extern unsigned char bar;

Muss es nicht zu jeder *.c Datei auch eine *.h Datei geben?

Mir ist klar, dass ich es mit den globaler Variablen variablen nicht 
übertreiben darf. Ich programmiere eine Steuerung für einen Empfänger 
mit einem umfangreichem Menü und einem Touchdisplay. Hier ergeben sich 
einige Zustände die global verfügbar sein "müssen". Naja, damit das 
Projekt nicht zu komplex für mich wird. Mit dem ATMega644 habe ich da 
etwa Luft.
Für Anregungen was den guten Programmierstil betrifft bin ich aber 
offen.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Muss es nicht zu jeder *.c Datei auch eine *.h Datei geben?

Nöö.

von Thomas W. (diddl)


Bewertung
0 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Muss es nicht zu jeder *.c Datei auch eine *.h Datei geben?

Nee.

Es kann zu jeder C Datei ein oder mehrere H Dateien geben.

Es kann eine H Datei in einer, mehreren oder allen C Dateien inkludiert 
werden.

von Matthias (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Muss es nicht zu jeder *.c Datei auch eine *.h Datei geben?

Nein, muss es nicht.
Üblich ist es aber durchaus, dass es zu einem .c-File auch ein (oder 
mehrere) .h-file(s) gibt.

Wenn in einem C-File globale Funktionen (nicht static) implementiert 
werden, sollten diese in einem gleichnamigen H-File bekannt gemacht 
werden. Dies kann dann von den Aufrufenden C-Files eingebunden werden.

Z.B. können für UART init(), put() und get() Funktionen im C-File uart.c 
implementiert und über ein H-File uart.h bekannt gemacht werden.

Gruß

Matthias

von Joern DK7JB .. (moin)


Bewertung
0 lesenswert
nicht lesenswert
Ihr verwirrt mich etwas. Welchen Sinn macht es mehrere .h Files zu 
haben, wenn es nur ein zugehöriges .c File gibt?
Gibt es hierzu eine sinnvolle Strategie?

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Ihr verwirrt mich etwas.

Ist eigentlich ganz einfach:
Wenn man in einem Programm-Unit, also einer .c Datei irgend etwas 
geschrieben hat, worauf andere Programm-Units drauf zugreifen 
sollen/können/müssen, also so etwas wie Variablen, Funktionen, 
Typdeklarationen usw. - dann schreibt man das in eine "header"-Datei .h, 
damit das von anderen Units inkludiert werden kann.

Man kann im Prinzip unendlich viele Headerdateien für seinen Unit 
schreiben, die Anzahl ist unbegrenzt. Aber für solchen Firlefanz gibt es 
wohl kaum eine praktische Anwendung, da begnügt man sich mit einer 
einzigen .h

Ach ja, die Endung .h ist rein willkürlich und nicht festgelegt. Man 
könnte im Prinzip das Ganze auch .ottokar nennen - aber wer will sowas 
schon?

Merke: beim Programmieren mit C hat man an vielen Stellen völlige 
Freiheit - aber eben auch die Freiheit, dabei Bockmist zu verzapfen.

W.S.

von Matthias (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Ihr verwirrt mich etwas. Welchen Sinn macht es mehrere .h Files zu
> haben, wenn es nur ein zugehöriges .c File gibt?
> Gibt es hierzu eine sinnvolle Strategie?

Eine Strategie könnte zum Beispiel sein, dass ein H-File für den 
Globalen Kontext und ein H-File für den Lokalen Kontext verwendet wird.

Im Globalen H-File sind dann Globale Funktionen, Defines, Typen, Enums, 
etc. bekannt gemacht, die zur Verwendung der Funktionen benötigt werden.
Im Lokalen H-File sind dann Defines etc. zum Parametrisieren oder 
Konfigurieren der Funktionen untergebracht.

Gruß

von PinPon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas W. schrieb:
> Konstanten in H Files am besten als #define

Dann sind es aber keine "Konstanten".
(Hier ist man gerne pingelig.)

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Joern DK7JB .. schrieb:
> Ihr verwirrt mich etwas. Welchen Sinn macht es mehrere .h Files zu
> haben, wenn es nur ein zugehöriges .c File gibt?
> Gibt es hierzu eine sinnvolle Strategie?

Beispiel: Ein C-File implementiert einen Teil eines Moduls. Nun sollen 
z.B. alle Funktionen und verschiedene Typen dem Modul bekannt gemacht 
werden, aber nicht dem Benutzer des Moduls, da diese von außen nicht 
benutzt werden sollen. Dann macht man einen Header für das Modul und 
einen "public"-Header.

PinPon schrieb:
> Thomas W. schrieb:
>> Konstanten in H Files am besten als #define
>
> Dann sind es aber keine "Konstanten".

> (Hier ist man gerne pingelig.)

Eigentlich können es nur dann Konstanten sein.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Konstanten sind z.B Strings. Oder Werte, von denen Pointer benötigt 
werden.

Auch da die extern-deklaration (ohne Initialisierungswert) in eine .h 
und mit Initialisierung in .c


Wenn man eine library machen will, dann kommen oft Mini-Funktionen in 
eine eigene .c und viele davon zusammen in eine .h schau mal nach abs().

Ist momentan verwirrend aber egal, wird erst später wichtig.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.