Moin Moin, Ich möchte für ein Projekt ein ATmega4808 einsetzten. In der aktuellen gcc toolchain von Microchip wird der ATmega4808 / oder 4809 nicht unterstützt. Gibt es eine Möglichkeit die lib´s und includes und alledem upzudaten? Aktuelle Version ist: avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.2_1759) 5.4.0 Avrdude ist dann die nächste Hürde... Gruß Karsten
Karsten K. schrieb: > Gibt es eine Möglichkeit die lib´s und includes und alledem upzudaten? Mit Sicherheit: ja. Wenn du mehr zu deiner Umgebung Preis gibst, könnte man dazu passende Hilfe leisten.
War da nicht etwas mit den Packs? Atmel ATmega Series Device Support (1.3.300) aus: http://packs.download.atmel.com/ Zumindest sind die beiden libs da drin.
atpack ist eine normale zip Datei. Da sind alle Header und libs drin. Ein kopieren in die entsprechenden Verzeichnisse des gcc sollte genügen.
Moin @Stefanus: Was soll ich mehr schreiben als die Versionsnummer des avr-gcc und das diese Version die aktuelle vom Microchip ist. Ansonsten erzeuge ich den code mit vi, nutze make und avrdude was aber für meine Frage keine Relevanz hat. @pegel: Danke für den Hinweis mit dem pack für ATmega. gruß Karsten
Karsten K. schrieb: > Was soll ich mehr schreiben als die Versionsnummer des avr-gcc und das > diese Version die aktuelle vom Microchip ist. Unter Linux verwenden viele Menschen zum Beispiel den avg-gcc, der in der Distribution drin ist. Die Toolchain von Atmel bekommst du dort: https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers Der Atmega4808 ist darin allerdings nicht gelistet - komisch. Hier ist eine alternative Quelle für Windows: http://gnutoolchains.com/avr/ offensichtlich älter. Vielleicht musst du tatsächlich so ein Zusatzpack von http://packs.download.atmel.com/ installieren.
Gerade mit Google gefunden: Version 9.2.0 https://blog.zakkemble.net/avr-gcc-builds/ Ich finde die Versionsnummer seltsam.
Hallo, warum soll die Versionsnummer seltsam sein? Das ist die aktuelle gcc Version 9.2.0. https://gcc.gnu.org Falls im 9.2er Zak Paket unerwartet die Unterstützung für die neue ATmega Serie fehlen sollte, habe ich nicht geprüft, dann die Dateien aus dem aktuellen DevicePack (http://packs.download.atmel.com/) entnehmen und einsortieren. Dazu kann man dann gleich noch von Johann die aktualisierten spec Dateien verwenden wenn man schon dabei ist. Ziemlich am Ende von dem Thread. Beitrag "Re: cannot read spec file 'device-specs/specs-atmega4808'" Ich würde aber erstmal an deiner Stelle das Zak Paket so probieren wie es ist. Ich denke das läuft mit dem ATmega4808. Wenn alle Stränge reißen lade ich die mit Johann gebaute Toolchain von mir hoch. Also das was mit dem Thread entstanden ist. Da weiß ich das die läuft. Ganz grob nochmal. Die gcc Version muss halbwegs aktuell sein. Ab 7.3 geht das mit der neuen ATmega Serie laut meinem Wissens. Ganz wichtig sind die Dateien aus dem aktuellen DevicePack. Für avrdude brauchst du nur eine angepaßte .conf Datei. Die habe ich entweder hier aus dem Forum oder bei avrfreaks entdeckt. Habe ich auch mit einem ATmega4808 getestet, funktioniert.
MaWin schrieb: > MC wird den AVR austrocknen lassen. Also reitet kein totes Pferd! Ne, sonst hätten die keine neue ATmega und ATtiny Serie rausgebracht. ------------------------------------------------ Hallo nochmal, habe mir das Zak Paket jetzt doch noch angeschaut. Leider fehlt in diesem die Unterstützung für die neue ATmega und ATtiny Serie. Ich stelle deshalb mein Paket für eine Weile zur Verfügung. Irgendwann lösche ich das wieder. https://www.dropbox.com/s/ln92akonhfr37xj/avr-gcc-9.2.0-mingw64-selfmade.zip?dl=0 Das Einzigste was ich umbenannt habe ist die avr-size.exe in .org. Ich verwende eine alte Version davon damit mir Atmel Studio 7 die Flash/Ram Größe anzeigt. Falls jemand dafür eine bessere Lösung hat - bin ganz Ohr.
Veit D. schrieb: > neue ATmega und ATtiny Serie rausgebracht. Da fehlte ja nur noch der Stempel. Ne, die AVR laufen aus. Wirst 's sehen.
Veit D. schrieb: > warum soll die Versionsnummer (9.2) seltsam sein? Weil die Pakete von Atmel/Microchip sowie die gängigen Linux Distributionen noch bei Version 5.4.0 sind.
Veit D. schrieb: >> MC wird den AVR austrocknen lassen. Also reitet kein totes Pferd! > Ne, sonst hätten die keine neue ATmega und ATtiny Serie rausgebracht. Möglicherweise wurden diese neuen Serien noch von Atmel ausgearbeitet, und jetzt produziert man sie damit die Arbeit nicht für die Katz war und damit die übernommenen Angestellten von Atmel nicht sofort nach der Übernahme auf der Straße sitzen.
> In der aktuellen gcc toolchain von Microchip wird der ATmega4808 / oder 4809
nicht unterstützt.
Vielleicht die falsche toolchain. Wie von denen angekündigt, ziehen sie
mehr auf MPLABX ab als auf das Atmel Studio. Unter xc8-v2.xx findet man
Unterstützung für den 4808. Und sie sind "gelb" beim
SNAP/Pickit4/AtmelICE.
Stefanus F. schrieb: > Veit D. schrieb: >> warum soll die Versionsnummer (9.2) seltsam sein? > > Weil die Pakete von Atmel/Microchip sowie die gängigen Linux > Distributionen noch bei Version 5.4.0 sind. Laut meiner Meinung liegt das daran das die "beigelegte" Toolchain eben leider nie aktualisiert wurde mit der Atmel Studio Weiterentwicklung. Warum auch immer. Die ist eben hornalt. Kann man jedoch ändern. Da alle Bsp. in den Manuals allerdings in Assembler und C sind interessiert das nur die C++ Programmierer. Deswegen ist jedoch eine aktuelle Versionsnummer 9.2 nicht seltsam. :-) Gängige Linuxdistris wie Ubuntu (aktuelle LTS) ist bei gcc 7.4. Rolling Release Distris haben immer die aktuelle zur Verfügung. Alles andere ist mir zu viel Spekulation.
Veit D. schrieb: > Gängige Linuxdistris wie Ubuntu (aktuelle LTS) ist bei gcc 7.4. Nein, siehe Anhang. Auch Debian ist bei Version 5.4.0. Arch Linux ist bei Version 9.2.0
Hallo Stefanus, du sprachst von der gcc Version die eine Linux Distri mitbringt. Gehst du bei Ubuntu ins Terminal und fragst die gcc Version ab bekommste 7.4 angezeigt. Bei arch eben brand aktuell 9.2 (mindestes 9.1.). Aber das sind die gcc Versionen. Das hat nichts mit der avr-gcc zu tun. Die muss man sich selbst bauen wenn es kein anderer wie für einen macht. Dafür haste 3 Möglichkeiten a) selbst bauen b) Zak Paket c) mein Paket Wenn man nun irgendwelche IDE Pakete installiert können diese natürlich ihre eigene Toolchain mitbringen. Das hat aber wie gesagt nichts mit der Distri eigenen gcc Version zu tun. Bei arch gibts eine avr-gcc 9.2 zum nachinstallieren, ja, aber wie gesagt stammt die aus der Community und nicht von der Distri selbst. Man ist abhängig vom Maintainer. Genauso wie man abhängig von Zak ist bis er seine aktualisiert. Edit: und dann ist immer noch die Frage ob neue µC schon unterstützt werden, also eingepflegt sind. Ansonsten nützt einem auch eine aktuelle avr-gcc nichts.
:
Bearbeitet durch User
Veit D. schrieb: > du sprachst von der gcc Version die eine Linux Distri mitbringt. Gehst > du bei Ubuntu ins Terminal und fragst die gcc Version ab bekommste 7.4 > angezeigt. Ich rede die ganze Zeit vom avr-gcc, den die Linux Distributionen mit bringen.
Ich erkläre den Unterschied zwischen gcc den die Linux Ditri mitbringt und einer avr-gcc die man aus irgendwelchen Paketquellen nachinstallieren kann nicht noch einmal. Nein, wirklich nicht.
Veit D. schrieb: > Ich erkläre den Unterschied zwischen gcc den die Linux Ditri > mitbringt > und einer avr-gcc die man aus irgendwelchen Paketquellen > nachinstallieren kann nicht noch einmal. Nein, wirklich nicht. Das verlangt auch niemand. Mein Linux (Ubuntu und Debian auf mehreren Rechnern) enthält den avr-gcc 5.4.0. Deswegen finde ich die Versionsnummer 9.2.0 seltsam. Dass die neueste avr-gcc Version die Nummer 9.2.0 trägt, habe ich längst akzeptiert und bestätigt. Du bis derjenige, der hier unpassender weise mit dem anderen gcc argumentiert hat. Um den geht es hier nicht, über den wollen wir nicht diskutieren. Lass gut sein.
Bitte 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.