Unterschied bei #include

Hallo

Nachdem ich jetzt einige Seiten nach Codeschnipseln bzw. Libraries durchforstet habe:

Was ist der Unterschied zwischen #include “library.h” und #include <library.h>, außer in der Farbe der Bibliotheken?

Wenn ich die Suche hier im Forum benutzen will, gibt es eine Möglichkeit, nur im deutschsprachigen Teil zu suchen?

LG
Friedrich

hi,

in einem fall sucht er die library im libraries-ordner, im anderen im ordner, wo der sketch liegt.

unf nein, wüßte ich nicht und ärgere mich auch drüber...

gruß stefan

Danke. Kannst du mir bitte noch sagen, welche Version die mit dem Library-Ordner ist, diese wäre mir am liebsten.

Jetzt ist mir auch klar, warum manchmal eine Library nicht gefunden wurde, obwohl ich sie in den richtigen Ordner kopiert hatte.

hi,

ich glaube, das mit den pfeilen ist für den libraries-ordner. einfach ausprobieren...

gruß stefan

Die Bibliotek muß in einem Unterordner mit dem gleichen Namen wie die Bibliothek sein und in Bibliotheksordner sein.
Grüße Uwe

Mehr Suchoptionen (Einschänkungen z.B. nur auf eine Forums-Unterkategorie) gab es früher mal, jetzt leider nicht mehr und auch ich vermisse diese Möglichkeit sehr.

uwefed:
Die Bibliotek muß in einem Unterordner mit dem gleichen Namen wie die Bibliothek sein und in Bibliotheksordner sein.

Hallo Uwe,
mit IDE 1.5.9 war das so, aber meine IDE 1.6.5 gibt folgende Meldung aus:

Multiple libraries were found for "IRremote.h"
Used: F:\Arduino\libraries\IRremote
Not used: C:\Program Files (x86)\Arduino165\libraries\RobotIRremote
Not used: F:\Arduino\libraries\IRremote.mitTiny

Das scheint Deiner Aussage zu widersprechen, oder? (Mir wäre es lieber, es wäre so, wie Du schreibst, aber mein Wunsch steht leider nicht zur Diskussion :frowning: )

Gruß aus dem Urlaub!

Das scheint Deiner Aussage zu widersprechen, oder?

Nöö...
Grundsätzlich stimmt das.

Es gibt nur mehrere Ordner wo die Libs stecken können.

  1. Im Arduino Programm Ordner
  2. Im User Bereich, da wo auch die eigenen Sketches abgelegt werden.
  3. In dem Order, wo die betreffende Hardware/Bord Definition zu finden ist (da gibts dann auch noch mehrere Möglichkeiten)

Im Lib Order kann auch noch eine json Datei stecken, welche festlegt für welchen Prozessor/Board die Lib verwendbar ist.

Multiple libraries were found for "IRremote.h"
Used: F:\Arduino\libraries\IRremote
Not used: C:\Program Files (x86)\Arduino165\libraries\RobotIRremote
Not used: F:\Arduino\libraries\IRremote.mitTiny

Die Meldung kommt, wenn sich die IDE für eine Lib entscheiden muss.
Wenn es also mehrere mit gleichem Namen, an verschiedenen Orten, gibt.

Interessant, da ich konservativ "never touch a running system" fahre, habe ich die 1.5.8, die kennt das noch nicht. Wäre prinzipiell interessant, da es ja für die Tinys andere Lib's gibt.
Bzw. Ich habe die LCD lib für I2C gepatcht, weil ich die Pollin I2C Platine habe. Die von den Chinesen passen aber zum Original. Da könnte ich ja dann die Version auswählen, die ich will. Müßte man sich mal näher ansehen :slight_smile:

buffalo64:
Danke. Kannst du mir bitte noch sagen, welche Version die mit dem Library-Ordner ist, diese wäre mir am liebsten.

Jetzt ist mir auch klar, warum manchmal eine Library nicht gefunden wurde, obwohl ich sie in den richtigen Ordner kopiert hatte.

Alle Programmteile, die die Klasse verwenden wollen, müssen die Headerdatei mittels

#include "EineKlasse.h"

einbinden, falls diese in dem selben Ordner wie der Programmteil gespeichert ist.

Sollte die Headerdatei in den include-Ordner des Compilers verschoben worden sein, lässt sie sich mittels

#include <EineKlasse.h>

einbinden.

Kurzform:
in Spitzklammern werden diese im Library Ordner gesucht, also wenn man Librarys einbindet
#include <OneWire.h>

Mit Anführungszeichen muß die Headerdatei im Sketchordner liegen.
#include “LedBlinker.h”

combie:
Nöö...
Grundsätzlich stimmt das.

Was Du schreibst ist richtig. Uwe aber schreibt: "Die Bibliotek muß in einem Unterordner mit dem gleichen Namen wie die Bibliothek sein und in Bibliotheksordner sein." Das ist in meinem Beispiel nicht der Fall für die Datei IRremote.h im Verzeichnis c:\Program Files (x86)\Arduino165\libraries\RobotIRremote\src\

Das erscheint mir dann doch als Widerspruch.

Ich frage mich halt, ist es ein Fehler, der möglicherweise in neueren IDE-Versionen behoben ist, oder soll es ein Feature sein. Bei meiner Version der IDE weiß ich, was passiert, ich möchte aber ungern andere Forumsmitglieder durch falsche Beratung in die Irre führen. Das ist meine Motivation für die Frage.

Nebenbei habe ich das mit der json Datei gelernt, danke für die schöne Erklärung.

Womit ich den kühlen Abend genieße :slight_smile:

Deutsch Suche

Englisch Suche

Das ist in meinem Beispiel nicht der Fall für die Datei IRremote.h im Verzeichnis c:\Program Files (x86)\Arduino165\libraries\RobotIRremote\src\

Das erscheint mir dann doch als Widerspruch.

Da hast du allerdings wahr!

Ich betrachte das als Defekt!

IDE 1.6.7
Wenn ich für den ESP kompiliere und dabei #include <IRremote.h> einbinde wirft es die Meldung:

E:\Programme\Arduino\libraries\RobotIRremote\src\IRremote.cpp:23:27: fatal error: avr/interrupt.h: No such file or directory

#include <avr/interrupt.h>

^

compilation terminated.

Logisch, was will der ESP auch mit avr/interrupt.h, kann ja nichts werden, selbst wenn es gefunden werden würde.
Schade, dass das böse so passiert…

Trotzdem sollte man Uwes Weg folgen.

Und du hast einen Fehler gefunden!
Glückwunsch. Mach was draus.

Doc_Arduino:
Kurzform:
in Spitzklammern werden diese im Library Ordner gesucht, also wenn man Librarys einbindet
#include <OneWire.h>

Mit Anführungszeichen muß die Headerdatei im Sketchordner liegen.
#include “LedBlinker.h”

AFAIK wird (nach C Standard) bei Anführungszeichen zusätzlich und zuerst im aktuellen Verzeichnis (der zu übersetzenden Datei) gesucht, dann im Systembereich.

Beim Arduino läuft das möglicherweise etwas anders, da muß die IDE ja dem Compiler auch noch mitteilen, wo die zugehörigen Quelltexte (*.cpp) liegen, und diese Verzeichnisse ergeben sich aus der Lage der (zuerst gefundenen) Header-Dateien.

[Bei Pascal (OPL) und Konsorten wäre das viel einfacher, da enthält jede Quelldatei ihren eigenen Header, und man gibt direkt den Namen der Quelldatei an :-]

Danke für die Erläuterungen.

Was ist jetzt die bessere, bzw. sauberere Lösung, wo die libraries hin sollen? Auf C:, wo die systemeigenen Bibliotheken liegen, oder im Sketchordner (bei mir auf D:) in dem Unterordner "libraries"? Der Sketchordner hätte für mich den Vorteil, dass er synchronisiert wird (habe einen Online-Speicher, damit ich die Daten auf mehreren Rechnern synchron halte) und ich nicht auf jedem Rechner die libraries erst einbinden muss.
D.h., in diesem Fall müsste ich die libraries dann mit Anführungszeichen einbinden?

LG
Friedrich

Es kann eigentlch nicht schaden, immer die Anführungszeichen zu verwenden.

Man kann die Arduino IDE in ein beliebiges Verzeichnis installieren, dann kann man auch das automatisch synchronisieren.

Danke, jetzt habe ich die IDE auch in den Ordner installiert, der gesynct wird. Das vereinfacht wieder einiges.

Hoffe ich jedenfalls. Es ist ja jetzt auf Rechner 1 installiert, sobald ich Rechner 2 hochfahre, wird dieser Ordner mit dem installierten Arduino synchronisiert. Läuft dann Arduino auf Rechner 2, oder muss ich dies extra nochmal installieren? Ich hoffe, ich handle mir dadurch keine Konsistenzprobleme ein, wenn ich nochmal installiere und dann Rechner 1 das nächste Mal wieder hochfahre.

Die IDE muß mindestens einmal installiert worden sein, damit der USB-Treiber ins System integriert wird. Im Zweifelsfall nochmal eine Installation in das Arduino-Verzeichnis durchführen, und wenn das nicht geht, das Verzeichnis vorher löschen. Danach sollte das Synchronisieren problemlos funktionieren.

Ok, danke. Da es ja derzeit installiert ist, müsste es ja glatt gehen.

Was mir aber jetzt aufgefallen ist: Seit ich die IDE auf D: installiert habe, verliere ich sehr oft die Verbindung zum Board. D.h., ich muss das USB-Kabel ab- und wieder anstecken um eine COM-Verbindung zu erhalten.

Ich habe die IDE schon lange auf einem anderen Laufwerk installiert, und keine solchen Probleme beobachtet (Win8). Irgendwie sieht das nach einem Treiber-Problem aus.