eine mit 'volatile' erzeugte Variable wird im zweiten C-File ignoriert

OP (Firma: Chipwerkstatt) #7938054
Lesenswert?

Hallo Forengemeinde,

Habe ein Atmega32 Projekt, wo ich bis jetzt folgende Files habe:

  • ein Include-File wo ein Teil meiner Variablen deklariert sind.
  • ein Main-C File, wo meine Haupt-Anwendung steckt, mit ca. 500 Zeilen Code.
  • ein C-File, wo meine Service-Routinen stecken, mit ca. 400 Zeilen Code.

In beiden C-Files ist die Include-Datei, und weitere eingebunden.

In der Main-C steckt eine Timer/ISR Routine, die ich für das Display und andere Sachen, wie Sekunden-Timer, ect. benötige. Diverse Variablen, wie z.B. Chip_Timeout sind mit 'volatile' erstellt. Erst in der Main, dann verschoben in der Header mit dem Zusatz 'EXTERN' . Also sollte ich doch von ALLEN C-Files darauf zugreifen können.

  • EXTERN volatile int Chip_Timeout;

Soweit funktioniert auch die Anwendung, inclusive Hardware.

Nun zum Problem: Chip_Timeout funktioniert auch in der Main.c, da hier die ISR ist.

Ich benötige aber diesen Chip_Timeout aber auch in dem C-File, wo mein 'Service' - Zeugs ist. Und da klappt es nicht. Es kommt kein Fehler beim Build. Anscheinend wird die Variable (Chip_Timeout) in der ISR ignoriert, oder was ???

Wie kann man diese Problem lösen, damit Chip_Timout in beiden C-Files funktioniert ?

: Bearbeitet durch User
#7938081
Lesenswert?

in der Header-Datei: extern volatile int Chip_Timeout;

Das erklärt dem Compiler um welchen Datentyp es sich bei der Variable handelt.

Und in irgendeiner C Datei: volatile int Chip_Timeout = 0; // Definition und Initialisierung

Hier wird die Variable tatsächlich erzeugt und der Speicher dafür reserviert. Das darf natürlich nur genau 1 mal passieren.

Der Linker sorgt dann dafür, das alle Referenzierungen der Variable auf den selben Speicher verweisen.

: Bearbeitet durch User
#7938108
Lesenswert?

Rainer W. schrieb:

N. M. schrieb:

Bin lieber ein vernünftiges Buch.

Du sprichst in Rätseln.

Ja, Autovervollständigung ohne gegenlesen. Bin==Lies.

Rainer W. schrieb:

Gibt es auch kostenlose im Internet.

Was kannst du empfehlen?

Nö, schon lange keins mehr gelesen. Von dem her kann ich gerade keins persönlich empfehlen. Aber man bekommt definitv Skripte von FHs/Unis zum Thema. Und Bücher gab es auch schon immer kostenlose.

Moderator Persönliche Seite #7938122
Lesenswert?

Thomas S. schrieb:

Aber der Compiler meckert nicht, und es funktioniert.

Offenbar ja nicht, sonst hättest du den Thread nicht begonnen.

Daher bat ich eingangs um ein nachvollziehbares Beispiel. Dieses sollte auf das Minimum zusammen gestrichen sein, mit dem man sieht, wie du das aufgebaut hast. (Ganz am Rande: wenn man sich die Arbeit macht, so ein Beispiel aus dem zusammen zu streichen, was man hat, versteht man häufig auch gleich sein Problem.)

#7938237
Lesenswert?

Jörg W. schrieb:

wenn man sich die Arbeit macht, so ein Beispiel aus dem zusammen zu streichen, was man hat, versteht man häufig auch gleich sein Problem

Sein Problem ist, dass er den Unterschied zwischen Deklaration und Definition nicht kennt und deshalb nicht berücksichtigt.

Für mich war das seinerzeit beim Lernen anhand von K & R zunächst verwirrend, weil beide Begriffe in der Normalsprache ja ungefähr dasselbe meinen. Wenn ich definiere, was ein "Hund" ist, dann entsteht dadurch kein konkreter Hund. Ich sage damit lediglich, wie ein Hund aussähe, wenn einer da wäre. Nicht anders ist es, wenn ich vereinbare (deklariere), dass ich und andere ein Wesen mit bestimmten Eigenschaften (wenn denn ein solches Wesen da wäre) "Hund" nennen wollen. Wo ist da ein Unterschied?

In C entsteht durch eine Definition aber etwas durchaus Greifbares, nämlich ein reservierter Speicherplatz der definierten Größe im fertigen Programm; bei einer Deklaration entsteht gar nichts.

: Bearbeitet durch User
Moderator Persönliche Seite #7938243
Lesenswert?

Rolf schrieb:

Sein Problem ist, dass er den Unterschied zwischen Deklaration und Definition nicht kennt und deshalb nicht berücksichtigt.

Zumal eine Definition ja in der Regel auch zugleich eine Deklaration ist. ;-)

Sollte an sich trotzdem nicht zu dem beschriebenen Effekt führen: wenn sowohl Deklaration als auch Definition das "volatile" haben, dann müsste es funktionieren – und den Unterschied zwischen beiden hat er am Ende mit seinem Headerfile-Trick mit EXTERN unbewusst tatsächlich realisiert.

Moderator Persönliche Seite #7938445
Lesenswert?

Ist doch aber noch mehr 'ne Krücke, als sauber verstanden zu haben, wo man eine extern-Deklaration und wo man die Definition hinpackt.

Prinzipiell gab es bei C auch noch die Möglichkeit, dass sich mehrere gleichnamige Definitionen einander überlagern (im Stile eines FORTRAN COMMON-Blocks), und das war lange Zeit sogar der Default. Ich bin mir nicht ganz sicher, aber ich glaube mich zu erinnern, dass das in C23 dann rausgeflogen oder zumindest deprecated ist.

Schlampig war es auf jeden Fall schon immer. ;-)

(Firma: Gast) #7938592
Lesenswert?

Harald K. schrieb:

Was ist daran jetzt "besser"?

Es ist an einem Ort zusammen gefasst! Deklaration, Definition und Initialisierung. Das macht Änderungen einfacher.

Man kann auf die *.cpp Dateien verzichten, wenn man denn möchte.

Für die Methoden einer Klasse braucht es auch keine *.cpp Datei mehr. Auch wieder: Alles an einem Ort.

*.h only Angeblich hilft das gar der Optimierung auf die Sprünge. Wenn es auch das kompilieren verlängern mag.

Für mich macht es das "besser"! Du magst anderer Ansicht sein.

Harald K. schrieb:

weil es neuer ist?

Man muss nicht alles ablehnen nur weil neuer ist. Oder?

Harald K. schrieb:

Dann solltest Du Dich dafür einsetzen, daß Arduino nach Rust umzieht. Weil das ja neuer, ergo besser ist.

Mein AVR Arduino läuft mit C++23 und einer recht vollständigen libstdc++. Neuer/Frischer geht es kaum, möchte ich mal sagen.

#7938638
Lesenswert?

Arduino F. schrieb:

Für mich macht es das "besser"! Du magst anderer Ansicht sein.

Ich würde sagen: "Einfacher" und "Selbstkorrigierend". Wenn man vergisst, die Variable anzulegen, dann passiert das einfach automatisch "irgendwo" im Hintergrund. Allerdings auch bei Schreibfehlern. Oder wenn der Linker eigentlich ein Problem melden sollte.

Für mich ist das ähnlich dem Wunsch, dass "der Compiler doch die schließende Klammer hinzudenken kann, wenn klar ist, dass sie fehlt".

(Firma: Gast) #7938711
Lesenswert?

Bruno V. schrieb:

Wenn man vergisst, die Variable anzulegen, dann passiert das einfach automatisch "irgendwo" im Hintergrund. Allerdings auch bei Schreibfehlern. Oder wenn der Linker eigentlich ein Problem melden sollte.

Du hast eine witzige Fantasie, aber so funktioniert das nicht!

Dadurch, dass die inline Variable in der *.h definiert wird, gibt es diese in jeder Übersetzungseinheit, welche diese *.h einbindet. Durch das inline Attribut wird dem Linker mitgeteilt, dass er sie alle zusammen legen soll, auf ein einziges Speicherobjekt. Das gilt übrigens ganz ähnlich auch für inline Funktionen. Methoden sind übrigens per default inline, wenn sie im Klassenkörper definiert werden. Und das ist schon viel länger so. Das Prinzip wurde nur auf freie Funktionen und Variablen ausgedehnt, so dass es für den Programmierer gezielt nutzbar wird.

Da ist nix mit "automatisch" Klammern basteln, Schreibfehler korrigieren oder so....

Bruno V. schrieb:

"Selbstkorrigierend".

Nix davon ist "Selbstkorrigierend". Sondern das ist Teil der Sprachdefinition ab C++17 Das muss dir ja nicht schmecken, aber es ist jetzt so. Auch kannst du weiterhin dein extern nach belieben weiter nutzen.

: Bearbeitet durch User
Persönliche Seite #7938720
Lesenswert?

Arduino F. schrieb:

Oder sofort C++

Arduino F. schrieb:

oder besser sofort C++.

Arduino F. schrieb:

zumindest in C++

Arduino F. schrieb:

Danach kann man Chip_Timeout in jeder C++

Arduino F. schrieb:

Das ist in C++17

Arduino F. schrieb:

Mein AVR Arduino läuft mit C++23

Sag mal, welches Problem hast du eigentlich?

Die Frage bezieht sich ganz klar auf C.

Und das einzige was du kannst ist alles mit C++ zuzuspammen.

Und was "dein Arduino" macht interessiert keinen.

: Bearbeitet durch User
(Firma: Gast) #7938734
Lesenswert?

Auch in C geht das durch, allerdings mit einer Warnung: warning: variable 'testVar' declared 'inline'

Ohne inline, ein Linker Error: multiple definition of `testVar';

Getestet mit -std=gnu11 und -std=gnu23

Und ja alle diese inline Variablen, mit gleichem Namen, werden auf die gleiche Adresse gelinkt.

Johann L. schrieb:

Die Frage bezieht sich ganz klar auf C.

Geht also genau so mit gnu C!

Moderator Persönliche Seite #7938746
Lesenswert?

Harry L. schrieb:

foobar.h:

extern volatile int chip_timeout;

foobar.c:

volatile int chip_timeout;

void main() { chip_timeout = 0; }

Das ist schlecht. Besser wäre für foobar.c:

foobar.c:

1
#include "foobar.h"  // WICHTIG!
2
volatile int chip_timeout;
3

4
void main()
5
{
6
  chip_timeout = 0;
7
}

Nur so kann der Compiler prüfen, ob Deklaration und Definition vom selben Typ sind. Das ist extrem wichtig. Sonst könnte man in foobar.c die Variable auch abweichend als float definieren und keiner würde das merken!

Fazit:

In der Datei, wo die globale Variable definiert wird, sollte auch die externe Deklaration (in Form des include-Files) immer mit herangezogen werden, damit der Compiler prüfen kann, ob beide "kompatibel" sind.

#7938771
Lesenswert?

Arduino F. schrieb:

Du hast eine witzige Fantasie, aber so funktioniert das nicht!

In C schon.

Das Prinzip wurde nur auf freie Funktionen und Variablen ausgedehnt, so dass es für den Programmierer gezielt nutzbar wird.

Die ursprüngliche Bedeutung von inline war, den Aufruf möglichst schnell zu machen.

Dass es zur Definition im Header verwendet wird, ist eher eine Bedeutungsverschiebung. In C++ auch einleuchtend, da der C++-Compiler sich eh schon immer die Freiheit zum inline herausgenommen hat.

Persönliche Seite #7938778
Lesenswert?

Arduino F. schrieb:

Und ja alle diese inline Variablen, mit gleichem Namen, werden auf die gleiche Adresse gelinkt.

Nein, werden sie nicht.

Es gibt schlicht und einfach ein "multiple definition of" Fehler vom Linker, es sei denn du compilierst mit -fcommon.

Ws wird einfach nur das "inline" vom Compiler ignoriert, das ist alles. Zumindest wenn man ohne -Werror übersetzt.

Und C++ inline variables werden auf Target-Ebene komplett anders umgesetzt (comdat oder linkonce) als inline Funktionen.

Einfach alles Käse was du hier verzapfst.

(Firma: Gast) #7938790
Lesenswert?

Johann L. schrieb:

Nein, werden sie nicht.

Du hast recht! Mein Test war fehlerhaft. Habe ich gerade auch bemerkt!

Dank eines dummen Tippfehlers ist aus meiner beabsichtigten a.c Datei eine ac.ino geworden. Ist mir gerade erst aufgefallen.

Nach der Korrektur zeigt sich, dass C das nicht so tut. Also ab jetzt behaupte ich das Gegenteil von eben.

: Bearbeitet durch User

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren