Hallo alle, ich benutze Eclipse zur AVR-Entwicklung und ich werde inzwischen wahnsinnig mit den Projektabhängigkeiten, das klappt hinten und vorne nicht richtig. Ich mache das aktuell so: - AVR Programme mit: New Project > C++ Project > AVR Cross Target Application - Libraries (Uart, Fifo, etc.), die ich in mehreren Projekten verwenden will mit: New Project > C++ Project > AVR Cross Target Static Library Damit gibt es folgende Probleme: - ich muss bei jeder Library immer die Target Hardware angeben, d.h. wenn ich Projekt wechsle (und das eine andere Target Hardware hat, also Atmega8 > Attiny45), dann muss ich bei den Libraries auch das Target umstellen, sehr unpraktisch - ich muss immer beim AVR Programm-Project beim AVR Linker extra einstellen welche Objects (*.o) er sich woher holen soll aus den Library-Projekten, ich wundere mich, dass es keinen Weg gibt, dass die automatisch gefunden werden Ich tue nun schon eine ganze Zeit rum und finde keine bessere Lösung. Gibt es einen besseren Weg die Libraries auf eine Weise abzulegen, dass die obigen Probleme entfallen, also: - die Target Hardware-Einstellung wird beim Compile einfach vom referenzierenden Parent-Projekt übernommen - die .o werden einfach im Parent-Projekt abgelegt und damit passt auch immer die Target Hardware der .o's Danke für Eure Tipps, Konrad
Dann nutz eben nicht so eine Bloatware wie eclipse! Nimm zB Programmers Notepad, schön schlank und bei Winavr dabei. AVR Modell stellste im makefile ein und schreibst urnochn include der libs ins Program, läuft.
Das wäre theoretisch eine Möglichkeit, habe ich auch schon dran gedacht. Aber ich habe mich in jahrelanger Anwendung von Eclipse in Java so an die Komfortfunktionen gewöhnt, dass ich nicht darauf verzichten möchte. Zugegebenermassen funktioniert es für C nicht ebenso gut, aber trotzdem ist es komfortabler als Texteditor.
Martin Wende schrieb: > Dann nutz eben nicht so eine Bloatware wie eclipse! > > Nimm zB Programmers Notepad, schön schlank und bei Winavr dabei. > AVR Modell stellste im makefile ein und schreibst urnochn include der > libs ins Program, läuft. Du bist ein Vogel. Moderne Tools gehören heute dazu. Niemand entwickelt ernsthaft mehr so wie du das beschreibst. Das ist weder effizienter noch hat es andere Vorteile. Damit gibt man nur zu dass man mit modernen Tools überfordert und nicht lernbereit ist. gruß cyblord
Seh ich ja grade wie Toll und einfach das ist ;)
Jeder wie er mag :-) Hat denn noch jemand einen konstruktiven Tipp für mich?
Martin Wende schrieb: > Seh ich ja grade wie Toll und einfach das ist ;) Ob Eclipse für AVR-Progammierung gut geeignet ist weiß ich nicht, aber mit Codeblocks z.B. kann ich schon ganz gut arbeiten. Allerdings fehlen mir in Codeblocks noch ein paar Sachen, die z.B. Java-IDEs haben. Trotzdem kann es mehr als ein Texteditor. Mir reicht das als Grund, es zu verwenden :) 42m
cyblord ---- schrieb: > Moderne Tools gehören heute dazu. Das hast du vollkommen recht. > ich benutze Eclipse zur AVR-Entwicklung und ich werde inzwischen > wahnsinnig mit den Projektabhängigkeiten, das klappt hinten und vorne > nicht richtig. Jede Klappse wird dir das bestätigen.
Kannst dir ja noch AVR STudio angucken so als konstruktiver Vorschlag ;) Kann dazu aber nich viel sagen, nur mal angesehen und dann nie verwendet.
Häufig sind ja von Projekt zu Projekt neben CPU-Takt und Typ ja noch weitere Änderungen in den „Libs“ erforderlich, z.B. die Belegung der IO-Ports oder die Baudrate oder der TWI-Takt, … Dazu muss man aus den Dateien der „Libs“ auf die h-Dateien aus dem Projekt zugreifen können. Meine Lösung sieht so aus: In jedem Projekt (-Ordner) gibt es eine Datei _Options.h für allgemeine Einstellungen sowie eine _Io.h für die Zuordnung der Hardware. Die Quelltexte der „Libs“ liegen in einem Ordner (mit Unterordnern) auf gleicher Ebene zu den Projekt-Ordnern, z.B. Libs. Bei Bedarf enthalten die *.h- und *.c- Dateien „#include _Options.h“ und /oder „#include _Io.h“ für die Äbhängigkeiten vom Projekt. Im Projekt-Ordner wird ein „Linked Folder“ auf diesen Ordner Libs angelegt. Damit gehören ALLE Dateien aus dem Ordner Libs und dessen Unterordnern zum Projekt (ggf. kann/muss man hier über „Resource Configurations, Exclude from Build“ eingreifen; oder man regelt das über die _Options.h per #define…). Man kann mit dem Editor so auf die Dateien zugreifen, als ob sie im Projekt-Ordner lägen. Änderungen an diesen Dateien gelten aber auch für anderer Projekte, die obigen „Linked Folder“ enthalten, da sie physikalisch ja nur einmal vorhanden sind. (Wenn ein solches Projekt während der Änderung geschlossen war, merkt Eclipse nach dem nächsten Öffnen, dass eine Abweichung vorliegt; bei der Version Indigo muss man dann manuell „F5-Refresh“ ausführen, bevor man an den Dateien weiterarbeiten kann). In den Settings des Projektes unter C/C++ Build, Settings, AVR Compiler, Directories, Include Paths die Pfade hinzufügen (entsprechend angepasst; ${ProjName} ist eine Eclipse-Variable; auf diese Weise ist es möglich, ein Projekt zu kopieren und umzubenennen, ohne den Pfad ändern zu müssen): D:/Eclipse/WorkspaceAvr/${ProjName} und D:\Eclipse\WorkspaceAvr\Libs (die Slash und Backslash haben sich bei mir aus unerfindlichen Gründen so ergeben;) Zum Sichern eines Entwicklungsstandes oder einer fertigen Version zippe ich den Projekt-Ordner (um den Projekt-Namen zu haben) und ziehe dann noch den Libs-Ordner in die Zip-Datei.
@Josef Jaaaaaa, das klingt nach der Lösung, die ich gesucht habe!! Vielen Dank! Bin auch gerade eben dabei mich dorthin zu tasten, hätte aber sicher noch einige Stunden gebraucht da anzukommen. Hatte zuletzt Project Dependencies versucht und die Libs als Static Library Projekt eingestellt, aber das hat diverse Probleme (jeder Build mit anderer Hardware-Plattform überschreibt im /Release oder /Debug der Lib die .o's und beim Platformwechsel immer komplett neu builden mit der Gefahr, dass irgendwo doch noch nicht gecleant ist usw.) Gleich mal ausprobieren, grade dabei ein neues Projekt aufzusetzen und hätte jetzt schon wieder alle Libs umstellen müssen auf die neue Hardware etc. nerv
Weiss ja nicht, wie das hier im Forum gemacht wird ... aber wäre sowas nicht ein Thema für ein Tutorial? "Best practise: Wie setze ich einen Multiprojekt-Workspace in Eclipse für AVR auf" Hat mich bisher viel Zeit gekostet mich mit mehreren Projekten rumzuschlagen...
@Josef Das sieht super aus, jetzt habe ich alle Object files unter meinem Project und nicht unter den Libs, hervorragend! Jetzt hab ich grad noch ein Problemchen: es gibt z.B. in mehreren Dateien einen bestimmten Interrupt-Handler, damit bekomme ich jetzt vom Linker Fehlermeldungen wie: buzzer.c:(.text+0x22): multiple definition of `__vector_3' ./libs/ppsend/ppSend.o:ppSend.c:(.text+0x234): first defined here Wobei er aber natürlich beim jeweiligen Projekt nicht alle .c-Files mitlinken sollte, brauche ja nur einen Teil der Libs. Müsste ja nichtmal compiliert werden. Was wäre eine elegante Lösung hierfür? Meintest Du das mit dem Exclude Resources oder den #define's?
Bin begeistert, das geht super. Compiliert viel schneller als in separaten Projekten und ich habe den Eindruck der Code Size ist auch kleiner. Habe jetzt die nicht benötigten Libs über rechte Maustaste auf das Lib-Verzeichnis > Resource Configurations > Exclude from build... herausgenommen, geht recht gut und ist auch nicht aufwändig zu machen.
Konrad G. schrieb: > Meintest Du das mit dem Exclude Resources oder den #define's? genau. Das "Exclude..." geht ja nur mit Dateien, die schon existieren. Ist ein Projekt fertig und man fügt für ein neues Projekt eine (.c-)Datei in Libs dazu, dann wird die beim nächsten compilieren des fertigen Projekts auch mit eingebaut (mit den oben genannten Problemen). Deshalb bin ich dazu übergegangen, in allen *.c-Dateien im Prinzip folgende Konstruktion zu verwenden: XXXX.h-Datei: #include "_Options.h" #ifdef USE_XXXX // wird in _Options.h definiert oder nicht # define USES_XXXX 1 // + ggf. weitere Default-Werte etc. #else # define USES_XXXX 0 #endif XXXX.c-Datei: #include "XXXX.h" #if USES_XXXX //... gesamter Rest der ursprünglichen c-Datei #endif
Ok, da warte ich mal darauf bis mich das das erste Mal nervt und überlege mir das. Momentan möcht ich lieber nicht alle c-files komplett #ifdef'en... Besten Dank, Josef, hast mir sehr weitergeholfen und mir viele Stunden rumprobieren erspart. VG, Konrad
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.