Forum: Compiler & IDEs AVR128DA AVR-GCC ohne ATMEL Studio (woher nehmen)


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von 900ss (900ss)


Lesenswert?

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
von c-hater (Gast)


Lesenswert?

900ss D. schrieb:

> Danke für hilfreiche Hinweise.

MC-Studio installieren und benutzen.

von 900ss (900ss)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

Letztendlich hast Du die Wahl zwischen Atmel Studio, MPLABX/XC8 und 
IAR($$$).

fchk

von c-hater (Gast)


Lesenswert?

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...

von Gerhard O. (gerhard_)


Lesenswert?

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

von 900ss (900ss)


Lesenswert?

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
von Gerhard O. (gerhard_)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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?

von 900ss (900ss)


Lesenswert?

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
von Gerhard O. (gerhard_)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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.

von Gerhard O. (gerhard_)


Lesenswert?

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.

von Veit D. (devil-elec)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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?

von 900ss (900ss)


Lesenswert?

Veit D. schrieb:
> Also wenn du unbedingt willst kann ich dir was anbieten.

Danke :)
Ich schreib dir eine PN.

von 900ss (900ss)


Lesenswert?

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. ;)

von 900ss (900ss)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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?

von FS (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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?

von 900ss (900ss)


Lesenswert?

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 ;)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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).

von c-hater (Gast)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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
von 900ss (900ss)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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
von 900ss (900ss)


Lesenswert?

Jörg W. schrieb:
> Naja, ich habe ja einen PD-Sourcecode

Ich dachte eher zum Hack für die avrlibc bzgl. NVM.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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).

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.