Gast
#3011064
Hallo, wie es aussieht wird WINAVR nicht mehr geben oder? schade. Ist schwierig so ein "Tool-Paket" für Windows erstellen? kennt jemand ein gute Anleitung dafür?
Carlos schrieb: > Hallo, > > wie es aussieht wird WINAVR nicht mehr geben oder? schade. > Ist schwierig so ein "Tool-Paket" für Windows erstellen? kennt jemand > ein gute Anleitung dafür? Ne ist ganz easy. Da gibts nen Tutorial mit 4 einfachen Schritten. Beim Atmel Studio ist eine aktuelle WinAVR Toolchain dabei. Darum wird es auch nicht separat weiterentwickelt. gruß cyblord
Gast
#3011088
cyblord ---- schrieb: > Ne ist ganz easy. Da gibts nen Tutorial mit 4 einfachen Schritten. Kennst du eventuell den Link? cyblord ---- schrieb: > Beim Atmel Studio ist eine aktuelle WinAVR Toolchain dabei. Darum wird > es auch nicht separat weiterentwickelt. Ist klar aber ich will nicht unbedingt Atmel Studio.
Carlos schrieb: > cyblord ---- schrieb: >> Ne ist ganz easy. Da gibts nen Tutorial mit 4 einfachen Schritten. > > Kennst du eventuell den Link? Grad verlegt. War aber echt easy. > > cyblord ---- schrieb: >> Beim Atmel Studio ist eine aktuelle WinAVR Toolchain dabei. Darum wird >> es auch nicht separat weiterentwickelt. > > Ist klar aber ich will nicht unbedingt Atmel Studio. Musst du auch nicht. Die Toolchain ist da dabei, aber das heißt noch lange nicht dass du auch das Studio nutzen musst.
Gast
#3011147
WinAVR wird seit 2010 nicht mehr weiter entwickelt. Brauchbar ist es dennoch. Das Projekt wurde von Atmel unter dem Namen "AVR Toolchain" übernommen. Sie ist seit Version 4.19 in AVR Studio enthalten, aber auch einzeln downloadbar. Ich bevorzuge allerdings immer noch WinAVR, denn der C Compiler wurde innerhalb der letzten Monate mehrfach so sehr geändert, dass mein wichtigstes Projekt mal nicht mehr compilierte und mal defekter Code generiert wurde. Mit WinAVR hatte ich nie derartige Probleme. WinAVR ist eine Portierung des avr-gcc, der wiederum ein Ableger vom gcc ist, mit dem Linux compiliert wird. Der avr-gcc wird immer noch gepflegt und ist in jeder Linux Distribution enthalten. Wir haben also die Qual der Wahl: 1) avr-gcc (Linux und andere Unix-Artige Betriebssysteme) 2) WinAVR 2010 (Windows, Ableger von avr-gcc, nicht mehr gepflegt) 3) Atmel AVR Toolchain (Windows, Ableger von WinAVR) Die drei Compiler sind nicht mehr identisch, deswegen sind umfangreichere Projekte nicht zu jedem Compiler kompatibel.
Gast
#3011832
Wenn man sich an die Sprache hält, keinen "Mist" programmiert, und keine compiler spezifischen befehle/makros nutzt, dann muss jeder compiler das projekt compiliren. Wenns nicht so ist, dann habt ihr was falsch gemacht. wenn ich lese: "Der Compiler ist neu und macht plötzlich mist" dann liegt das in 99,99% daran das der code schon immer falsch war, und der "alte" compiler das einfach hingenommen/ignoriert hat. Nur weil es funktioniert, was man da Programmiert, heißt das noch lange nicht, das es auch richtig ist! ;)
Gast
#3011841
@undefined: FullACK! Compilerunabhängigen Code erstellen sollte man schon können, das nicht nur wegen dem hier beschriebenen "Problem" aber auch gerade deswegen dass es immer mal passieren kann dass altes nicht mehr weiterentwickelt wird, die Person welche die Maintenance durchgeführt hat was besseres zu tun bekommt oder einfach mal keine Lust dazu hat, oder wenn man einen kommerziellen Compiler verwendet die Firma Pleite geht usw. Von dem her ist es schon Vorteilhaft wenn man seinen Code gleich Compilerunabhängig schreibt. Sonst will jeder Portierbarkeit erreichen, meistens scheitert das dann an so etwas wie das hier ;-)
Gast
#3011844
cyblord ---- schrieb: > Ne ist ganz easy. Da gibts nen Tutorial mit 4 einfachen Schritten. Du solltest Ironie besser kennzeichnen!
Stefan schrieb: > Wir haben also die Qual der Wahl: > > 1) avr-gcc (Linux und andere Unix-Artige Betriebssysteme) > 2) WinAVR 2010 (Windows, Ableger von avr-gcc, nicht mehr gepflegt) > 3) Atmel AVR Toolchain (Windows, Ableger von WinAVR) > > Die drei Compiler sind nicht mehr identisch, deswegen sind > umfangreichere Projekte nicht zu jedem Compiler kompatibel. 4) Verfügbare Builds nutzen, etwa wie beschrieben und verlinkt in: http://lists.gnu.org/archive/html/avr-gcc-list/2012-09/msg00026.html Das ist ein 4.7.2 für Windos, und die Mail sollte keine Fragen zu dem Build offen lassen. Im Vergleich zu dem 4.6.2 vom Atmel sind u.a. folgende Unterschiede zu erwähnen: - Es sind nur Compiler, Binutils und AVR-Libc enthalten - Support von Embedded C Named Address Spaces wie __flash. avr-gcc-Tutorial: flash und Embedded-C - Weniger Devices werden unterstützt, insbesondere für Xmega. Im GCC Wiki ist beschrieben, mit welchen Optionen der Compiler aufzurufen ist, um auch für diese "nicht-nuterstützten" AVRs Code generieren: http://gcc.gnu.org/wiki/avr-gcc#Supporting_.22unsupported.22_Devices - Kein Fixed-Point Support (der im offiziellen avr-gcc erst in der 4.8 kommt, und dort nicht binärkompatibel zu dem von Atmel) - Viele neue Optimierungen und behobene Bugs. Neue Features wie Link-Time Optimierung (LTO). Beim Umstieg lese man auch die Release Notes! 4.7: http://gcc.gnu.org/gcc-4.7/changes.html 4.6: http://gcc.gnu.org/gcc-4.6/changes.html 4.5: http://gcc.gnu.org/gcc-4.5/changes.html Insbesondere die Teile, die sich auf AVR beziehen!
Hinweis: Die automatische Verlinkung zu Embedded C ist natürlich Käse, da kann ich nix für!
Gast
#3011908
Johann L. schrieb: > Im Vergleich zu dem 4.6.2 vom Atmel sind u.a. folgende Unterschiede zu > erwähnen: was ist das für eine Versionsnummer? Auf der Atmel seite finde ich nur: Atmel AVR 8-bit and 32-bit Toolchain 3.4.1 - Windows http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx
Peter II schrieb: > Johann L. schrieb: >> Im Vergleich zu dem 4.6.2 vom Atmel sind u.a. folgende Unterschiede zu >> erwähnen: > > was ist das für eine Versionsnummer? Ich rede vom GCC und seiner Version: http://gcc.gnu.org WinAVR 20100110 ist zum Beispiel Version 4.3.3 (plus Patches). Fragst zu einfach gcc:
1 | |
Peter II schrieb: > was ist das für eine Versionsnummer? 4.6.2 ist die gcc-Versionsnummer, so wie sie das gcc-Entwicklungsteam zählt. Der avr-gcc wird von Atmel zusammen mit weiteren Entwicklungswerkzeugen in ein "AVR Toolchain" genanntes Paket gepackt, für das Atmel eigene (Paket-)Versionsnummern hat. Grüße Stefan
Gast
#3014670
Stefan schrieb: > Das Projekt wurde von Atmel unter dem Namen "AVR Toolchain" übernommen. > Sie ist seit Version 4.19 in AVR Studio enthalten, aber auch einzeln > downloadbar. Ok ist klar, ich habe es gefunden und runtergeladen aber wie kann ich mein Notepad Programmers (die bei WinAVR dabei ist) überreden dass er dann vom AVR Toolchain Compaliert? Gibt es ein Trick?
Keine Ahnung wie das bei Programmers Notepad geht. Aber allgemein läuft das so, dass eine IDE die Aufrufe der Programme (z.B. avr-gcc) in den Einstellungen mitgeteilt bekommt. Aber meist nur der Name. Es muss dann in der Betriebssystemeinstellung unter "Umgebungsvariablen" in die Variable PATH mit vollem Pfad eingetragen werden. So kann man überall im System das Programm einfach mit Eingabe des Namens starten. Testen kann man das selbst in der Eingabeaufforderung. Oft steht auch gleich der ganze Ordner (z.B c:\WinAvr\bin;c:\WinAvr\utils). D.h. eine neue Toolchain kommt in einen neuen Ordner. Und in der PATH Variable werden dann die Pfade zu den Programme die dort stehen auf den neuen Ordner gestellt. D.h. in den Einstellungen der IDE selbst muss meist gar nichts geändert werden. gruß cyblord
Gast
#3015565
Carlos schrieb: > Gibt es ein Trick? Die Verbindung zwischen WinAVR & PNP stellen das Programm make.exe und das Skript Makefile her(Einstellungen siehe Bild im Anhang).
Angehängte Dateien:
-
PNP.gif
(46 KB)
Gast
#3015632
Demnach muss die Umgebungsvariable PATH angeben, wo sich die make.exe befindet. Make ruft allerdings auch avr-gcc und einige andere Programme auf, die dazu gehören. Die müssen auch im Suchpfad liegen. Bei WinAVR liegt make in einem anderem Verzeichnis, als avr-gcc, darum ist das obige Beispiel mit zwei Pfaden korrekt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.