Hallo Leute, ich wollte jetzt mal meine wichtigen "Libs", also z.B. für 1-Wire, LCD usw. in echte binäre Libraries umwandeln. Habe dazu ein neues Projekt (Static Library) angelegt. Funktioniert auch alles soweit. Nur muss ich natürlich dafür auch die Zielplattform, also den AVR-Typ auswählen. Wenn ich später ein Projekt habe, und diese lib verwenden will, aber die Typen stimmen nicht überein, bekomme ich einen Linkerfehler "incompatible library". Aber es muss doch möglich sein, high-level libs zu schreiben, welche für viele AVR-Typen gleichzeitig geeignet sind. Oder nicht? Bitte um Infos wie das Grundsätzlich aussieht. Also es geht um avr-gcc und ich entwickle in Eclipse. gruß cyblord
Der Befehlssatz der AVR wurde immer wieder erweitert. Die Übersichtsseite für gcc zählt nicht weniger als 10 unterschiedliche Architekturen für die 8-bit AVR auf: http://www.nongnu.org/avr-libc/user-manual/using_tools.html Üblicherweise kann man aber nur Module für die gleiche Architektur linken, weil binärkompatibilität nicht garantiert werden kann. In der Regel unterscheiden sich nicht nur der Befehlssatz (ISA) sondern u.U auch die Register- und Aufrufkonventionen usw. (ABI). Das ist zum Beispiel bei ARM besonders schlimm. Du musst also deine Bibliothek für jede gewünschte Architektur gesondert kompilieren. Ich benutze nur Makefiles, das ist das mit ein paar Zeilen erledigt, bei Eclipse muss man wohl Targets oder so'n Zeugs anlegen.
cyblord ---- schrieb: > ich wollte jetzt mal meine wichtigen "Libs", also z.B. für 1-Wire, LCD > usw. in echte binäre Libraries umwandeln. Wozu, um Deine Source vor den Blicken anderer zu schützen? Dann mußt Du aber die Lib für einen bestimmten Typ, bestimmten Takt, bestimmte Pinbenutzung usw. festlegen. Ich lasse die Libs daher als Source, dann bin ich flexibel. Auch kann ich dann in der Lib debuggen, falls doch noch ein Fehler drin sein sollte. Oder die Lib erweitern. Peter
Eine weitere Möglichkeit wäre du machst es geschichtet.. eine highlevel Bibliothek die auf eine Treiberschicht zugreift, die treiberschicht musst du hald für jeden Prozessor neu machen. Die Herausforderung dabei ist wie du die Schnittstellen machst.. am besten mit structs oder mit funktion callback. Das ist dann hald die Schwierigkeit.
Peter Dannegger schrieb: > cyblord ---- schrieb: >> ich wollte jetzt mal meine wichtigen "Libs", also z.B. für 1-Wire, LCD >> usw. in echte binäre Libraries umwandeln. > > Wozu, um Deine Source vor den Blicken anderer zu schützen? Nein, eben um sie flexibel in mehreren Projekten nutzen zu können. > > Dann mußt Du aber die Lib für einen bestimmten Typ, bestimmten Takt, > bestimmte Pinbenutzung usw. festlegen. Abgesehen von der Pinbenutzung hast du recht. Diese wird flexibel übergeben. Der Rest ist eben gerade mein Problem. > Ich lasse die Libs daher als Source, dann bin ich flexibel. Auch kann > ich dann in der Lib debuggen, falls doch noch ein Fehler drin sein > sollte. > Oder die Lib erweitern. Würde ich auch gerne so machen. Also dass die "libs" immer nur einmal als Sourcen rumliegen und alle Projekte die verwenden können. Aber da habe ich momentan das Problem das ich dies nicht konfiguriert bekomme. Sicher kann man das mit eigenen Makefiles lösen, aber ich nutze Eclipse und brauche eine konsistente Umgebung. Ich kann in Eclipse zwar header Dateien von außerhalb einbinden, und auch libs aber keine c sources. Eventuell weißt du ja wie das geht, oder ebentuell analog dazu wie du das so handhabst. @codefux: Ja natürlich mache ich so nur highlevel libs aber auch die müssen leider für Prozessor und Takt kompiliert werden. Übergabe von Ports usw. per Struct ist kein Problem, das funktioniert gut. gruß cyblord
Was meinst du mit "keine C-Sources von ausserhalb"? Du kannst einem Eclipse-Projekt Sourcen aus beliebigen Verzeichnissen deiner Festplatte hinzufügen. Einfach mit der Maus aus dem jeweiligen Ordner in den Eclipse-Projekt-Ordner ziehen. Eclipse fragt dann, ob das File in den workspace kopiert werden (soll es nicht) oder als Verweis eingefügt werden soll (soll es). Fertig. Professioneller wäre allerdings auch hier der Einsatz eines Sourcecode-Verwaltungssystems. Oliver
Ich benutze eine Batch. Die Lib liegt im übergeordneten Verzeichnis neben den Projekten: set lib1=../CLib/ avr-gcc.exe *.c %lib1%*.c ... Peter
Oliver S. schrieb: > Was meinst du mit "keine C-Sources von ausserhalb"? > > Du kannst einem Eclipse-Projekt Sourcen aus beliebigen Verzeichnissen > deiner Festplatte hinzufügen. Einfach mit der Maus aus dem jeweiligen > Ordner in den Eclipse-Projekt-Ordner ziehen. Eclipse fragt dann, ob das > File in den workspace kopiert werden (soll es nicht) oder als Verweis > eingefügt werden soll (soll es). Fertig. Du hast recht, das Einfügen als Verweis habe ich noch gar nicht bedacht. > Professioneller wäre allerdings auch hier der Einsatz eines > Sourcecode-Verwaltungssystems. Was meinst du? Natürlich nutze ich SVN, aber was genau bringt mir das in dieser Situation? Bitte mehr Infos. gruß cyblord
cyblord ---- schrieb: > Oliver S. schrieb: >> Professioneller wäre allerdings auch hier der Einsatz eines >> Sourcecode-Verwaltungssystems. > Was meinst du? Natürlich nutze ich SVN, aber was genau bringt mir das in > dieser Situation? Bitte mehr Infos. > > gruß cyblord Vermutlich meint er, daß du die Bibliothek in einem SVN Zweig pflegst und wenn du sie in einem Projekt einsetzen willst, einfach mit svs:externals anbindest. Du kannst dann im wesentlichen so arbeiten, als würde die Bibliothek inkl. Sourcen zu deinem Projekt gehören. Fixes usw. gehen dann aber wieder in den Ast der Bibliothek zurück und können dann durch ein "svn update" gleich in anderen Projekten genutzt werden die diese Bibliothek nutzen. http://svnbook.red-bean.com/en/1.0/ch07s03.html
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.