Hallo, wo werde ich fündig, wenn ich (möglichst für Windows) eine Toolchain brauche, die auch schon den AVR128DA48 beinhaltet? Muss ich dafür dieses Gebastel machen? Toolchain bei ATMEL runterladen und dann die devicepacks manuell nachinstallieren? Oder gibt es evtl. schon was fertiges? Die Toolchains von "Zakke" haben den scheinbar noch nicht drin. :-/ Danke für hilfreiche Hinweise. PS. Nein, bitte nicht Arduino.
:
Bearbeitet durch User
c-hater schrieb: > MC-Studio installieren und benutzen. Danke für den Hinweis, aber ich mag diese "fetten" Monster nicht. Wenn es eine "nackte" Toolchain gibt, dann würde ich es bevorzugen.
Letztendlich hast Du die Wahl zwischen Atmel Studio, MPLABX/XC8 und IAR($$$). fchk
900ss D. schrieb: > c-hater schrieb: >> MC-Studio installieren und benutzen. > > Danke für den Hinweis, aber ich mag diese "fetten" Monster nicht. Wenn > es eine "nackte" Toolchain gibt, dann würde ich es bevorzugen. Nunja, man kann sich das Leben auch kompliziert machen. Also: nach Installation des Studio aktualisierst du das entsprechende Device-Pack, dann extrahierst (kopierst) du die Toolchain und das Devicepack und deinstallierst das MC-Studio wieder. Fertig. Und bei der nächsten MCU dasselbe Spiel erneut... Nicht sehr sinnvoll oder effizient...
Moin, Was mich betrifft kann ich Folgendes berichten: Die Arduino IDE kann man mit Spence Kondes "DXCore" für die neuen AVRs erweitern. Ich arbeite zur Zeit mit guten Ergebnissen für einen DA/DB uC. Ferner funktioniert CodeVision AVR damit auch einwandfrei und ist voll unterstützt. Es erlaubt direkte Programmierung mittels ICE. Programmieren lässt sich der DA/DB entweder mit dem Bootloader direkt vom Arduino-IDE mit AVRDude oder mit dem ICE über MC Studio. Gerhard
Hmmm..... ok, ich gebe mich geschlagen :) Ich hatte die Hoffnung, dass es evtl. etwas anderes gibt. Danke für die Hinweise. Edit: Ah da kam noch etwas von Gerhard. CodeVision ist $-Ware. Das ist nicht unbedingt ein Showstopper, aber wenn es den GCC so gibt :) Den DXCore für Arduino kenne ich. Ich habe gerade aus Arduino die Toolchain mit dem DXCore extrahiert und es scheint zu funktionieren als Standalone-Lösung. Aber ich traue dem Braten noch nicht ;)
:
Bearbeitet durch User
900ss D. schrieb: > Hmmm..... ok, ich gebe mich geschlagen :) > > Ich hatte die Hoffnung, dass es evtl. etwas anderes gibt. > Danke für die Hinweise. > > Edit: Ah da kam noch etwas von Gerhard. CodeVision ist $-Ware. Das ist > nicht unbedingt ein Showstopper, aber wenn es den GCC so gibt :) > > Den DXCore für Arduino kenne ich. > Ich habe gerade aus Arduino die Toolchain mit dem DXCore extrahiert und > es schient zu funktionieren als Standalone-Lösung. Aber ich traue dem > Braten noch nicht ;) Bis jetzt geht es bei mir tadellos. Auch Veit hat schon viel damit gemacht. Arduino ist ja GCC. Mit den DXCore Erweiterungen geht das ja prinzipiell. Man kann notfalls mit direkt mit main.cpp ohne "loop()" arbeiten wo nichts "Arduinoisches" eingebunden wird und könnte vorläufig als Übergangslösung für Dich dienen. Abgesehen davon ist Minimal Arduino Eingebundenes nicht so schlimm. Man kann ja sonst damit in "Bare Metal" arbeiten. Man ist ja nicht gezwungen mit deren Libs zu arbeiten. Und die Seriell Funktion ist ja gut funktionierend.
Gerhard O. schrieb: > Die Arduino IDE Benutzt du die IDE eigentlich zum Editieren und übersetzen oder hast du dir was gebaut um mit einem eigenen IDE/Editor/Makefile (z.B. Eclipse) zu arbeiten?
Gerhard O. schrieb: > Man > kann ja sonst damit in "Bare Metal" arbeiten. Ja das stimmt, ich habe da auch schon einiges probiert. Aber ich versuche immer um die Arduino IDE herumzukommen und der Aufwand ist nicht ohne. Funktioniert aber schön ist anders ;) Gerhard O. schrieb: > Und die Seriell Funktion ist ja gut > funktionierend. Ja das stimmt, die Arduno "Basics" sind schon ok.
:
Bearbeitet durch User
900ss D. schrieb: > Gerhard O. schrieb: >> Die Arduino IDE > > Benutzt du die IDE eigentlich zum Editieren und übersetzen oder hast du > dir was gebaut um mit einem eigenen IDE/Editor/Makefile (z.B. Eclipse) > zu arbeiten? Ich bin mit der IDE für meine relativ kleinen nicht sehr anspruchsvollen Projekte zufrieden. Habe aber auch die IDE so eingestellt um optional mit einen externen Editor umgehen zu können. Was mich als "Gelegenheitsprogrammierer" betrifft, finde ich die Arduino IDE ausreichend komfortabel. Auch Multi-Modul GCC Projekte lassen sich nicht zu schlecht durchziehen. Das Schöne am IDE ist, daß es praktisch nach Voreinstellung "aus der Box" gut überall funktioniert. Ob Desktop oder Läppie, es macht nichts aus. Aber jeder muß halt selber wissen wie angehoben die Entwicklungsumgebung gestaltet werden soll. Für mich reicht es eigentlich aus. Mit Makefile mache ich nichts unter Windows weil es immer für mich unlösbare Pfad Probleme gab und mir das zu blöd wurde. Da funktioniert das wesentlich besser in Linux. Unter dem IDE scheint das immer zu funktionieren.
Gerhard O. schrieb: > Das Schöne am IDE ist, daß es praktisch nach Voreinstellung "aus der > Box" gut überall funktioniert. Solange man nicht viele externe Libraries einbindet, stimme ich dir zu. Aber ich habe schon ziemlich viel Quälerei hinter mir weil irgendwelche Inkompatibilitäten zwischen Libraries entstanden und sich das nur an nicht funktionierendem Code zeigte. Nach eine Neuinstallation der IDE und nur der Libs, die ich brauchte, funktionierte es dann plötzlich ohne weitere Codeänderung. Und das hat mich zu oft Nerven gekostet :) Solange man nichts aufwendiges macht, möglichst ohne Extra-Libraries, geht es.
900ss D. schrieb: > Gerhard O. schrieb: >> Das Schöne am IDE ist, daß es praktisch nach Voreinstellung "aus der >> Box" gut überall funktioniert. > > Solange man nicht viele externe Libraries einbindet, stimme ich dir zu. > Aber ich habe schon ziemlich viel Quälerei hinter mir weil irgendwelche > Inkompatibilitäten zwischen Libraries entstanden und sich das nur an > nicht funktionierendem Code zeigte. Nach eine Neuinstallation der IDE > und nur der Libs, die ich brauchte, funktionierte es dann plötzlich ohne > weitere Codeänderung. Und das hat mich zu oft Nerven gekostet :) > > Solange man nichts aufwendiges macht, möglichst ohne Extra-Libraries, > geht es. Ja. Ich kenne Ähnliches über die Jahre. Aber irgendwie ist es besser geworden. Im Augenblick geht alles ziemlich gut. Wenn man, wo es Sinn hat, Bare Metal arbeitet, dann ist man weniger von Externalitäten abhängig. Andrerseits hat man bei Stacks zu Frameworks wenig Alternativen. An sich betrifft mich das allerdings kaum, weil ich mehr mit klassischen uC Aufgaben abgebe wo ich so ziemlich alles selbst im Griff habe. Ich bin auch Portierung gewohnt. Ob (ds) PIC, AVR, oder ARM , mir macht das nicht zu viel aus. Im Augenblick finde ich Arduino die bequemste Entwicklungsumgebung für die relativ kleinen 8-bit uC Anwendungen die mich momentan interessieren. Vor zwölf Jahren befasste ich mich jahrelang in der Firma mit ARMTDI und habe mich damals gut damit eingearbeitet. Heute bin ich mit ARM rostig. Damals funktionierte auch CooCox mit STDPL recht gut. Auch die NXP Cortexen funktionierten recht gut. Aber im Hobby spiele ich lieber mit einfacheren 8-bit Anwendungen weil man nicht monatelang programmieren muß und Lebenszeit aufbraucht. Mit 68 ist meine Energie für komplizierte Projekte auch nicht mehr so vorhanden wie früher als Jungspund. Aber das trifft nur auf mich in meiner aktuellen Zeit zu. Ich rate Dir, die eine Entwicklungsumgebung zu pflegen die Dir zusagt und dann so lange wie möglich dabei zu bleiben, bis eben was Besseres hereinschneit und die Umstellung dann auch lohnend ist. Eintagsfliegen nachzulaufen lohnt sich nicht. Gib Dich mit dem ab, das erfahrungsweise funktioniert.
900ss D. schrieb: > Hallo, > > wo werde ich fündig, wenn ich (möglichst für Windows) eine Toolchain > brauche, die auch schon den AVR128DA48 beinhaltet? Also wenn du unbedingt willst kann ich dir was anbieten. avr-gcc 9.4.0 oder avr-gcc 11.2.0 mit binutils 2.36.1. Welches Atmel Devicepack darf es denn sein? 1.10.114 oder das brand aktuelle 2.0.141? Ich selbst mache viel mit Arduino IDE und mit Atmel Studio 7 rum. Vorwiegend Arduino IDE. Ist einfach am bequemsten.
:
Bearbeitet durch User
900ss D. schrieb: > Wenn > es eine "nackte" Toolchain gibt, dann würde ich es bevorzugen. Hat denn schonmal jemand die CCL ohne MC-Studio benutzt?
Veit D. schrieb: > Also wenn du unbedingt willst kann ich dir was anbieten. Danke :) Ich schreib dir eine PN.
Peter D. schrieb: > Hat denn schonmal jemand die CCL ohne MC-Studio benutzt? Ich nicht. Aber die CCL brauche ich aktuell auch nicht. Wenn es so sein sollte, dann werde ich ja sehen, ob ich es ohne hinbekomme oder nicht. Aber wahrscheinlich eher nicht oder nur nach vielem Probieren. Wird nicht so einfach sein. ;)
Gerhard O. schrieb: > Ich rate Dir, die eine Entwicklungsumgebung zu pflegen die Dir zusagt > und dann so lange wie möglich dabei zu bleiben, bis eben was Besseres > hereinschneit und die Umstellung dann auch lohnend ist. Eintagsfliegen > nachzulaufen lohnt sich nicht. Gib Dich mit dem ab, das erfahrungsweise > funktioniert. Genau deshalb möchte ich den GCC + Binutils "standalone" nutzen. Ich benutze seit 2006 Eclipse als IDE und bin da zufrieden mit. Manche sagen langsam, ja nur beim Starten, danach ist es meiner Meinung völlig ok. Und ich starte das Ding einmal am Tag. Da bin ich dann geduldig ;) Allerdings sind die AVR128DA schon mächtig. Die Clockeinstellung ist deutlich aufwendiger als bei einem ATMEGA/TINY und wenn man dann so Dinge wie die CCL nutzen möchte, wird es wahrscheinlich kaum ohne MPLABX gehen.
900ss D. schrieb: > Genau deshalb möchte ich den GCC + Binutils "standalone" nutzen. Dann mach das doch einfach. Installiere das Studio, und fertig. Benutzen musst du es ja nicht. Setz den Pfad auf die mitgelieferte toolchain, und nimm die IDE deiner Wahl. Oliver
Peter D. schrieb: > Hat denn schonmal jemand die CCL ohne MC-Studio benutzt? Naja, ich benutze die CCL i.d.R. zwar schon im MC-Studio, aber ich wüßte nicht, was mir das Studio dabei helfen sollte oder geholfen hätte (abgesehen natürlich von der Bereitstellung den üblichen Registerdeklarationen). Was meinst du also eigentlich?
Man kann doch die AVR GNU Toolchain und die Device Packs von Atmel/Microchip völlig unabhängig von der IDE verwenden. Das gewünschte Device Pack muss dafür doch nur von https://packs.download.microchip.com/ heruntergeladen, entpackt und mittels Kommandozeilenschalter dem AVR-GCC beim Kompilieren mitgeteilt werden, am simpelsten per Makefile. Ich mach das seit geraumer Zeit für meine Projekte nur noch so. Für das DFP einmal:
1 | -B <Pfad-zum-DFP>/gcc/dev/<Device-Name>/ |
und für die dazugehörigen Header noch:
1 | -I <Pfad-zum-DFP>/include |
Unter Windows die Pfadangaben natürlich mit Backslash.
Oliver S. schrieb: > Dann mach das doch einfach. Installiere das Studio, und fertig. Benutzen > musst du es ja nicht. Setz den Pfad auf die mitgelieferte toolchain, und > nimm die IDE deiner Wahl. So isses. Übrigens könnte man, wenn man nur die Toolchain benutzen und zusätzlich gelegentlich die Device-Packs aktualisieren möchte, diese Teile auch aus dem Studio extrahieren und das Studio danach wieder deinstallieren. Beides ist unabhängig von der eigentlichen Studio-Installation lauffähig. Naja, ein klein wenig Konfigurationsarbeit am Pack-Manager muss man natürlich leisten, aber das ist wirklich sehr überschaubar. Ich verstehe bloß nicht, wozu das gut sein soll. Wer verzichtet denn freiwillig und ohne Not auf Intellisense und den sonstigen Komfort des Studios?
c-hater schrieb: > Übrigens könnte man, wenn man nur die Toolchain benutzen und zusätzlich > gelegentlich die Device-Packs aktualisieren möchte, diese Teile auch aus > dem Studio extrahieren und das Studio danach wieder deinstallieren. Ich hatte vorhin mal nachgesehen. Der Download von MPLABX IDE ist ca. 650MB groß. Die haben nicht nur ein Rad ab, die fahren schon auf den Achsen ;) Da wird soviel Müll auf den Rechner geladen der beim späteren Deinstallieren mit Sicherheit nicht wieder vollständig verschwindet. Hab ich schon mehrmals erlebt. Etwas ausprobiert, deinstalliert. Später dann, komisch was ist denn das noch für ein Dienst auf dem Rechner? War ein Überbleibsel. Ich finde das furchtbar. c-hater schrieb: > Ich verstehe bloß nicht, wozu das gut sein soll. Wer verzichtet denn > freiwillig und ohne Not auf Intellisense und den sonstigen Komfort des > Studios? Eclipse bietet das auch. Und ich bin mit dem Komfort zufrieden. Aber langsam bin ich drauf und dran das Zeug mal zu installieren um mal zu sehen, ob es soviel besser ist als Eclipse. Ich glaube kaum, aber Glauben hat nichts mit Technik zu tun ;)
900ss D. schrieb: > Muss ich dafür dieses Gebastel machen? Toolchain bei ATMEL runterladen > und dann die devicepacks manuell nachinstallieren? Devicepacks sind zumindest ein gar nicht so schwieriger Weg. Habe ich im AVR-GCC bei FreeBSD jetzt ausprobiert. Man muss da nur eine Tüte voller specs-Files in ein entsprechendes Verzeichnis kopieren. (Was anderes macht das Studio ja auch nicht damit.) Der einzige Schönheitsfehler ist dann, dass diese devices bei --target-help nicht angezeigt werden, aber compilierbar wird es dann. Allerdings stolpere ich bei der Integration in die AVR-Libc noch darüber, dass das komplette EEPROM-Interface anders ist, sodass das dort gar nicht compiliert. Es gibt auch einige Foreneinträge dazu und eine public-domain-Implementierung des EEPROM-Interfaces für die AVR Dx. Ich werde demnächst zusehen, wie ich das in die AVR-Libc rein bekomme. Insbesondere halt, wie ich die AVR Dx generisch (ohne alle devices einzeln aufzuzählen) im Präprozessor von anderen Xmega / neuen Tiny unterscheiden kann, um diese alternative EEPROM-Implementierung zu benutzen. Ich denke mal, wenn ich damit durch bin, wäre das ausreichend Grund für ein neues AVR-Libc-Release, zumal ja schon Johanns Multilib-Änderungen drin sind, mit denen double64 unterstützt wird (optional natürlich).
900ss D. schrieb: > Ich hatte vorhin mal nachgesehen. Der Download von MPLABX IDE ist ca. > 650MB groß. Wir redeten hier zuletzt über das MC-Studio (früher Atmel-Studio). Das ist was völlig anderes als MPLABX. Allerdings auch nicht kleiner, eher im Gegentum... > Da wird soviel Müll auf den Rechner geladen der beim späteren > Deinstallieren mit Sicherheit nicht wieder vollständig verschwindet. Das ist unbezweifelbar so. Aber gegen sowas gibt es Snapshots. Man macht einen, installiert den Kram, zieht raus, was man braucht, legt es erstmal irgendwo anders hin, kehrt zurück zum Snapshot und packt dann den extrahierten Kram dorthin, wohin man ihn haben will. > Eclipse bietet das auch. Genauso wie die unerwünschten Hinterlassenschaften bei einer Deinstallation. Da ist Eclipse (je nach konkreter Ausformung) teilweise sogar noch VIEL schlimmer. Da geht es ohne den Snapshot-Trick kaum noch mit überschauberem Aufwand. Beim MC-Studio kann man das hingegen zur Not noch manuell leisten.
FS schrieb: > Man kann doch die AVR GNU Toolchain und die Device Packs von > Atmel/Microchip völlig unabhängig von der IDE verwenden. Hmmm... wusste ich nicht. Das ist ein super Hinweis. Ich habe es gerade mit einem AVR-GCC probiert, der die AVR128DA nicht kennt. Mit der Angabe des device packs nach Deinen Angaben hat es funktioniert. Man lernt nie aus. Ich gebe zu, alle Optionen der Toolchain kenne ich nicht ;) Danke :)
:
Bearbeitet durch User
c-hater schrieb: > Da ist Eclipse (je nach konkreter Ausformung) teilweise > sogar noch VIEL schlimmer. Da geht es ohne den Snapshot-Trick kaum > noch mit überschauberem Aufwand. Nöö, ich installiere Eclipse aus dem ZIP. Wenn es mir nicht mehr gefällt, lösche ich den Ordner, wo ich es entpackt habe und es ist vollständig verschwunden. Da bleibt nichts zurück.
900ss D. schrieb: > Nöö, ich installiere Eclipse aus dem ZIP. Wenn es mir nicht mehr > gefällt, lösche ich den Ordner, wo ich es entpackt habe und es ist > vollständig verschwunden. Da bleibt nichts zurück. Das pure Eclipse ist allerdings nicht sehr nützlich. Normalerweise braucht man einen Riesen-Arschvoll Plugins, um etwas Nützliches daraus zu machen... Das allerdings ist beim MC-Studio auch wieder ganz genauso. Du kannst das "Visual Studio (isolated shell)", also den Kern der Sache, vergleichbar mit einem nackten Eclipse, auch alleine installieren und vollkommen sauber wieder deinstallieren. Sprich: du laberst.
c-hater schrieb: > Das pure Eclipse ist allerdings nicht sehr nützlich. Normalerweise > braucht man einen Riesen-Arschvoll Plugins, um etwas Nützliches daraus > zu machen... Nö, ich nehme das mit integriertem CDT und dann eine handvoll Plugins. Fertig. Soviel ist das mit Eclipse nicht. Und ich kann dann den gesamten Installationsordner auf ein anderes System kopieren und es läuft wieder. Das mach mal mit MC Studio :) c-hater schrieb: > Sprich: du laberst. Damit ist die Diskussion mit dir beendet.
Jörg W. schrieb: > Devicepacks sind zumindest ein gar nicht so schwieriger Weg. Hatte mich noch nie damit beschäftigt da ich bisher keinen AVR verwendet habe wo ich keine Toolchain hatte. AVRs waren eher selten in Gebrauch oder ein AVR auf einem ARDUINO Board. Und dafür gab es bisher alles. Ich hab keine exotischen Boards genutzt. Jörg W. schrieb: > Ich denke mal, wenn ich damit durch bin, wäre das ausreichend Grund für > ein neues AVR-Libc-Release, zumal ja schon Johanns Multilib-Änderungen > drin sind, mit denen double64 unterstützt wird (optional natürlich). EEPROM nutze ich noch nicht. Deshalb wäre es mir nicht aufgefallen. So kompliziert ist es ja nicht, dass auf Register-Ebene anzusteuern. Aber ich hätte natürlich die AVR-Libc dafür genutzt und wäre dann erstmal gescheitert. Ich freue mich natürlich über ein neues AVR-Libc-Release. Auch wenn ich double64 aktuell auch nicht brauche. Aber das ist natürlich eine tolle Erweiterung.
900ss D. schrieb: > Nö, ich nehme das mit integriertem CDT und dann eine handvoll Plugins. CDT... Naja, wenn sich die Fähigkeiten auf C/C++ beschränken... Damit ist dann eigentlich schon alles geklärt... > Damit ist die Diskussion mit dir beendet. Sehe ich auch so.
900ss D. schrieb: >> Ich denke mal, wenn ich damit durch bin, wäre das ausreichend Grund für >> ein neues AVR-Libc-Release, zumal ja schon Johanns Multilib-Änderungen >> drin sind, mit denen double64 unterstützt wird (optional natürlich). > > EEPROM nutze ich noch nicht. Deshalb wäre es mir nicht aufgefallen. Ist aber eben so, dass der Sourcecode der avr-libc für diese Devices im Moment nicht nur nicht funktioniert, sondern sich gar nicht compilieren lässt, weil er versucht, auf Register zuzugreifen, die es bei AVR Dx nicht mehr gibt (im NVM Controller). Weiß nicht, was sie bei Microchip da mit ihren device packs ausliefern. Möglicherweise haben sie das mit einem Hack zum Compilieren gebracht, aber es funktioniert nicht. Ich glaube nicht so recht dran, dass sie es wirklich neu geschrieben haben, aber genau das scheint für diesen neuen NVM-Controller nötig zu sein.
Jörg W. schrieb: > Ist aber eben so, dass der Sourcecode der avr-libc für diese Devices im > Moment nicht nur nicht funktioniert, sondern sich gar nicht compilieren > lässt, weil er versucht, auf Register zuzugreifen, die es bei AVR Dx > nicht mehr gibt (im NVM Controller). Hmmm... gibts keinen den du dazu fragen könntest?
900ss D. schrieb: > Hmmm... gibts keinen den du dazu fragen könntest? Naja, ich habe ja einen PD-Sourcecode: https://github.com/epccs/MacGyver/blob/master/Applications/lib/eerw_dx.h https://github.com/epccs/MacGyver/blob/master/Applications/lib/eerw_dx.c Ich muss mir nur nochmal die diversen CPP-Makros ansehen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Naja, ich habe ja einen PD-Sourcecode Ich dachte eher zum Hack für die avrlibc bzgl. NVM.
900ss D. schrieb: > Jörg W. schrieb: >> Naja, ich habe ja einen PD-Sourcecode > > Ich dachte eher zum Hack für die avrlibc bzgl. NVM. Da dieser Sourcecode offenbar getestet ist, würde ich den für die AVR Dx in die Avr-Libc einbauen wollen.
Jörg W. schrieb: > weil er versucht, auf Register zuzugreifen, die es bei AVR Dx > nicht mehr gibt (im NVM Controller). Das ist bei den AVRs ja ein alter Hut. Bei den Timern, UARTs, usw. wurden regelmäßig die Vektor-, Register- und Bitnamen umgerubelt. Wenn man z.B. vom ATmega8 zum ATmega88 upgradet, muß man den UART-Code umschreiben oder sich Macros zur Übersetzung erstellen. Und die Assemblerfreaks müssen zusätzlich von IO auf RAM umstellen (IN,OUT->LDS,STS).
Peter D. schrieb: > Bei den Timern, UARTs, usw. wurden regelmäßig die Vektor-, Register- und > Bitnamen umgerubelt. Es ist aber hier eine komplett andere Baustelle. Der NVM-Controller der AVR Dx ist einfach mal anders gestrickt als bei frühere Xmegas, es sind nicht nur irgendwelche Umbenamsungen. Letztere wären in der Lib relativ einfach handhabbar gewesen.
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.