Hi,
eine kurze Frage:
Darf ich aus einem Tab, also einer Datei die z.Bsp. "Widerstand.h" heißt, und via #include "Widerstand.h" eingebunden ist, wiederum eine selbstgestrickte Funktion aufrufen, die z.Bsp. "float Widerstand_messen (byte R_Pin, float R_Wert)" heißt?
Wenn ja, wo muss die stehen? Wenn nein, muss ich auf die Tabs verzichten, oder was muss ich ändern?
Gruß André
Kondensator.h (182 Bytes)
R_u_C_neu_24.08.2018_001.ino (3.84 KB)
Widerstand.h (8.21 KB)
Wenn die Funktion in einer anderen Datei implementiert ist, muß sie noch in einer Header-Datei (*.h) deklariert werden. Dieser Header muß dann mit #include in die aufrufende Datei importiert werden.
Hi,
danke für den Hinweis, aber ich denke, daß ich mich hier erstmal einlesen muss, da fehlt mir noch das eine oder andere Puzzleteil 
Bisher funktionierte es in Tabs, aber nun mit Funktionsaufrufen geht es erstmal nicht mehr.
Gruß André
Wenn ja, wo muss die stehen?
Das Zauberwort ist "Sichtbarkeit" !
Du kannst nur Funktionen aufrufen, welche in dieser Übersetzungseinheit sichtbar sind.
Zum Anfang:
Üblicherweise deklariert man diese in *.h Dateien.
Und die Definition sollte dann in *.cpp stattfinden, da unsere Arduinowelt eine C++ Welt ist.
Verstanden?
Was hast du nicht verstanden?
// Wie bei allen Regeln, gilt:
// Man kann von dem gesagten abweichen, wenn man weiß, was man tut.
Beispiel:
*.ino
#include "Test.h"
void setup()
{
Serial.begin(9600);
}
void loop()
{
Serial.println(++testVar);
testFunc();
delay(500);
}
Tab: Test.h
#pragma once
extern int testVar; // extern deklariert
void testFunc(); // deklaration
Tab: Test.cpp
#include "Test.h"
#include <Arduino.h>
int testVar = 41; // lokale definition einer als extern deklarierten Variable.
void testFunc()
{
Serial.println("Hi");
}
Du redest von Tab
Meinst Du die Tab's in der Arduino IDE?
Grüße Uwe
uwefed:
Du redest von Tab
Meinst Du die Tab's in der Arduino IDE?
Grüße Uwe
Du meinst mich?
Dann ja!
*.cpp und *.h Dateien als Tab in der IDE.
Diese kann man dann fix/problemlos als Lib auslagern, wenn man den Kram häufiger nutzt.
(so entwickle ich meine Libs)
Darf ich aus einem Tab, also einer Datei die z.Bsp. "Widerstand.h" heißt, und via #include "Widerstand.h" eingebunden ist, wiederum eine selbstgestrickte Funktion aufrufen, die z.Bsp. "float Widerstand_messen (byte R_Pin, float R_Wert)" heißt?
Ja, allerdings sollten .h Dateien besser keinen ausführbaren Code enthalten, sondern deren Funktionsdeklarationen.
Kannst ja mal combie's Beispiel für deine Frage konkretisieren und sehen ob es geht. Wenn nicht, hier (mit Fehlermeldung) zeigen.
Ja, allerdings sollten .h Dateien besser keinen ausführbaren Code enthalten,
Doch darf, macht sogar öfter mal richtig Sinn.
Aber dann bekommt man u.U., wenn man es falsch macht, ein Sichtbarkeitsproblem(mehrfache Definition ein und derselben Funktion, was dann der Linker gar nicht mag), oder gar einen unbeabsichtigten Code Bloat.
Im Grunde machen meist nur als static deklarierte Funktionen in *.h Sinn.
Diese sollten dann auch inline sein.
Alternativ, zu static, ein anonymer Namespace
Das (oder so ähnliche Bedenken) versuchte ich mit " sollten ... besser" nur anzudeuten.
Auch wer deine Erläuterungen nicht auf Anhieb versteht, kann doch dein Beispiel hernehmen und seine, in Tabs ausgelagerten Funktionen und Deklarationen, entsprechend gesalten.
" sollten ... besser"
Ok....
.... Feinheiten, bei Bedarf ....
Guten Morgen,
vorab vielen Dank an alle die sich mit meiner Problemstellung beschäftigen und helfen wollen. Vermutlich ist es für Wissende gar kein Problem.
Für mich, der nicht in der Materie steckt ist es halt eins, da mir die Tabs helfen, den Überblick zu bewahren. Alles in einer Datei funktioniert, (so wie vorher in Tabs ohne Funktionsaufrufe) aber es ist sehr mühsam bei momentan ~ 600 Zeilen.
Ich denke combie hat Recht mit dem Zauberwort "Sichtbarkeit", das sagt mir zumindest die Fehlermeldung des Compilers:
'Widerstand_messen' was not declared in this scope.
@ combie, wenn Du mich fragst, ob ich es verstanden habe, dann muss ich zum jetzigen Zeitpunkt mit nein antworten, nach dem WE kommt dann hoffentlich ein ja.
Vermutlich habe ich auf Sand angefangen zu bauen, und schiebe jetzt ein Fundament drunter, mein Nick ist aber mit bedacht gewählt
Gruß André
'Widerstand_messen' was not declared in this scope.
Der Meldung ist zu glauben!
Mein Tipp:
Da Widerstand_messen thematisch zu Widerstand passt, deklariere diese Funktion in Widerstand.h und definiere sie in Widerstand.cpp
So passt es zusammen.
So habe ich es dir im Beispiel gezeigt.
So machen es die meisten C/C++ Programmierer.
Wenn du lernen möchtest, wie man Dateien sinnvoll aufteilt, dann musst du lernen in Übersetzungseinheiten zu denken. Denn, nichts anderes sieht der Compiler.
Er sieht Übersetzungseinheiten.
Erst der Linker klöppelt dann die ganzen Übersetzungseinheiten zu einem fertigen Irgendwas zusammen.
Hast du dir erstmal die gleiche Sicht angewöhnt, wie sie auch der Compiler hat, dann verstehst du auch dessen Meldungen. Und die offensichtlichen Lösungen liegen klar vor dir.
Übersetzungseinheit:
Vereinfacht gesagt, ist eine Übersetzungseinheit eine einzelne *.cpp oder *.c Datei.
Ja, der Arduino Builder macht aus der *.ino Datei eine *.cpp Datei(eine Übersetzungseinheit) und wirft sie dem
Compiler vor. Das kann man schön im Build Ordner sehen.
mein Nick ist aber mit bedacht gewählt
Meiner auch!!
Die Arduino IDE vereint alle [EDIT] .ino File [/Edit]TABs vor der Kompilierung zu einem File und kompiliert dann alles. Darum brauchst Du kein #include und kein xxx.h. Du brauchst nur alles .INO files. Das Zusammenfügen erfolgt alfabetisch nach Namen.
Wenn Du was includieren willst dann erstelle einen Bibliothek und speichere diese in seier Direktory in der Bibliothekdirektory.
Grüße Uwe
uwefed:
Die Arduino IDE vereint alle TABs vor der Kompilierung zu einem File und kompiliert dann alles. Darum brauchst Du kein #include und kein xxx.h. Du brauchst nur alles .INO files. Das Zusammenfügen erfolgt alfabetisch nach
Uwe!
Ich mag dich.
Sowohl, als Mensch, als auch als Südeuropäer.
Egal, welche Schablone man auch anlegen will...
Jes!
Die Arduino IDE vereint alle TABs vor der Kompilierung zu einem File und kompiliert dann alles.
Aber das ist falsch!
Das mach es nur bei *.ino Dateien!
Nicht mit *.h und *.cpp oder *.c
Hallo,
hat Uwe ja auch so geschrieben. Ihr habt verschiedene Sichtweisen die alle einzeln stimmen. Der eine schreibt von .ino Dateien und der andere von .h und .cpp Dateien. Nur vermischen darf man sie nicht in euren Erklärungen.
Doc_Arduino:
Ihr habt verschiedene Sichtweisen die alle einzeln stimmen.
Nein!
Wir haben hier eine massive Kollision.
Da gibt es ein klares Nein/Ja
Kein weiches "Ihr habt je beide fast recht"
Also einigen wir uns auf mehrere TABs mit .ino Sketch-Teilen die automatisch von der IDE zusammengefügt werden. Wobei ich bezüglich Lesbarkeit nicht sicher bin, ob ein langer Sketch oder mehrer Teile übersichtlicher ist.
Oder .h und .ccp Files als Bibliothek im entsprechenden Ordner inkludert. (Soweit ich weis funktioniert es mit h und ccp auch im Sketch Ordner aber reden wir mal von sauberen Lösungen.
Grüße Uwe
combie:
Uwe!
Ich mag dich.
Sowohl, als Mensch, als auch als Südeuropäer.
Egal, welche Schablone man auch anlegen will...
Jes!
Aber das ist falsch!
Das mach es nur bei *.ino Dateien!
Nicht mit *.h und *.cpp oder *.c
Meist liege ich richtig und bin handzahm 
Du weißt ich bin ein praktischer Mensch und kein super Programmierer. Darum mache ich bei solch sprachspezifischen Aussagen machmal ungewollt Fehler. Sollte zwar nicht passieren aber wenn man überzeugt ist das richtige zu wissen ....
Ich bitte um Entschuldigung und nichtbeachtung meiner falschen Aussage.
Hab den beanstandeten Post geändert. Hoffentlich ist es jetzt klar.
Grüße Uwe
Es passieren immer wieder seltsame Dinge.
combie sprach von .h und .cpp Dateien. Korrekte Aussage.
Uwe sprach nur von .ino Dateien. Es war keine Rede von h. und .cpp Dateien. Also ist seine Aussage ebenfalls korrekt.
Erst ab dem Punkt wo combie die Aussage von Uwe ohne Grund um seine Gedanken mit .h und .cpp erweitert, stellt er Uwes Aussage damit falsch dar. Völlig zu unrecht. combie baut sich damit seine eigene Kollision die es vorher nicht gab.
Und dann passiert etwas völlig verrücktes. Uwe sieht das Problem nicht und stellt seine eigene korrekte Aussage als falsch dar. Völlig absurd.
