Hallo! Ich habe gerade eine Library für ATMega48, ATMega88 und ATMega168 kompiliert. ATMega48 und ATMega88 sind avr4 und ATMega168 ist avr5- der Unterschied liegt wohl bei "__AVR_HAVE_JMP_CALL__" alle drei teilen sich ein gemeinsames Datenblatt und ich sehe da keine Sonderstellung des 168ers. Wieso bekommt der 168er also eine andere Architektur zugewiesen? Warum sind die Bibliotheken nicht binär gleich? Gibt es eine Möglichkeit zumindest für ATMega48 und ATMega88 eine einzige Bibliothek zu erstellen? Könnte diese dann nach $toolchain/lib/avr4 installiert werden? Weiterhin sehe ich im lib Verzeichnis der Toolchain Unterverzeichnisse für die verschiedenen Architekturen- aber es liegen auch Libraries einfach so im lib Verzeichnis- sind die universell? Danke!
Heiko L. schrieb: > Wieso bekommt der 168er also eine andere Architektur zugewiesen? Was der Name schon sagt: Bis 8KB Flash kann man mit RJMP/RCALL überall hin springen, jenseits davon nicht mehr. Infolgedessen existieren die JMP/CALL Befehle nur beim 168 und auch die Interrupt-Sprungleiste ist verschieden, mit 2 Bytes vs 4 Bytes pro Eintrag.
Da ist natürlich etwas dran. Der Befehlssatz steht natürlich nicht im Datenblatt mit drin. Ich denke mal, dass die Frage der Unterbringung meiner Lib unter /lib/avr4 auch gegessen ist (selbst wenn ich die Libs von ATMega48 und 88 binär gleich bekomme)- ich benutze in den Libs Peripherie und ich glaube nicht, dass die bei allen avr4- Architekturen an den gleichen Adressen sitzen. Bleibt noch die Frage, warum die Libs auch außerhalb der Architekturverzeichnisse bestehen. Danke!
Heiko L. schrieb: > Da ist natürlich etwas dran. Der Befehlssatz steht natürlich nicht im > Datenblatt mit drin. Natürlich steht er drin. In der Langfassung, nicht der Summary.
> Natürlich steht er drin.
Hmpf.
Wichtige Regeln - erst lesen, dann posten
Sollte auch im Datenblatt stehen :D
Heiko L. schrieb: > Bleibt noch die Frage, warum die Libs auch außerhalb der > Architekturverzeichnisse bestehen. Den Satz versteh ich überhaupt nicht. Stell die Frage nochmal.
> Den Satz versteh ich überhaupt nicht. Stell die Frage nochmal. Ok, ich bringe mal ein Beispiel. Ich habe die AVR- Toolchain von Atmel installiert. Da gibt es die libgcc.a unter "AVR Toolchain\lib\gcc\avr\4.5.1", sowie unter "AVR Toolchain\lib\gcc\avr\4.5.1\avr25", "AVR Toolchain\lib\gcc\avr\4.5.1\avr3" [...]. Für welche Architektur ist denn da die libgcc.a unter "AVR Toolchain\lib\gcc\avr\4.5.1"?
ehrlich gesagt würde ich die Lib(im funktionalen Sinn) überhaupt nicht als Lib(im compilertechnischen Sinn) ausliefern oder ablegen. Ich würde sie als Source im Projekt direkt mit einkompilieren. Das ausliefern vorkompilierter Libs macht imho nur Sinn, wenn es nur wenige unterschiedliche Zielplattformen gibt. Für so diversitäre Zielplattformen wie µCs ist das imho umständlich und fehleranfällig.
Heiko L. schrieb: >> Den Satz versteh ich überhaupt nicht. Stell die Frage nochmal. > > Ok, ich bringe mal ein Beispiel. Ich habe die AVR- Toolchain von Atmel > installiert. > > Da gibt es die libgcc.a unter "AVR Toolchain\lib\gcc\avr\4.5.1", sowie > unter "AVR Toolchain\lib\gcc\avr\4.5.1\avr25", "AVR > Toolchain\lib\gcc\avr\4.5.1\avr3" [...]. > > Für welche Architektur ist denn da die libgcc.a unter "AVR > Toolchain\lib\gcc\avr\4.5.1"? Die Multilib-Konfiguration des aktuellen avr-gcc ist: $ avr-gcc -print-multi-lib .; avr25;@mmcu=avr25 avr3;@mmcu=avr3 avr31;@mmcu=avr31 avr35;@mmcu=avr35 avr4;@mmcu=avr4 avr5;@mmcu=avr5 avr51;@mmcu=avr51 avr6;@mmcu=avr6 avrxmega2;@mmcu=avrxmega2 avrxmega4;@mmcu=avrxmega4 avrxmega5;@mmcu=avrxmega5 avrxmega6;@mmcu=avrxmega6 avrxmega7;@mmcu=avrxmega7 tiny-stack;@mtiny-stack avr25/tiny-stack;@mmcu=avr25@mtiny-stack Links vom ; steht das Unterverzeichnis ab der Multilib-Wurzel und rechts davon die Option(en), wie man da hinkommen kann. Für . also: Keine Optionen, d.h. für den Default -mmcu=avr2. Der wird genommen, wenn kein -mmcu= angegeben ist. Die Multilib-Granularität im avr-gcc richtet sich nach dem Instruktionssatz. Wenn, wie ober bereits erklärt, die Granularität feiner sein muss, zB weil I/O verwendet wird, muss dies durch die Granularität des jeweiligen Multilib-Layouts abgebildet werden. Oder ein Quell-Repository ausliefern anstatt (Multi)libs.
Johann L. schrieb: > Für . also: Keine Optionen, d.h. für den Default -mmcu=avr2. Der wird > genommen, wenn kein -mmcu= angegeben ist. > > Die Multilib-Granularität im avr-gcc richtet sich nach dem > Instruktionssatz. Wenn, wie ober bereits erklärt, die Granularität > feiner sein muss, zB weil I/O verwendet wird, muss dies durch die > Granularität des jeweiligen Multilib-Layouts abgebildet werden. Oder ein > Quell-Repository ausliefern anstatt (Multi)libs. Ah, danke! Vlad Tepesch schrieb: > ehrlich gesagt würde ich die Lib(im funktionalen Sinn) überhaupt nicht > als Lib(im compilertechnischen Sinn) ausliefern oder ablegen. > Ich würde sie als Source im Projekt direkt mit einkompilieren. Wobei da die Versuchung groß ist, gleich die Source- Dateien ins Projektverzeichnis zu kopieren ;)
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.