Zum Übersetzen, Linken und auf das Target laden verwende ich seit Jahren WinAVR. Die letzte offizielle WinAVR-Zusammenstellung stammt von 2010. Es gab Hinweise für ein Update: Beitrag "Update von Winavr2010 auf gcc 4.8 Howto" Beitrag "Re: WinAVR 2010 / AVR-GCC und Atmega48PA" unter der Atmel-Adresse ist kein Paket mehr zu finden: http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx Bei Microchip kann man avr8-gnu-toolchain-3.6.2.1759-win32.any.x86.zip herunterladen unter https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers Im Readme avr8-gnu-toolchain-3.6.1.1752-readme.pdf steht der Hinweis: Downloading/Installing on Windows "If you want to try the Atmel AVR8 GNU toolchain alone, you can download it from here". Im Vergleich zu WinAVR2010 sind im zip neuere Versionen: - GCC: 5.4.0 statt 4.3.3 in WinAVR2010 - binutils: 2.26 statt 2.19 in WinAVR2010 - avr-libc: 2.0.0 statt 1.6.7 in WinAVR2010 leider sind kaum Hinweise gegeben wie ein Update von WinAVR2010 mit diesem Paket gemacht werden soll. nicht im zip-Paket enthalten sind - AVRDUDE - USB-Treiber für AVRDUDE libusb0.dll - make.exe - Utils für Nutzung im Makefile. um vorhandene Makefiles die bisher unter WinAVR2010 liefen zu nutzen reicht es also nicht das zip-file einfach auszupacken. es ist nötig etwas zusammenzubasteln. Microchip schreibt: "If the toolchain is installed separately.... upgrading is not supported. You can install the new package side-by-side of the old package and use it." Hier ein paar Hinweise die bei mir zu einer lauffähigen Version unter Win7 64bit geführt haben: Verzeichnis C:\WINAVR anlegen avr8-gnu-toolchain-3.6.2.1759-win32.any.x86.zip in diesem Verzeichnis auspacken, dann das zip löschen Dateien nach C:\WINAVR\bin hinzukopieren wie - avrdude.exe (neuere Fassung, z.B. 6.3 aus dem Netz) - avrdude.conf (neuere Fassung aus dem Netz) - giveio.sys aus Arduino (fuer ISP-Programmierung per Parallel-Port) - install_giveio.bat aus Arduino - remove_giveio.bat aus Arduino - status_giveio.bat aus Arduino - cygwin1.dll aus WinAVR - itcl32.dll aus WinAVR - itk32.dll aus WinAVR - libiconv-2.dll aus Arduino - libusb0.dll aus Arduino - srec_cat.exe aus WinAVR - splint.exe aus WinAVR - tcl84.dll aus WinAVR - tclpip84.dll aus WinAVR - tclsh84.exe aus WinAVR - tk84.dll aus WinAVR - wish84.exe aus WinAVR Dateien nach C:\WINAVR\utils\bin kopieren die in WinAVR2010 waren enthält in bin: - cp.exe aus WinAVR - diff.exe aus WinAVR - echo.exe aus WinAVR - make.exe aus WinAVR (ggf. neues make.exe nehmen) - msys-1.0.dll aus WinAVR - rm.exe aus WinAVR - sed.exe aus WinAVR - sh.exe aus WinAVR - msys-1.dll aus WinAVR - ... Dateien nach C:\WINAVR\doc hinzukopieren wie alte Ordner - avrdude - Doku dazu aus WinAVR - gcc - Doku dazu aus WinAVR - gdb - Doku dazu aus WinAVR - splint - Doku dazu aus WinAVR Registry ggf. anpassen mittels Regedit: - in Registry nach WinAVR suchen -> Stellen in HKEY_LOCAL_MACHINE HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Free Software Foundation\WINAVR\BINUTILS -> C:\WINAVR HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Free Software Foundation\WINAVR\G++ -> C:\WINAVR HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Free Software Foundation\WINAVR\GCC -> C:\WINAVR HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\WinAVR\20100110 -> C:\WINAVR HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\AVR32_HOME -> C:\WINAVR Suchpfad ggf. ändern: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path -> C:\WINAVR\bin;C:\WINAVR\utils\bin;%SystemRoot%\system32;%SystemRoot%;%Sy stemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\ den Deinstallierpfad ggf. lassen. nach Booten des Rechners werden die Änderungen wirksam. im Vergleich zu WinAVR2010 zeigten sich folgende Codegrößen: LED-Blink-Programmm auf Atmega32U4: main.hex 6kB vs. 5kB bei WinAVR2010 data+text 1834 bytes vs. 1720 bytes bei WinAVR2010 Laststeuerprogramm mit ADC/DAC/RTC/SRAM auf Atmega2560: main.hex 24kB vs. 25kB bei WinAVR2010 data+text 428+8068 bytes vs. 446+8458 bytes bei WinAVR2010 unschön groß erscheint der totale Speicher incl. der Debug-Informationen. 59187 bytes vs. 39231 bytes bei WinAVR2010. Am Makefile wurde nichts verändert. Die Einstellungen sind dieselben wie bei WINAVR2010. Vielleicht helfen diese Angaben dem einen oder anderen sich auch ein neueres WinAVR auf Basis der obigen aktuellen zip-Datei einzurichten. Viel Erfolg ! Matthias
Hm. Man kanns auch unnötig kompliziert machen. WinAVR ist ja nun nix anderes als ein avr-gcc, gebündelt mit Notepad++ und MFile. Das war zu seiner Zeit damals eine tolle Sache, weil's für Windows nichts besseres gab, aber das ist lange her. Das Stichwort Atmel Studio ist ja schon gefallen, auch noch zu nennen sind Eclipse mit Avr-plugin, oder Codeblocks. Alles ausgewachsene IDEs, die über das vom Notepad++ gebotene weit hinausgehen. Eine wirklich aktuellen avr-gcc mit make gibt es hier: http://blog.zakkemble.net/avr-gcc- builds/ Dazu ein aktuelles MFile zum Erstellen von makefiles, oder eben eine richtige IDE, und man ist im 21 Jahrhundert. Oliver
Matthias W. schrieb: > leider sind kaum Hinweise gegeben wie ein Update von WinAVR2010 mit > diesem Paket gemacht werden soll. Weil es kein Update ist sondern eine "andere" Toolchain. Die 2 Toolchains (oder mehr) können parallel genutzt werden, es besteht keine Notwendigkeit, beide Toolchains zu Frankensteins Monster zu verwursten. > nicht im zip-Paket enthalten sind [...] Deshalb bleiben die alten Pfade in PATH. > es ist nötig etwas zusammenzubasteln. Nope. > Microchip schreibt: "If the toolchain is installed separately.... > upgrading is not supported. You can install the new package side-by-side > of the old package and use it." Genau. Einfach den Pfah in PATH eintragen (vor dem von WinAVR) und gut iss. Da braucht's weder Rumgewusel im Dateisystem noch Remstochern in der Registry! > Verzeichnis C:\WINAVR anlegen > avr8-gnu-toolchain-3.6.2.1759-win32.any.x86.zip in diesem Verzeichnis > auspacken, dann das zip löschen Und ggf. Pfad anpadden, so dass keine Sonderzeichen drinne sind. Weil die Tools mi Pfad sind, rehct ein "avr-gcc" auf Kommandozeile, um den neuen compiler aufzurufen, z.B. mit --version um zu sehen, welche Version es ist. Und falls du das alte WinAVR brauchst für Legacy-Projekte oder um erzeugten Code zu vergleichen, einfach mit absoluten Pfad aufrufen und fertig.
Johann L. schrieb: > Nope. Danke Johann ! wo ist denn ein neues aktuelles WinAVR zu finden, so daß meine alten Makefiles ohne Probleme laufen. Eine IDE/Studio brauche/will ich nicht.
Johann L. schrieb: > Weil die Tools mi Pfad sind, rehct ein "avr-gcc" auf Kommandozeile, um > den neuen compiler aufzurufen, danke für den Hinweis Johann. Du hast wohl verschiedene Umgebungen auf dem PC parallel in Nutzung.
Oliver S. schrieb: > Eine wirklich aktuellen avr-gcc mit make gibt es hier: > http://blog.zakkemble.net/avr-gcc-builds/ Danke Oliver für den Hinweis !
Oliver S. schrieb: > Eine wirklich aktuellen avr-gcc mit make gibt es hier: > http://blog.zakkemble.net/avr-gcc-builds/ hier gibt es 2 Pakete zum Download: avr-gcc-9.1.0-x64-mingw.zip (56.48 MB) AVG-GCC 9.1.0 Windows x64 (64 bit) Downloaded 728 times avr-gcc-9.1.0-x86-mingw.zip (54.28 MB) AVG-GCC 9.1.0 Windows x86 (32 bit) Downloaded 226 times Gibt es einen Grund das erste - das offenbar häufiger heruntergeladen wird - nicht zu nehmen wenn man Win7 64bit hat?
Johann L. schrieb:
> Nope.
ist aus Deiner Sicht avr-gcc-9.1.0-x64-mingw.zip (56.48 MB) ein
vollwertiger Ersatz?
Matthias W. schrieb: > Du hast wohl verschiedene Umgebungen auf dem PC parallel in Nutzung. "Umgebungen" nicht, aber AVR-Toolchains (GCC) ca. 20 Stück. Das make ist noch aus WinAVR-20100110 und tut seine Dienste, ich setze die Tools aber auch nicht beruflich ein. Die Tools sind WinAVR, von Atmel, MHV und die meisten selbstgeneriert unter Linux. https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20(Win32)/ Das sind einfach nur die Tools (GCC, Binutils, AVR-Libc) generiert für MinGW32 und als ZIP. Zur "Installation" einfach auspacken und umbenennen falls der Pfadname nicht passt. Generiert wurde das aus den GNU / AVR-LibC Quellen, i.d.R ohne spezielle Patches. Jedenfalls ohne extra Patches von Atmel / Microchip.
Johann L. schrieb: > Zur "Installation" einfach auspacken und > umbenennen falls der Pfadname nicht passt. Generiert wurde das aus den > GNU / AVR-LibC Quellen, i.d.R ohne spezielle Patches. Danke Johann !
Kann mir jemand sagen wie ich mit Atmel Studio 7 die Ausgabe der Codegröße in % hinbekomme? Es steht bei mir alles auf 0%. Irgendwie muss die avr-size dort mit eingebunden werden oder?
Vergessen: unter Verwendung der avr-gcc-9.1.0-x64-mingw, mit den offiziellen Atmel Toolchains gibts da keine Probleme.
Ingo Less schrieb: > unter Verwendung der avr-gcc-9.1.0-x64-mingw, mit den > offiziellen Atmel Toolchains gibts da keine Probleme. Danke Ingo !
Ingo Less schrieb: > unter Verwendung der avr-gcc-9.1.0-x64-mingw, mit den offiziellen Atmel > Toolchains gibts da keine Probleme Kapier deine Kombination nicht. Du hast die Atmel Toolchain installiert und dazu die gcc-9.1.0-x64 und nutzt diese von der Atmel Installation aus? Oder wie genau?
Matthias W. schrieb: > ist aus Deiner Sicht avr-gcc-9.1.0-x64-mingw.zip (56.48 MB) ein > vollwertiger Ersatz? Kommt frauf an was für dich vollwertig ist. WinAVR war ja mehr als ne reine Toolchain: make, Mfile, Simulator, Insight/TCL, avrdude, grep, sed, awk, ... Mit v9 hab ich keine Erfahrung, es wird aber berichtet über Zunahme an Größe von generiertem Code bzgl. v8. Keine Ahnung wie gravierand das ist; Codegröße schwankt immer mal wieder mit der Version. Wenn du nicht den letzten Schrei an C++20 Features braucht bist mit v8 vielleicht besser bedient. Ingo Less schrieb: > Mit den AVR Toolchains läuft avr-size, mit dem 9.1 nicht Einige Distributionen kommen mit einem gepatchten avr-size, das die Speichergrößen von verschiedenen Derivaten hinzufügt zwecks Anzeige von Resourcenverbrauch. In die offizielle Release / Codebase hat's dieses Patch aber nie geschafft.
:
Bearbeitet durch User
Johann L. schrieb: > Kommt frauf an was für dich vollwertig ist. WinAVR war ja mehr als ne > reine Toolchain: make, Mfile, Simulator, Insight/TCL, avrdude, grep, > sed, awk, ... Nun ja, make und avrdude lassen sich einfach besorgen (bzw. sind in den Paketen von zak mit dabei), und der Simulator steckt im avr-gdb (den man sich leider wegen des nach wie vor ungefixten Flash-Diassemble-Bugs eh selber bauen muß). Wobei, wenn man einen Simulator braucht, nimmt man eh besser das Studio. Den ganzen Rest braucht ein "handelsüblicher" Windowsuser sowieso nicht ;) Oliver
Oliver S. schrieb: > Dazu ein aktuelles MFile zum Erstellen von makefiles kannst Du dazu einen Link angeben? ich habe das Mfile das bei WINAVR2010 beigepackt war. im Ordner mfile von WINAVR liegt mfile.tcl, mfile.xbm und makefile_template. In help.html steht jedoch nicht wie man das zum Laufen bekommt. einfach aufrufen von mfile.tcl klappt nicht. Einen Pfad auf das Verzeichnis mfile habe ich gesetzt. Außerdem liegen im bin-Verzeichnis Dateien wie wish84.exe, tclsh84.exe, itcl32.dll, itk32.dll usw. es sollte doch kein Hexenwerk sein das in Betrieb zu bekommen?
Johann L. schrieb: > Kommt frauf an was für dich vollwertig ist. vollwertig ist für mich vergleichbarer Funktionsumfang. > WinAVR war ja mehr als ne > reine Toolchain: make, Mfile, Simulator, Insight/TCL, avrdude, grep, > sed, awk, ... ja. Deswegen sah ich mich genötigt selbst etwas funktionsähnliches zusammenzubauen. Es mag ja sein daß es geschickter gegangen wäre. Wenn jemand dazu Hinweise hat - gerne. > Mit v9 hab ich keine Erfahrung, es wird aber berichtet über Zunahme an > Größe von generiertem Code bzgl. v8. mein Test ergab für ein LED-Blink-Beispiel data+text 1886 bytes mit AVR-GCC8.2.0 64bit im Vergleich zu 1940 bytes für AVR-GCC9.1.0 32bit. WINAVR2010 sind 1720 bytes. Der totale Speicher (incl. Debug-Infos) wuchs bei allen neueren Versionen gegenüber WINAVR2010 stark an. Bei GCC4.3.3 waren es 10657 bytes, GCC8.2.0 64bit 21833 bytes und GCC9.1.0 32bit 22264 bytes. bei einem deutlich größeren Programm für Atmega2560: totaler Speicher incl. Debug-Informationen: GCC4.3.3 39231 bytes, GCC8.2.0 64bit 72040 bytes, GCC9.1.0 32bit 72689 bytes. data+text waren bei WINAVR2010 (GCC4.3.3) 446+8458 bytes, GCC8.2.0 64bit 428+7944 bytes, GCC9.1.0 32bit 428+8230 bytes.
Oliver S. schrieb: > Den ganzen Rest braucht ein "handelsüblicher" Windowsuser sowieso nicht nur funktioniert das alte Makefile dann eben nicht ! wenn es so einfach gewesen wäre hätte ich nicht angefangen zu suchen und etwas zusammenzubauen.
Matthias W. schrieb: > nur funktioniert das alte Makefile dann eben nicht ! > wenn es so einfach gewesen wäre hätte ich nicht angefangen zu suchen und > etwas zusammenzubauen. Ach ja, das Steinzeit-Makefile von WimAVR nutzt tatsächlich ein sed. Geht seit ungefähr 100000 IT-Jahren aber auch ohne. Matthias W. schrieb: > kannst Du dazu einen Link angeben? > ich habe das Mfile das bei WINAVR2010 beigepackt war. https://www.mikrocontroller.net/articles/Mfile Oliver
Oliver S. schrieb: > Geht seit ungefähr 100000 IT-Jahren aber auch ohne. mein Makefile geht nicht ohne. Keine Ahnung wem es noch so geht.
Oliver S. schrieb: > Matthias W. schrieb: >> kannst Du dazu einen Link angeben? >> ich habe das Mfile das bei WINAVR2010 beigepackt war. > https://www.mikrocontroller.net/articles/Mfile Danke Oliver, leider bringt mich das nicht weiter. http://www.sax.de/~joerg/mfile/ hatte ich angesehen. im zip-File ist genau das was ich auch in WINAVR2010 vorfand. auch das Readme http://www.sax.de/~joerg/mfile/README.txt half mir bisher nicht. vermutlich fehlt eine Verknüpfung? ein tcl/tk-Aufruf-Thema?
ohje, das ist alles schon so lange her... Ok, mfile braucht tcl, und davon eine uralte Version. Da wirst du das aus der WinAVR-Umgebung weiterverwenden müssen. Es wäre vielleicht mal an der Zeit, einen Schnitt zu machen, und auf eine aktuellere Entwicklungsumgebung umzusteigen. Ein schnitt ist eh eforderlich, da die aktuelleren gccs bei deinen alten WinAVR-Projekten bei nicht-const progmem meckern, und du eh an den sourcen Änderungen vornehmen musst. Ich nutze set ewigen Zeiten Eclipse mit dem avr-plugin, aber das ist Geschmackssache. Oliver
Oliver S. schrieb: > ohje, das ist alles schon so lange her... ja. > Ok, mfile braucht tcl, und davon eine uralte Version. Da wirst du das > aus der WinAVR-Umgebung weiterverwenden müssen. ich habe kein Problem das zu nehmen was da ist, nur leider lässt mich die Doku dazu wie ich das in Gang bringe bisher im Stich. Du schriebst: "Dazu ein aktuelles MFile zum Erstellen von makefiles..." - und so dachte ich - frag halt mal . . . Kürzlich bin ich beim Versuch ein Makefile zu ändern verzweifelt. Es gab immer wieder Fehler. Vielleicht hätte mir mfile da geholfen - keine Ahnung. Hat das denn gar niemand mehr in Betrieb? > Es wäre vielleicht mal an der Zeit, einen Schnitt zu machen, und auf > eine aktuellere Entwicklungsumgebung umzusteigen. darüber habe ich länger nachgedacht bevor ich das obige versuchte. das Studio war mir zu sperrig. Manchmal war der Code zu groß, passte nicht in den Butterfly. am besten kam ich mit WinAVR klar. Das lief stets rasch und unkompliziert. Daher möchte ich dabei bleiben. > Ein schnitt ist eh > eforderlich, da die aktuelleren gccs bei deinen alten WinAVR-Projekten > bei nicht-const progmem meckern, und du eh an den sourcen Änderungen > vornehmen musst. die bisher probierten GCCs haben meinen C-Code anstandslos geschluckt. > Ich nutze set ewigen Zeiten Eclipse mit dem avr-plugin, aber das ist > Geschmackssache. ja. Ich war mit Eclipse nicht so froh. Der Umgang damit war für mich zäher als WinAVR. Mein Rechner ist älter/langsamer. Oft sind mehrere Fenster auf. Da brauche ich Anwendungen die nicht viel Speicher fressen.
Matthias W. schrieb: > Du schriebst: "Dazu ein aktuelles MFile zum Erstellen von makefiles..." > - und so dachte ich - frag halt mal . . . Ich dachte, da gäbs was neueres. Scheint aber nicht so zu sein. Schau dir halt an, wie mfile im WinAVR-Paket aufgerufen wird (das muss ein batch-Datei oder sowas sein). Ansonsten sind die makefiles jetzt aber nicht so kompliziert, als daß du nicht einfach eins von einem existierenden Projekt kopieren und da drin die sourcen und eventuell den Prozessor von Hand ändern könntest. Oder du nimmst halt das hier als Vorlage: https://www.mikrocontroller.net/articles/Beispiel_Makefile Oliver
Oliver S. schrieb: > Ich dachte, da gäbs was neueres. Scheint aber nicht so zu sein. ja. Leider. > Schau dir halt an, wie mfile im WinAVR-Paket aufgerufen wird (das muss > ein batch-Datei oder sowas sein). WinAVR basiert vor allem auf der Funktionalität des Makefiles und der Tools die damit aufgerufen werden. mfile wird nicht mittels des Makefile-Template aufgerufen. Da kann ich nichts abschauen. > Ansonsten sind die makefiles jetzt aber nicht so kompliziert, als daß du > nicht einfach eins von einem existierenden Projekt kopieren und da drin > die sourcen und eventuell den Prozessor von Hand ändern könntest. so hatte ich das bisher gemacht. Als ich bei einem Projekt dann C++ files statt der C-Files bisher verwenden wollte bin ich krachend gescheitert. auch das Lesen der ersten 22 Seiten der Make-Beschreibung (danach hatte ich keine Lust mehr) und das Ansehen diverser youtube Tutorials brachte nicht wirklich weiter. mit der Arduino-IDE läuft das Projekt. Nur verwendet Arduino kein Make.exe mehr. Der Output ist so lang und kryptisch daß ich da erst mal Abstand genommen habe das weiter zu verfolgen. > Oder du nimmst halt das hier als Vorlage: > https://www.mikrocontroller.net/articles/Beispiel_Makefile Danke Oliver. So etwas ähnliches nutze ich ja. Bei den C-Files hat das bisher immer geklappt.
Matthias W. schrieb: > mfile wird nicht mittels des Makefile-Template aufgerufen. Da kann ich > nichts abschauen. Vergiss das einfach. mfile ist der Generator für makefiles, aber wenn du das noch nie benutzt hast, ist das jetzt auch egal. Im Netz finden sich auch makefile-beispiele für C++-Projekte. Oliver
Oliver S. schrieb: > makefile-beispiele für C++-Projekte. danach hatte ich eine ganze Weile gesucht. Nur ist eben wohl nur ganz selten etwas für AVR GCC passend dabei. frustriert schmiss ich dann die Dateien in den Arduino und der hat es anstandslos geschluckt und fehlerfrei übersetzt.
Angehängte Dateien:
-
AVRStudio4.19.png
480 KB
Wenn es einfach sein soll und kompakt so geht das auch mit ********************************************************** AVRStudio 4.19 avr-gcc-9.1.0-x64-mingw\bin\avr-g++.exe avr-gcc-9.1.0-x64-mingw\bin\make.exe mit -std_c++2a -fconcepts Das generierte Makefile als Beispiel angeheftet... -------------------------------------------------------- (Sinngemäss und moderner auch mit AtmelStudio 6.2 und 7)
nun soll ein ATmega4809 mit WinAVR genutzt werden. Erst mal soll eine LED blinken. das selbst zusammengebastelte WINAVR auf Basis avr8-gnu-toolchain-3.6.2.1759-win32.any.x86.zip liefert den Fehler: avr-gcc.exe: error: device-specs/specs-atmega4809: No such file or directory. es fehlt etwas. Wie kann ich das brauchbar hinzufügen? es gibt das MegaCoreX-master.zip Paket, das die Arduino-Umgebung befähigt. Nur wie kann man das brauchbar in WINAVR integrieren? wer kann/will dazu etwas sagen? Gruss Matthias
:
Bearbeitet durch User
Die Dateien sind im aktuellen Device Support Package enthalten Atmel.ATmega_DFP.1.4.351.atpack http://packs.download.atmel.com Veit D. hat eine Grafik erstellt, die genau zeigt wo die Dateien in die Toolchain eingepflegt werden. Beitrag "Re: cannot read spec file 'device-specs/specs-atmega4808'"
Hallo, ich habe mir erlaubt hier ein Update für alles zu liefern. :-) Beitrag "Re: Toochain bauen avr-gcc-x.x mit binutils-2.34 funktioniert nicht"
A. B. schrieb: > Atmel.ATmega_DFP.1.4.351.atpack http://packs.download.atmel.com > Veit D. hat eine Grafik erstellt, vielen Dank an Euch beide. Ich werde es versuchen !
Ich habe ganz einfach das Atmel Studio 7 installiert, da ist alles dabei. Dann in den Userpfad von W10 die Verzeichnisse von AVR-GCC und Make eintragen, fertig. Die Pfade kriegt man raus, indem man nach avr-gcc.exe und make.exe sucht. Ich hab mir auch eine Batch geschrieben, die aus allen *.c im aktuellen Verzeichnis ein make erzeugt.
Hallo, was meinst du mit "Userpfad" genau? C:\Users\Name\... ? Ich kopiere entweder kleine DOS Tools u.ä. nach C:\Windows\ damit sie global gefunden werden oder ich mach einen Pfadeintrag in die Systemumgebungsvariablen.
Matthias W. schrieb: > vielen Dank an Euch beide. Ich werde es versuchen ! auf Basis des erstellten WinAVR mit der 9.1.0 habe ich den Atmega4809 entsprechend Veits Hinweisen hinzugefügt. Das main.c definiert die Pins, so wie ich es bei den anderen AVRs stets gemacht hatte. An Port PF5 hängt die LED die blinken soll.
1 | // DDRF Pins teilweise auf Eingabe: kein PF7
|
2 | DDRF = (0<<DDF6) | (1<<DDF5) | (0<<DDF4) | (0<<DDF3) | (0<<DDF2) | (0<<DDF1) | (0<<DDF0); |
3 | // PORTF pullup enable fuer Eingänge: kein PF7
|
4 | PORTF = (1<<PF6) | (0<<PF5) | (1<<PF4) | (1<<PF3) | (1<<PF2) | (1<<PF1) | (1<<PF0); |
mit diesen Zeilen in einer Schleife sollte die LED blinken:
1 | sbi(PORTF,5); // LED ein - LED gg. GND |
2 | delay_ms(1000); // warte |
3 | cbi(PORTF,5); // LED aus |
4 | delay_ms(1000); // warte |
Der Compiler findet das chip nun - bemängelt jedoch die bisher üblichen Hinweise auf die Portpins: error: PC7 undeclared error: PC6 undeclared error: DDRD undeclared error: DDD7 undeclared usw. wenn man iom4809.h mit iom328p.h vergleicht sieht man dass das alles ganz anders aufgebaut ist. So einfach übernehmen kann man altes da nicht.
A. B. schrieb: > Veit D. hat eine Grafik erstellt, die genau zeigt wo die Dateien in die > Toolchain eingepflegt werden danke Veit ! das hat mir beim Hinzufügen des Atmega4809 in die 9.1.0 sehr geholfen. nur gibt es ein Problem beim alten WINAVR2010. Die Datei specs-atmega4809 aus gcc/dev/atmega4809/device-specs sollte nach lib/gcc/avr/9.1.0/device-specs kopiert werden. Das alte Paket hat einen Ordner lib/gcc/avr/4.33. Darunter ist jedoch kein Ordner device_specs. Es gibt Ordner wie avr3, avr4,... avrxmega2, avrxmega3, avrxmega5,... es ist unklar wo specs-atmega4809 nun hin soll? die anderen Änderungen scheinen machbar.
:
Bearbeitet durch User
Matthias W. schrieb: *************************************** > wenn man iom4809.h mit iom328p.h vergleicht sieht man dass das alles > ganz anders aufgebaut ist. So einfach übernehmen kann man altes da > nicht. Das ist korrekt. ATmega-Series0 ist eine neue Generation AVR-uC. *************************************************************** Das datasheet und viele application-notes gibt es hier: https://www.microchip.com/wwwproducts/en/ATMEGA4809 Ein einfaches uart-Beispiel gibt es hier: https://www.avrfreaks.net/forum/cant-get-uart-comm-going-nano-curiosity-w-mega4809 Matthias W. schrieb: *************************************** > nur gibt es ein Problem beim alten WINAVR2010. Du hast doch avr-gcc-9.1.0 und mit den beschriebenen Modifikationen ist das eine taugliche Toolchain für ATmega4809. Vergiss den WinAvr von 2010. Falls Du Probleme mit Makefiles hast: AtmelStudio generiert die Makefiles automatisch und kann die neueste verfügbare AVR-GCC-Toolchain verwenden. Falls du eine einfachere IDE bevorzugst: Auch AVRStudio 4.19 generiert die Makefiles automatisch und kann die neueste verfügbare AVR-GCC-Toolchain verwenden. Beitrag "Re: Update von WinAVR2010" Sowohl im AtmelStudio als auch in der Windows-Version der AVR-GCC-Toolchain von https://blog.zakkemble.net/avr-gcc-builds/ ist ein MAKE enthalten
A. B. schrieb: > Das datasheet und viele application-notes gibt es hier: > https://www.microchip.com/wwwproducts/en/ATMEGA4809 > Ein einfaches uart-Beispiel gibt es hier: > https://www.avrfreaks.net/forum/cant-get-uart-comm-going-nano-curiosity-w-mega4809 vielen Dank für diese beiden wertvollen Links ! das schau ich an.
A. B. schrieb: > Vergiss den WinAvr von 2010. WinAVR 2010 ist alt - ich weiß. Daher habe ich mehrere WINAVR parallel aufgebaut. Der alte WinAVR liefert bisher den kleinsten Code, daher möchte ich das ggf. nutzen können - neben avr-gcc-9.1.0 und anderen.
Matthias W. schrieb: > Die Datei specs-atmega4809 aus gcc/dev/atmega4809/device-specs sollte > nach lib/gcc/avr/9.1.0/device-specs kopiert werden. Das alte Paket hat > einen Ordner lib/gcc/avr/4.33. Darunter ist jedoch kein Ordner > device_specs. Es gibt Ordner wie avr3, avr4,... avrxmega2, avrxmega3, > avrxmega5,... Also, eine alte 4.x Toolchain habe ich nicht, baue ich mir auch nicht. Ich kann dir "nur" sagen wie du die fehlenden Dateien einer frischen Toolchain hinzufügst, aus dem Devicepack. Bspw.:
1 | Datei: iom4809.h |
2 | von: .\Atmel.ATmega_DFP.1.4.351.atpack\include\avr\ |
3 | nach: .\avr-gcc-9.3.0\avr\include\avr\ |
4 | |
5 | Dateien: crt*.o und lib*.a |
6 | von: .\Atmel.ATmega_DFP.1.4.351.atpack\gcc\dev\atmega4809\avrxmega3\ |
7 | nach: .\avr-gcc-9.3.0\avr\lib\avrxmega3\ |
8 | |
9 | Datei: specs-atmega4809 |
10 | von: .\Atmel.ATmega_DFP.1.4.351.atpack\gcc\dev\atmega4809\device-specs\ |
11 | nach: .\avr-gcc-9.3.0\lib\gcc\avr\9.3.0\device-specs\ |
Falls es mit dem spec File Probleme gibt, ich hatte damals ein Problem damit, kannste noch das von Johann probieren. Beitrag "Re: cannot read spec file 'device-specs/specs-atmega4808'" Mehr kann ich dazu nicht mehr sagen. Dann sollte dann funktionieren. Ich könnte dir höchstens noch eine avr-gcc 7.5 Toolchain anbieten mit allen drin. Und wegen kleinsten Code. Sollte ja nun beim 4809 kein Thema sein, auch wenn es ein paar Byte hier und da mehr werden. :-)
:
Bearbeitet durch User
Veit D. schrieb: > Ich kann dir "nur" sagen wie du die fehlenden Dateien einer frischen > Toolchain hinzufügst, aus dem Devicepack. Bspw.: vielen Dank Veit, so habe ich das ja auch gemacht. Nur gibt es beim WINAVR 2010 den Ordner device-specs\ nicht. Daher weiß ich nicht wohin ich diese Datei kopieren soll. wenn es nicht geht mit dem 4.3.3. dann geht es eben nicht.
Veit D. schrieb: > ich mach einen Pfadeintrag in die > Systemumgebungsvariablen. Die sind in der Regel grau, d.h. vom Benutzer nicht änderbar. Mit Userpfad meine ich den "Path" unter Benutzervariablen. Mist, ich sehe gerade, die Einstellung ist seit irgendeinem Update nicht mehr direkt verfügbar. Man muß erst in der Suche nach "Umgebungsvariablen" suchen. Was soll der Quatsch?
Veit D. schrieb: > Ich könnte dir höchstens noch eine avr-gcc 7.5 Toolchain anbieten. ich kann es probieren. Hast Du einen Link dazu? ich kann das auch zusammenbauen wie die anderen davor wenn es ein zip gibt für Download.
Hallo, frisch montiert, weil ich weg muss leider ungetestet. Versuche mal dein Glück. https://www.dropbox.com/sh/bhz67ip1k3wj3eq/AAAb9WQ33hhNIqru2FRnWc8Ra?dl=0 (lösche ich wieder)
Hallo, habe die 7.5 jetzt getestet, funktioniert leider nicht. :-( Ich kann machen was ich will, ich erhalte immer: unknown core architecture 'avrxmega3' specified with '-mmcu=' Da bin ich ehrlich gesagt überfragt wie man der die xmega3 Architektur beibringt das sie da ist. Den Ordner gabs hier übrigens nicht. Habe ich selbst eingefügt. Das macht mich jetzt auch etwas stutzig. Als letzten Ausweg kann ich dir meine wirklich funktionierende 9.3.0 Toolchain geben. Mit der programmiere ich schon länger auch mit ATmega4809. Habe ich mit in den Download Ordner kopiert. Mit älteren Toolchains wie 9.1 hatte ich mit den neuen ATmegas bis jetzt auch noch nichts probiert. Ich dachte nicht das es da Probleme gibt. Entschuldigung. Edit: Ich glaube es macht wohl nun doch einen großen Unterschied ob man "nur" fehlende Devices hinzufügt wenn die Architektur der Toolchain schon bekannt ist oder sie diese generell noch nicht kennt. Ich denke bei Letzterem muss man beim Toolchain bauen andere Optionen bzw. größere Änderungen vornehmen. Sagt mir jetzt so mein Bauchgefühl. Ich hoffe du bist mit der 9.3 glücklich. Ansonsten kann ich dir noch die "Rohvariante" einer avr-gcc 8.4.0 Toolchain geben. Die hat den Stand "frisch kompiliert". Also da sind noch keine fehlenden Dateien hinzugefügt. Es existieren aber die Ordner 'avrxmega3', was hoffen läßt das es damit funktioniert, falls du ein paar Byte Codegröße einsparen möchtest. Ich kopiere die mit in den Downloadordner. Die fehlenden Dateien kannste bestimmt selbst einsortieren. Das sollte wirklich nach der weiter oben beschriebenen Methode funktionieren.
:
Bearbeitet durch User
Veit D. schrieb: > habe die 7.5 jetzt getestet, funktioniert leider nicht. schade. Hast Du einen Link zur Rohversion? dann kann ich das auch mal versuchen.
Veit D. schrieb: > Mit älteren Toolchains wie 9.1 hatte ich mit den neuen ATmegas bis jetzt > auch noch nichts probiert. die 9.1.0 geht bei mir. Die machte halt den größten Code.
Hallo, dann wirst du Toolchainbauer. https://gcc.gnu.org/ Dort findest du dann auch alle älteren gcc Versionen. Viel Spass beim bauen. Was ich noch in einem Forum gefunden habe ist folgender Hinweis. In order to add the architecture, three things need to be updated, gcc - gcc\config\avr\avr.c, gcc\config\avr\avr.h, gcc\config\avr\t-avr, Binutils - gas\tc-avr.c avr-libc - avr\io.h, configure, configure.in, And Header file changes.
Veit D. schrieb: > Hallo, > > dann wirst du Toolchainbauer. > https://gcc.gnu.org/ > Dort findest du dann auch alle älteren gcc Versionen. > Viel Spass beim bauen. > > Was ich noch in einem Forum gefunden habe ist folgender Hinweis. > > In order to add the architecture, three things need to be updated, > gcc - gcc\config\avr\avr.c, gcc\config\avr\avr.h, gcc\config\avr\t-avr, > Binutils - gas\tc-avr.c > avr-libc - avr\io.h, configure, configure.in, And Header file changes. Für das Bauen der avr-Toolchain (suche:avr-gcc from Source) gibt es gute Anleitung mit für alle Teile. Die hab ich in ein scipt verpackt und muß eigentlich nur noch die gewünschte Version(en) angeben, dann holt das Ding alles nötige aus dem Web und spuckt hinten die Toolchain raus. Nach gebührender Wartezeit. Das einzige Problem ist das Win in WinAVR. Seit ich das abgelegt hab, brauch ich keine fremde Hilfe mehr für neue Versionen.
Hallo, kannst du auch älteren gcc Versionen neuere Architekturen beibringen?
Veit D. schrieb: > Hallo, > > kannst du auch älteren gcc Versionen neuere Architekturen beibringen? Das wäre ein "Down-Port" und das einzige was ich mache ist ein "Download". Nein, dazu müßte man an der GCC-Source rumfummeln, zumindest wenn es sich um neue Varianten handelt, die die Code-Generierung beeinflussen. Einfach ein neuer Typ mit mehr Speicher/zusätzlichen Io-Registern würde eventuell mit AVRLibc Änderungen auskommen, die aber WIMRE von Jörg W. regelmäßig in AVRLibc Trunk ergänzt werden. Bisher verwende ich aber nur die latest Release, die aber schon Jährchen auf dem Buckel hat. Bin aber μC-mäßig nur Bastler, der nicht jedem neuen Chip hinterherhechelt.
:
Bearbeitet durch User
Hallo, Schade, denn das wäre das was Matthias machen müßte, einen Down-Port wie du das nennst.
Angehängte Dateien:
-
atmega4809_gcc.png
7,3 KB
das Beispiel LED-Blinken liefert mit der 9.1.0 nun keine Compilerfehler mehr, dafür meckert der Linker - siehe Bild. Dabei sollte der AVR-Kern doch derselbe sein? vielleicht hat jemand einen Hinweis wie das gelöst werden kann?
Matthias W. schrieb: > Nur gibt es beim WINAVR 2010 den Ordner device-specs\ nicht. Korrekt. Spec Files wurden mitr v5 eingeführt; WinAVR von 2010 ist v4.3 also 7 Releases davor. Veit D. schrieb: > habe die 7.5 jetzt getestet, funktioniert leider nicht. :-( Ich kann > machen was ich will, ich erhalte immer: > unknown core architecture 'avrxmega3' specified with '-mmcu=' avrxmega3 hab ich in v8 eingebaut. Dass muss(te) im Compiler selbst gemacht werden, per Spec-File geht das nicht. Du kannst aber deine Spec-Files auf avrxmega2 umschreiben — sollte funktionieren allerdings nicht so performant wie mit v8+. > Ich glaube es macht wohl nun doch einen großen Unterschied ob man "nur" > fehlende Devices hinzufügt wenn die Architektur der Toolchain schon > bekannt ist oder sie diese generell noch nicht kennt. Ich denke bei > Letzterem muss man beim Toolchain bauen andere Optionen bzw. größere > Änderungen vornehmen. Sagt mir jetzt so mein Bauchgefühl. +1 für männliche Intuition. > Ich hoffe du bist mit der 9.3 glücklich. Ansonsten kann ich dir noch die > "Rohvariante" einer avr-gcc 8.4.0 Toolchain geben. Die hat den Stand > "frisch kompiliert". Also da sind noch keine fehlenden Dateien > hinzugefügt. Wenn man avrxmage3 will, also 0-Series wie ATmega4808, bekommt man den besten Code mit v8. Neurer Versionen machen schlechteren Code, siehe PR90706. Toolchains mit 0-Series Support sind da: https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20(Win32)/ Alternativ Toolchains von µchip, da ich die nicht verwende kann ich aber nix zu der benötiogten (Mindest-)Version sagen. > Es existieren aber die Ordner 'avrxmega3', Ab v10 gibt es auch -nodevicespecs was Hinzufügen neuer Spec-Files vereinfacht: http://gcc.gnu.org/gcc-10/changes.html#avr http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html#index-nodevicespecs
Johann L. schrieb: > avrxmega3 hab ich in v8 eingebaut. Dass muss(te) im Compiler selbst > gemacht werden, per Spec-File geht das nicht. ok. Könnte ich so etwas nutzen? > Wenn man avrxmega3 will, also 0-Series wie ATmega4808, bekommt man den > besten Code mit v8. Neurer Versionen machen schlechteren Code, siehe > PR90706. Danke für den Hinweis Johann ! > Toolchains mit 0-Series Support sind da ok. Ich schau mal.
Veit D. schrieb: > dann wirst du Toolchainbauer. > https://gcc.gnu.org/ > Dort findest du dann auch alle älteren gcc Versionen. das wollte ich eher nicht werden. Mein Ziel ist es etwas einfach benutzbares brauchbares zu haben das sicher und performant läuft und effizienten Code liefert. dafür bin ich auch bereit mal einer brauchbaren Anleitung zu folgen wie man so eine Version zusammenbaut.
Hallo, @ Johann: Danke für die Antwort, erklärt vieles ... :-) @ Matthias: War so frei und habe dir die aktuelle 8.4er fertig gemacht. Ist in Atmel Studio 7 mit ATmega4809 getestet. Funktioniert. https://www.dropbox.com/sh/tsz1w39xkkzpu4q/AAAgwXS1DYdR2RKB0ZFM_hV9a?dl=0 Brauchbare Anleitungen hattest du übrigens bekommen, sogar mit einfachen .bat Datei doppelklicken. Darüber musste dich jetzt nicht beschweren.
Veit D. schrieb: > Darüber musste dich jetzt nicht beschweren. ich beschwer mich ja gar nicht ! Danke Veit !
Veit D. schrieb: > War so frei und habe dir die aktuelle 8.4er fertig gemacht. Ist in Atmel > Studio 7 mit ATmega4809 getestet. Funktioniert. vielen Dank Veit. Ich probier es aus.
Peter D. schrieb: > Ich hab mir auch eine Batch geschrieben, die aus allen *.c im aktuellen > Verzeichnis ein make erzeugt. Danke Peter für den Hinweis. Kannst/willst Du das hier posten?
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.