www.mikrocontroller.net

Forum: Compiler & IDEs WinAVR vs. Atmels Toolchain


Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich bin mit dem Auftauchen der neuen Toolchain für das AVR-Studio 
ziemlich verwirrt, alles redet (noch?) von WinAVR, oder gar Eclipse, 
oder AVR-GCC.

Soweit ich glaube zu überblicken, ist die Toolchain zusammen mit 
AVR-Studio neuerdings eine eigenständige Alternative zu WinAVR oder 
Eclipse? Vielleicht sollte man ein paar Worte dazu im AVR-Tutorial und 
AVR-GCC-Tutorial an den Anfang setzen.

Es wird auch meißt von AVR-GCC geredet, ich vermute damit ist "die 
Toolchain" von Atmel gemeint?

Mein AVR-Studio scheint neben der Toolchain eben auch WinAVR, falls 
installiert, verwenden zu können, was die Frage aufwirft, welche der 
beiden Optionen ist für die verschiedenen 
Benutzergruppen/Anwendungsbereiche vorzuziehen, z.b. was ist 
Einsteigerfreundlicher, was ist flexibler (in der Anpassung, 
Konfiguration)? Zwei, drei Sätze dazu würden zu Beginn der genannten 
Tutorials auch sehr helfen. Ich würd gern helfen die Tutorials 
upzudaten, im Moment habe ich aber noch zuwenig durchblick.

Ich habe schon frühere Anläufe mit WinAVR und Eclipse hinter mir, aber 
allein das Makefile-Voodoo hat mich ziemlich schnell abgeturnt, wenn das 
mit der integrierten Toolchain nun alles Out-of-the-Box laufen sollte, 
wäre das doch die beste Grundlage für das AVR-GCC Tutorial (anstelle des 
für den Einsteiger schwierigsten Weg über Ecplipse)

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich häng mich mal mit dran, interessiert mich auch...

Autor: Sebastian M. (psytalent)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Atmel-Toolchain soll wohl WinAVR ablösen.  Hintergrund dabei ist,
dass Eric Weddington (derjenige, der nun über Jahre WinAVR zusammen-
gestellt hat) ja seit einigen Jahren von Atmel bezahlt wird, sodass
man lieber ein "Atmel-Produkt" sehen möchte.  Außerdem ist es wohl
der Versuch, AVR (8-bit) und AVR32 unter einen Deckel zu bekommen.

AVR-GCC ist ein GCC, der für das "target" AVR konfiguriert worden ist.
Dieser ist einer der Bestandteile, die WinAVR (bzw. die AVR Toolchain)
bilden.  Weitere wesentliche Bestandteile sind die GNU binutils
(Assembler, Linker und paar Tools darum herum, ebenfalls für den AVR
konfiguriert), die avr-libc (Standardbibliothek) und AVRDUDE
(Programmierwerkzeug).

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:

> AVR-GCC ist ein GCC, der für das "target" AVR konfiguriert worden ist.

Ist was über die Atmel-Strategie bezüglich avr-gcc bekannt? D.h. werden 
sie, wie es bisher mit WinAVR war, auf (gepatchte) FSF-Quellen 
aufsetzen, oder analog wie bei AVR32, der ja im Gegensatz zu AVR keine 
"offizielle" GCC-Architektur ist, eine eigene Linie aufziehen mit 
separaten (Quell-)Downloads?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> D.h. werden
> sie, wie es bisher mit WinAVR war, auf (gepatchte) FSF-Quellen
> aufsetzen,

Davon kann man ausgehen.  Ungepatchte wäre schöner ;-), aber die
Entwicklung der Halbleiterindustrie ist leider etwas schneller,
als die Release-Policy des Kolosses namens GCC es gestatten würde,
das alles "upstream" zeitnah aufgenommen zu bekommen.

> oder analog wie bei AVR32, der ja im Gegensatz zu AVR keine
> "offizielle" GCC-Architektur ist, eine eigene Linie aufziehen mit
> separaten (Quell-)Downloads?

Dass AVR32 hier ausschert, ist meines Wissens nicht unbedingt
Absicht, sondern hängt mit diversen juristischen Querelen zusammen.
Du weißt ja wohl am besten, wie schwierig es ist, dieses vermaledeite
copyright assignment unter Dach und Fach zu bekommen — nun stell' dir
das mal für einen Laden wie Atmel vor, bei dem noch eine Rechtsab-
teilung mit ins Spiel kommt...

Ich würde mal hoffen, dass über kurz oder lang auch AVR32 seinen Weg
ins offizielle Repository findet, aber nichts genaues weiß ich da
auch nicht.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>
>> D.h. werden
>> sie, wie es bisher mit WinAVR war, auf (gepatchte) FSF-Quellen
>> aufsetzen,
>
> Davon kann man ausgehen.  Ungepatchte wäre schöner ;-), aber die

Ja, fürwahr. Die Testbasis wäre damit etwas größer und die Entwicklung 
einfacher. IMHO sollte Atmel die non-GPL Patches vergessen und jemand 
anheuern, der GPL-kompatible Patches für die Bugs einbringt. Das wär 
wahrscheinlich billiger und auch für Erik deutlich nervensparender als 
diesen Sack voll Flöhe zu verwalten anstatt ihn einfach los zu werden. 
Und was Testbasis angeht... ich überfliege gerade die avr-bugs und 
solche Klopper wie

http://gcc.gnu.org/PR45291

wären bestimmt schon viel früher aufgefallen. Keine Ahnung, wie lange 
das schon drinne ist. Schätze mal 4.2 oder 4.3 oder noch älter.

> Entwicklung der Halbleiterindustrie ist leider etwas schneller,
> als die Release-Policy des Kolosses namens GCC es gestatten würde,
> das alles "upstream" zeitnah aufgenommen zu bekommen.

Ach komm, wenn Atmel ein neues Derivat auf den Markt wirft, dann wissen 
die das doch im Voraus und würden besser ne Co-Entwicklung anstreben als 
immer hinterher zu hecheln. Nach dem Motte "um Gottes Willen, in 2 
Wochen ist Weihnachten/Messe/was-auch-immer. Gaaanz plötzlich!". Ich 
denk die haben inzwischen erkannt wie wichtig GCC für ihre Käfer ist, 
auch und gerade für AVR.

>> oder analog wie bei AVR32, der ja im Gegensatz zu AVR keine
>> "offizielle" GCC-Architektur ist, eine eigene Linie aufziehen mit
>> separaten (Quell-)Downloads?
>
> Dass AVR32 hier ausschert, ist meines Wissens nicht unbedingt
> Absicht, sondern hängt mit diversen juristischen Querelen zusammen.
> Du weißt ja wohl am besten, wie schwierig es ist, dieses vermaledeite
> copyright assignment unter Dach und Fach zu bekommen — nun stell' dir
> das mal für einen Laden wie Atmel vor, bei dem noch eine Rechtsab-
> teilung mit ins Spiel kommt...

ARGL, ja. Ist wohl auch einer der Gründe, warum PIC nicht offiziell ist. 
Ich hab da einmal in die Quellen geschaut... heidenei. Die Jungs 
entwickeln GCC offenbar unter Windows und sind wohl recht hart im 
Nehmen... ;-)

Was die Rechtsabteilungen angeht ja, da sind manche Firman echt 
paranoid. Ich kenn da welche, die ihr proprietäre Software mit gcc 
entwickeln, aber noch nichtmal gegen die libgcc linken aus Panik, sie 
müssten ihre Quellen offenlegen (wo man, beim Reinschauen denkt: bei 5% 
"Hut ab", bei den restlichen 95% "wir werden alle sterben!").

> Ich würde mal hoffen, dass über kurz oder lang auch AVR32 seinen Weg
> ins offizielle Repository findet, aber nichts genaues weiß ich da
> auch nicht.

Die Frage ist auch, inwieweit bei der Implementierung das Backend 
verlassen werden musste/wurde. Wenn Atmel das gemacht hat -- warum auch 
immer -- wird's doppelt schwer.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>
>> D.h. werden sie, wie es bisher mit WinAVR war,
>> auf (gepatchte) FSF-Quellen aufsetzen,
>
> Davon kann man ausgehen.

Das bedeutet im Endeffekt also einen Fork. Das wird doch für Atmel 
allenfalls kurz- oder mittelfristige Vorteile bringen. Auf lange Sicht 
wird es den mainline gcc ausbremsen (was effektiv schon seit längerem 
geschieht) und früher oder später wahrscheinlich auch den Atmel-Fork.

Selbst wenn sich Entwickler für avr-gcc fänden wird das die Situation 
nicht auflösen, wenn die Weiterentwicklung der mainline die 
Weiterentwicklung des Atmel-Forks erschwert -- was sie aber zwangsläufig 
tun wird. Eine Weiterentwicklung dürfte also nicht ganz im Interesse von 
Atmel sein.

Sehr interessant in dem Zusammenhang finde ich auch folgenden Artikel.

http://linux.sys-con.com/node/33898

Der Artikel ist von 2003, aber heute wohl noch deutlich aktueller als 
damals, weil sich gcc im kommerziellen Bereich weiter etabliert hat und 
vermutlich noch weiter etablieren wird. Das Image von 
zusammengeschusterter, unsicherer Software stimmt eben immer weniger 
(wenn es je gestimmt hat) und das ist eben auch in der Industrie 
angekommen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

>> Davon kann man ausgehen.  Ungepatchte wäre schöner ;-), aber die
>
> Ja, fürwahr. Die Testbasis wäre damit etwas größer und die Entwicklung
> einfacher.

Naja, das wage ich zu bezweifeln, dass sich davon die Testbasis in
irgendeiner Weise nennenswert vergrößert.  Die mit Abstand größte
Testbasis stellen derzeit eindeutig die WinAVR- (bzw. künft Atmel AVR
Toolchain-)Nutzer dar.

> IMHO sollte Atmel die non-GPL Patches vergessen

Welche bitte?

Es gibt praktisch drei Sorten Patches:

. Bugfixes, die aus dem GCC-Trunk rückportiert worden sind auf eine
  ältere Compilerversion.  Mit dem Trunk bzw. selbst mit dem jüngsten
  Release will man in der Regel nicht sofort in die Produktion
  springen.

. "new devices" Patches der simplen Sorte, also im Wesentlichen ein
  Patchen der internen specs und dergleichen; unterhalb eines
  irgendwie copyright-mäßig interessierenden Niveaus anzusiedeln.

. Aufwändige Patch-Suites wie Xmega oder mittlerweile wohl tiny10;
  hier genügt es einfach mal nicht, dass man da eine GPL drüber
  schreibt, sondern du hast wieder das gleiche Dilemma wie auch schon
  beim AVR32: GCC besteht auf diesem blöden Copyright-Assignment, und
  wenn Atmel das Copyright hält, weil der Patch in deren Auftrag und
  mit deren Geld kreiert worden ist, dann bist du wieder bei der
  Rechtsabteilung...

>> Entwicklung der Halbleiterindustrie ist leider etwas schneller,
>> als die Release-Policy des Kolosses namens GCC es gestatten würde,
>> das alles "upstream" zeitnah aufgenommen zu bekommen.
>
> Ach komm, wenn Atmel ein neues Derivat auf den Markt wirft, dann wissen
> die das doch im Voraus und würden besser ne Co-Entwicklung anstreben als
> immer hinterher zu hecheln.

Der Release-Prozess eines GCC bleibt dennoch zu langsam, bzw. die
Zeit, bis man das Risiko eingehen möchte, einen Release auch wirklich
produktiv zu nutzen.  Kommt noch hinzu, dass es da sicher auch
firmenintern Befindlichkeiten gibt, die man respektieren muss: bevor
der Name eines neuen Modells in die Öffentlichkeit "transpiriert"
(sodass ihn ja u. a. dann auch die Konkurrenz mitbekommt und sich
einen Reim drauf machen kann), möchte man sich schon sicher sein, dass
es dafür auch in absehbarer Zeit benutzbares Silizium geben wird und
das Ding nicht "Vaporware" wird.  Damit fällt schon mal die
Möglichkeit aus, das bereits zum Beginn des Planungsprozesses
öffentlich irgendwo einzukippen.

> Was die Rechtsabteilungen angeht ja, da sind manche Firman echt
> paranoid. Ich kenn da welche, die ihr proprietäre Software mit gcc
> entwickeln, aber noch nichtmal gegen die libgcc linken aus Panik, sie
> müssten ihre Quellen offenlegen

Hatte ich bis vor kurzem auch für bekloppt gehalten.  Allerdings hat
GCC zeitgleich mit dem Umstellen der Lizenz auf GPLv3 die
Lizenzbedingungen für die libgcc (die "runtime") auch umformuliert,
und das Ergebnis ist nun leider für die Rechtsverdreher derartiger
Firmen ein gefundenes Fressen, da es keinesfalls mehr so eindeutig und
problemlos nachnutzbar ist, wie das noch zu GPLv2-Zeiten der Fall war.
Ich denke, dass das eigentliche Ziel der GCC-Leute lediglich war, dass
der runtime-Code nicht durch andere (nicht-GPL) Compiler nachgenutzt
werden darf (keine Ahnung, ob das überhaupt eine reale Gefahr war),
aber die Formulierungen sind leider nunmehr alles andere als
eindeutig.

Johann L. schrieb:

>>> D.h. werden sie, wie es bisher mit WinAVR war,
>>> auf (gepatchte) FSF-Quellen aufsetzen,
>>
>> Davon kann man ausgehen.
>
> Das bedeutet im Endeffekt also einen Fork.

Das verstehe ich nicht.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>
>>> Davon kann man ausgehen.  Ungepatchte wäre schöner ;-), aber die
>>
>> Ja, fürwahr. Die Testbasis wäre damit etwas größer und die Entwicklung
>> einfacher.
>
> Naja, das wage ich zu bezweifeln, dass sich davon die Testbasis in
> irgendeiner Weise nennenswert vergrößert.  Die mit Abstand größte
> Testbasis stellen derzeit eindeutig die WinAVR- (bzw. künft Atmel AVR
> Toolchain-)Nutzer dar.

Genau deshalb. Wieviel Windows-Anwender setzen einen avr-gcc-4.5.1 ein, 
was glaubst du? Ja, da sind Fehler drinne, die machen ihn unbenutzbar. 
Warum? Weil sich alles ewig aufgestaut hat. Nen erfahrenen 
GCC-Entwickler anzuheuern, der gemeldete Fehler zeitnah fixt, würde 
Atmel aus der Portokasse bezahlen. Momentan ist eben ein riesiger Berg 
entstanden, und es wird ewig dauern, den abzutragen.

>
>> IMHO sollte Atmel die non-GPL Patches vergessen
>
> Welche bitte?
>
> Es gibt praktisch drei Sorten Patches:
>
> . Bugfixes, die aus dem GCC-Trunk rückportiert worden sind auf eine
>   ältere Compilerversion.  Mit dem Trunk bzw. selbst mit dem jüngsten
>   Release will man in der Regel nicht sofort in die Produktion
>   springen.

Das geht für andere Tatgets doch auch. Und backports müssen ja nicht 
extern sein, sie können genauso intern sein wie die eigentlichen fixes. 
Ein Großteil der "Bugs" sind doch "performance regressions". Nur ein 
relativ kleiner Teil sind echte Bugs (die sich, wie gesagt, über einige 
Zeit ansammeln durften) oder Anwendungsfehler (zB falsche Anwendung 
globaler Register)

> . "new devices" Patches der simplen Sorte, also im Wesentlichen ein
>   Patchen der internen specs und dergleichen; unterhalb eines
>   irgendwie copyright-mäßig interessierenden Niveaus anzusiedeln.

IdR sind das copy-and-past-patches. Einen attiny2313a hinzuzufügen macht 
Eric doch schon. Erweiterungen wie 3-byte-pc brauchen natürlich mehr 
Arbeit und auch mehr Tests.

>>> Entwicklung der Halbleiterindustrie ist leider etwas schneller,
>>> als die Release-Policy des Kolosses namens GCC es gestatten würde,
>>> das alles "upstream" zeitnah aufgenommen zu bekommen.
>>
>> Ach komm, wenn Atmel ein neues Derivat auf den Markt wirft, dann wissen
>> die das doch im Voraus und würden besser ne Co-Entwicklung anstreben als
>> immer hinterher zu hecheln.
>
> Der Release-Prozess eines GCC bleibt dennoch zu langsam, bzw. die
> Zeit, bis man das Risiko eingehen möchte, einen Release auch wirklich
> produktiv zu nutzen.  Kommt noch hinzu, dass es da sicher auch

Das Problem ist teilweise doch, daß jeder immer die neueste (verfügbare) 
Release aufspielt ohne nachzudenken und überall die Ansprüchlichkeit 
ist, daß das ohne den kleinsten Hickser geht. Alles ist performance-geil 
(ok, ich auch manchmal, ich geb's ja zu) und denkt keine Sekunde darüber 
nach, ob es nicht vielleicht besser ist, erst mal anzugucken was da 
neues verfügbar ist oder auf der alten, bewährten Version zu bleiben.

Eine neue Version bedetet doch nicht, daß man die nutzen muss, und für 
die copy-and-paste-Targets könnte Atmel die bewährte Version mit updates 
zur Verfügung stellen, bis das in ne offizielle gcc release drinne ist.

> das Ding nicht "Vaporware" wird.  Damit fällt schon mal die
> Möglichkeit aus, das bereits zum Beginn des Planungsprozesses
> öffentlich irgendwo einzukippen.

Es könnte sich jemand anschauen wie das in gcc (bzw, binutils, gdb) 
umsetzbar wäre, zB ein Atmel-Mitarbeiter. Wenn es irgendwo gründlich 
hakt, ist es in phase 1 oft noch möglich, in die entwicklung 
einzugreifen, indem man zB in den MLs Probleme bespricht. Da geht es 
garnicht um Patches, sondern daß Hänfling avr nicht hinten runterfällt. 
Oft wird nur was übersehen, und wenn sich keiner beschwert, wird auch 
nix geändert (middle und frontend), wo es garkein avr-Entwickler 
bräuchte. Dinge wie zB

http://gcc.gnu.org/PR46278

würden viel früher erkannt. Konkret in diesem Falle lügt zwar das 
Backend, weil es falsche Kosten angibt, aber wenn ich es recht sehe hat 
IRA überhaupt nicht die Möglichkeit, das avr sich da reinhängt und die 
Kosten überhaupt beschreibt. D.h. das avr-Backend hätte überhaupt nicht 
die Basis, da groß was zu ändern. Oft geht es "nur" um diese Basis, die 
garnix direkt mit avr zu tun hat.

> Johann L. schrieb:
>
>>>> D.h. werden sie, wie es bisher mit WinAVR war,
>>>> auf (gepatchte) FSF-Quellen aufsetzen,
>>>
>>> Davon kann man ausgehen.
>>
>> Das bedeutet im Endeffekt also einen Fork.
>
> Das verstehe ich nicht.

Wenn heute jemand ein Fehler behebt dann ist das für 4.6.0 und evtl. 
backports; ein neues Feature oder Optimierung nicht vor 4.7.

Nehmen wir mal an, es fixt jemand nen Bug, für den Eric ein Patch hat. 
Derjenige wird sich den PR anschauen und was zu machen ist und wird 
einen Teufel tun, den Patch abzukäsen. D.h. Eric muss ab irgendeinem 
Zeitpunkt anfangen, alle Patches, die auf dem besagten PR sind zu 
portieren, und sozusagen mitten aus dem Stapel ein Patch rausziehen. Die 
Darüberliegenden Pflasterchen braucht er idealerweise nicht anzufassen 
(wie zB das Ada-Zeug) aber das ist keinswegs selbstverständlich, und je 
mehr Sachen in mainline behoben werden, desto stressiger wird es für 
Eric, auf ne neue Version zu gehen. Irgendwann wird er (bzw. Atmel) den 
Weg des geringsten Widerstands nehmen, d.h. sich von der mainline 
komplett abkoppeln und atmel-fork und mainline folgen unabhängigen 
Entwicklungen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jedenfalls scheint es momentan in diese Richtung zu laufen.

Weil keine avr-Entwickler weit und breit... Andrew Pinski macht hin und 
wieder was, ok.

Und es gab mal jemand, der nen pattern-Generator für peephole2 schreiben 
wollte. Das war das einzige mal, daß ich mitbekommen hatte, daß sich 
jemand für avr-Entwicklung interessiert oder Gedanken darüber macht und 
versucht was beizutragen (blieb aber wohl aus technischen Gründen bei 
der Idee, und ich hatte damals davon abgeraten sowas zu machen). Und 
A.K. hat zumindest ein paar Hacking-Skills, aber wohl kein Interesse.

Adacore scheint auch keine Ambitionen zu haben. BTW, was um aller Welt 
macht man mit Ada auf 'nem AVR? Im saftety-Bereich sind Compiler-Bugs 
bestimmt auch eher ungern gesehen ;-) Aber ok, vielleicht machen die 
ebenfalls ihre eigene Distribution.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Genau deshalb. Wieviel Windows-Anwender setzen einen avr-gcc-4.5.1
> ein, was glaubst du?

Keiner.  Der Grund ist, weil es keinen vorcompilierten gibt, und
Windows-Nutzer nun mal nur mit vorcompilierten Dingen wirklich
arbeiten wollen.

Das liegt aber nicht so sehr an den Patches (ja, die brauchen auch
manpower, damit man sie pflegt), sondern vor allem daran, dass WinAVR
bzw. dessen Nachfolger schlicht gar keine Möglichkeit haben, mehr als
eine Version des Compilers zu installieren (geschweige denn, zur
Laufzeit zwischen zweien umzuschalten).  Daher, und natürlich vor
allem, weil diese Tools von vielen Leuten für produktiven Code genutzt
werden, hinkt die populärste der AVR-Toolchains halt immer so um die
zwei minor versions hinter dem aktuellen Release hinterher.

Ich habe in meinen FreeBSD-Ports zwar die Möglichkeit, mehr als eine
Version überhaupt anzubieten, aber auch da kostet es man power, das zu
pflegen, und es bleibt eine Entscheidung zur Installationszeit, nicht
zur Laufzeit.

> Nen erfahrenen
> GCC-Entwickler anzuheuern, der gemeldete Fehler zeitnah fixt, würde
> Atmel aus der Portokasse bezahlen.

Wenn du einen kennst, dann schick ihn nach Colorado Springs.  Eric hat
händeringend versucht, jemanden anzuheuern (zumindest eine zeitlang,
keine Ahnung, ob der Job nach wie vor zu haben wäre).

Ergebnis: über Jahre hat niemand Interesse gezeigt.  Der einzige so
einigermaßen aktive AVR-GCC-Entwickler ist und bleibt Anatolij
Sokolov, und der will und kann das lediglich als Hobbyarbeit machen.

(Mittlerweile scheint Atmel wohl mindestens einen zu haben, der sich
um sowas kümmert, siehe Unterstützung für den ATtiny10.)

> Das geht für andere Tatgets doch auch. Und backports müssen ja nicht
> extern sein, sie können genauso intern sein wie die eigentlichen
> fixes.

Das braucht auch wieder jemanden, der bei GCC die nötigen Rechte hat,
dass er das ins SVN committen darf (und der natürlich die Zeit dafür
hat).

> Das Problem ist teilweise doch, daß jeder immer die neueste
> (verfügbare) Release aufspielt ohne nachzudenken und überall die
> Ansprüchlichkeit ist, daß das ohne den kleinsten Hickser geht. Alles
> ist performance-geil (ok, ich auch manchmal, ich geb's ja zu) und
> denkt keine Sekunde darüber nach, ob es nicht vielleicht besser ist,
> erst mal anzugucken was da neues verfügbar ist oder auf der alten,
> bewährten Version zu bleiben.

Genau deshalb bleibt aber WinAVR bei einer etwas älteren Version, was
dazu führt, dass die jeweils neueste in den Tests komplett
"unterbelichtet" ist.

> Da geht es garnicht um Patches, sondern daß Hänfling avr nicht
> hinten runterfällt.

Erics Ziel seit langem ist es, einen Simulator so verfügbar zu haben,
dass ihn jeder X-beliebige GCC-Entwickler bei sich installieren und
damit das AVR-Target testen kann.  Erst dann wäre er in der Lage, den
AVR als "2nd tier"-Target aufwerten zu lassen, sodass er stärker in
automatisierten Tests aufschlägt, was wiederum "lack of optimization"
Fehler den GCC-Entwicklern früher gewahr machen würde.  Bislang drehen
praktisch all diese Dinge erst eine komplette Runde über einen "mature
release" zu den Anwendern, und von da zurück als PR.

Keine Ahnung, wie weit Eric mit diesem Ansinnen mittlerweile vorwärts
kommen konnte.  Ein Opensource-Simulator wird halt für Atmel keine
große Priorität genießen (sprich: kaum bezahlte man power locker
machen), weil die sich natürlich hinstellen: "AVR Studio hat doch
einen prima Simulator, wofür sollten wir einen zweiten bezahlen?"

> D.h. Eric muss ab irgendeinem
> Zeitpunkt anfangen, alle Patches, die auf dem besagten PR sind zu
> portieren, und sozusagen mitten aus dem Stapel ein Patch rausziehen.

Ja, das ist so.  Lässt sich derzeit nicht ändern, hat aber seit Jahren
nun bereits nicht zu einem fork geführt sondern nur dazu, dass halt
WinAVR & Co. jeweils ein gutes Stück hinter dem aktuellen GCC-Release
hinterher hängen.  S. o. ...

Johann L. schrieb:

> Weil keine avr-Entwickler weit und breit...

Anatolij halt.  Ja, mehr AVR-Entwickler mit GCC-Fähigkeiten (und mit
dem Sche*** copyright assignment) wären sehr nützlich.  Erst hamm,
sprach Schramm, und dann ein Stück fort damit sein.

> Adacore scheint auch keine Ambitionen zu haben. BTW, was um aller Welt
> macht man mit Ada auf 'nem AVR?

Ist allemal eine schönere Sprache als C. ;-)  Wenn ich heute nochmal
anfangen würde als Programmierer, könnte ich mir gut vorstellen, lieber
Ada als C zu nehmen.

Autor: Mitleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>copyright assignment
Kannst du für die ahnungslosen Mitleser wie mich mal in wenigen Worten 
erklären was es mit diesem "Dings" auf sich hat? Google spuckt irgendwie 
keine kurze verständliche Erklärung aus.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mitleser schrieb:
>>copyright assignment
> Kannst du für die ahnungslosen Mitleser wie mich mal in wenigen Worten
> erklären was es mit diesem "Dings" auf sich hat?

Die FSF besteht für alle dem GNU-Projekt zugehörigen Projekte (also
insbesondere GCC, binutils und GDB) darauf, dass man für alle
Änderungen, die aus Copyright-Sicht relevant sind (also alles ab
Patches, die nicht trivial sind, bis hin natürlich zu komplett neuen
Dingen) ihnen das Copyright überträgt.  Vorgeblich möchten sie auf
diese Weise in die Lage versetzt sein, Copyright-Verstöße selbstständig
verfolgen zu können.

Die ganze Prozedur erfolgt aber in Schriftform, wobei sie lediglich
über eine Art Halbtags-Sekretöse verfügen (eher noch viel weniger)
und ganz offenbar mit der Abhandlung des selbst auferlegten Papierkriegs
völlig überfordert sind (wovon Johann ein leidvolles Lied singen kann).
Bevor der Mift aber nicht bei ihnen unterschrieben wieder auf dem Tisch
liegt, akzeptieren sie prinzipiell keine copyright-relevanten Beiträge
von irgendjemandem.  Ich selbst habe den Kram vorsorglich mal vor
Jahren für mich eingereicht und auch einigermaßen im zeitlichen Rahmen
durch bekommen (damals hatte ich eigentlich vor, den COFF-AVR-Patch für
die binutils offiziell beizusteuern, aber mittlerweile ist dieses Datei-
format ja glücklicherweise irrelevant geworden), habe den Papierkram
aber gleich für GCC, binutils und GDB komplett erledigt.

Das Lustige für uns Deutsche ist dabei, dass wir prinzipiell gar nicht
in der Lage sind, ein Copyright abzutreten, da dieses nach deutscher
Rechtsauffassung ein unveräußerliches Recht des Copyright-Inhabers
ist, das lediglich vererbbar ist.  Der ganze Papierkrieg ist für
unsereins daher eigentlich komplett verschwendete Zeit, aber die FSF
besteht darauf.

Autor: Mitleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg Wunsch
Und das ist natürlich eine Hemmschwelle für alle die da prinzipiell 
gerne mitmachen würden, verstehe.
Danke für die Erklärung und Hut ab vor euch Compiler-bauenden und 
Freizeit-in-Open-Source-Projekte-steckenden Menschen!

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>
>> Genau deshalb. Wieviel Windows-Anwender setzen einen avr-gcc-4.5.1
>> ein, was glaubst du?
>
> Keiner.  Der Grund ist, weil es keinen vorcompilierten gibt, und
> Windows-Nutzer nun mal nur mit vorcompilierten Dingen wirklich
> arbeiten wollen.
>
> Das liegt aber nicht so sehr an den Patches (ja, die brauchen auch
> manpower, damit man sie pflegt), sondern vor allem daran, dass WinAVR
> bzw. dessen Nachfolger schlicht gar keine Möglichkeit haben, mehr als
> eine Version des Compilers zu installieren (geschweige denn, zur
> Laufzeit zwischen zweien umzuschalten).

Hä? Da wär doch nur nen anderer Pfad anzugeben bei der "Installation" 
bzw. dem Aufruf. Für ne "Installation" bräuchte man nurn Archiv zu 
entpacken und das wars, das ganze Registry-Geraffel ist doch nur, damit 
astudio den gcc findet (denk ich mal, verwende kein astudio). Oder sind 
die neuen astudio-Releases dermassen mit gcc verdongelt, daß man nicht 
mal mehr auswählen kann, wohin die Tools installiert werden? Oder für 
jede Version von avr-gcc auch ne neue/andere Version von astudio 
installiert werden muss? Ich bin ja nicht in der astudio-Szene...

> Daher, und natürlich vor
> allem, weil diese Tools von vielen Leuten für produktiven Code genutzt
> werden, hinkt die populärste der AVR-Toolchains halt immer so um die
> zwei minor versions hinter dem aktuellen Release hinterher.
>
> Ich habe in meinen FreeBSD-Ports zwar die Möglichkeit, mehr als eine
> Version überhaupt anzubieten, aber auch da kostet es man power, das zu
> pflegen, und es bleibt eine Entscheidung zur Installationszeit, nicht
> zur Laufzeit.

Ok, klar. Ohne Installer geht wohl auch wegen des Lizenz-Clicks nicht 
oder Nicht-Installer-Distris nicht akzeptiert werden.

>> Nen erfahrenen
>> GCC-Entwickler anzuheuern, der gemeldete Fehler zeitnah fixt, würde
>> Atmel aus der Portokasse bezahlen.
>
> Wenn du einen kennst, dann schick ihn nach Colorado Springs.  Eric hat
> händeringend versucht, jemanden anzuheuern (zumindest eine zeitlang,
> keine Ahnung, ob der Job nach wie vor zu haben wäre).

Das überrascht mich jetzet. Ich weiß, daß gcc-Entwickler auch im 
kommerziellen Bereich rar sind. Aber daß sie sooo rar sind, daß noch 
nichtmal Atmel einen bekommt, wundert mich schon. Oder es stimmt was 
nicht mit den Randbedingungen". Davon ab ist Eric Maintainer, und manche 
Bugs zu finden (wenn sie denn gemeldet sind) dauert ein paar Minuten, 
dito sie zu beheben. Er könnte sich mit Kollegen beratschlagen und 
jemend anders macht dafür die etwas der zeitintensiven Support-Arbeit. 
Wo ein Wille ist, ist auch ein Weg. Wenn Atmel allerdings in 
lines-of-code/hour abrechnet, und sieht, daß eine gcc-Zeile auch mal 
$1000 kosten kann... naja.

> Ergebnis: über Jahre hat niemand Interesse gezeigt.  Der einzige so
> einigermaßen aktive AVR-GCC-Entwickler ist und bleibt Anatolij
> Sokolov, und der will und kann das lediglich als Hobbyarbeit machen.

Ok, er hat also ne Kaffee-Rechnung wie Hölle ;-)

>> Das geht für andere Tatgets doch auch. Und backports müssen ja nicht
>> extern sein, sie können genauso intern sein wie die eigentlichen
>> fixes.
>
> Das braucht auch wieder jemanden, der bei GCC die nötigen Rechte hat,
> dass er das ins SVN committen darf (und der natürlich die Zeit dafür
> hat).

Stop. Mal ganz langsam und von vorne. Ein FSF-CA genügt nicht ? 
Braucht man da noch svn write access? Dachte immer das geht so: 
patch->review->maintainer macht den svn-kram.

>> Das Problem ist teilweise doch, daß jeder immer die neueste
>> (verfügbare) Release aufspielt ohne nachzudenken und überall die
>> Ansprüchlichkeit ist, daß das ohne den kleinsten Hickser geht. Alles
>> ist performance-geil (ok, ich auch manchmal, ich geb's ja zu) und
>> denkt keine Sekunde darüber nach, ob es nicht vielleicht besser ist,
>> erst mal anzugucken was da neues verfügbar ist oder auf der alten,
>> bewährten Version zu bleiben.
>
> Genau deshalb bleibt aber WinAVR bei einer etwas älteren Version, was
> dazu führt, dass die jeweils neueste in den Tests komplett
> "unterbelichtet" ist.

Das meinte ich mit "es verkleinert die Testbasis"

>> Da geht es garnicht um Patches, sondern daß Hänfling avr nicht
>> hinten runterfällt.
>
> Erics Ziel seit langem ist es, einen Simulator so verfügbar zu haben,
> dass ihn jeder X-beliebige GCC-Entwickler bei sich installieren und
> damit das AVR-Target testen kann.  Erst dann wäre er in der Lage, den
> AVR als "2nd tier"-Target aufwerten zu lassen, sodass er stärker in
> automatisierten Tests aufschlägt, was wiederum "lack of optimization"
> Fehler den GCC-Entwicklern früher gewahr machen würde.  Bislang drehen
> praktisch all diese Dinge erst eine komplette Runde über einen "mature
> release" zu den Anwendern, und von da zurück als PR.

Ich hatte Eric schon gefragt, wie man ne Testumgebung (dejagnu) 
sinnigerweise aufsetzt. Keine Antwort.

Vemutlich ist da die Ansprüchlichkeit bei Atmel viel zu hoch. Ein 
Simulator für diesen Zweck braucht doch nicht die komplette (interne) 
Peripherie zu simulieren mit allen Weiß-der-Teufel-was-für-Features. Es 
geht doch nur um den Kern, und wenn ein Testfall wegen des Simulators 
failt und bekannt ist, wär ds ein Drama? Es geht doch vor allem um 
Regressions, die in neuen Versionen auftreten, nicht um den Absoutstand 
an Fehlern. Stacküberlauf, mangelnd RAM und avr fliegt raus, Trampolines 
werden nicht unterstützt, Exceptions, etc. Ist doch kein Drama.

Ein Simulator für den Kern reicht doch, und was in der testsuite 
unterhalb von gcc/testsuite/gcc.target/avr passiert ist für den Rest der 
gcc-Welt eher uninteressant. Und was gcc.target/avr angeht, da gibt's 
genau 3 (in Worten: drei) Testfälle, von denen 2 den vielversprechenden 
Namen "trivial.c" haben. Nix mit SFRs oder Interrupts oder was zur 
Laufzeit target-spezifisch wäre, noch nichmal zur Compilezeit: 
_attribute_? Fehlanzeige.

> Keine Ahnung, wie weit Eric mit diesem Ansinnen mittlerweile vorwärts
> kommen konnte.  Ein Opensource-Simulator wird halt für Atmel keine
> große Priorität genießen (sprich: kaum bezahlte man power locker
> machen), weil die sich natürlich hinstellen: "AVR Studio hat doch
> einen prima Simulator, wofür sollten wir einen zweiten bezahlen?"

Hehe, Atmel macht astudio als gdb-server übers Netz verfügbar :-)

>> D.h. Eric muss ab irgendeinem
>> Zeitpunkt anfangen, alle Patches, die auf dem besagten PR sind zu
>> portieren, und sozusagen mitten aus dem Stapel ein Patch rausziehen.
>
> Ja, das ist so.  Lässt sich derzeit nicht ändern, hat aber seit Jahren
> nun bereits nicht zu einem fork geführt [...]

Ok, man wird sehen, was die Zukunft bringt... Wieso bereits?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Hä? Da wär doch nur nen anderer Pfad anzugeben bei der "Installation"
> bzw. dem Aufruf. Für ne "Installation" bräuchte man nurn Archiv zu
> entpacken und das wars, ...

Ach, das fasst doch kein Windows-Nutzer an.  Man müsste doch
automatisch $PATH ändern etc. pp., und man braucht ein schickes Tool
mit der Auswahl.  Hast du jemals einen Windows Installer für irgendwas
geschrieben?  Ich nicht, aber ich würde auch freiwillig keinen schreiben
wollen.

Falls man die Entscheidung in AVR Studio machen können soll (ist ja
schließlich deren IDE), dann müsste man wohl dort noch eine Mimik
einbauen, wie man unterschiedliche Compiler aufrufen kann (PATH ändern
oder epxlizit aufrufen).

> das ganze Registry-Geraffel ist doch nur, damit
> astudio den gcc findet (denk ich mal, verwende kein astudio).

Meiner Meinung nach ersetzt das die unter Unix typischen festen (via
--prefix bei ./configure eingebauten) Pfade für die Komponenten (also
cpp, cc1 etc.).  Ich hatte da irgendwann mal reingeguckt, ich glaube,
da gibt's zumindest schon eine Versionierung, d. h. man könnte mehrere
verschiedene GCC-Versionen parallel installieren.

Das Problem dabei ist, dass du für derartige Mimiken bei Entscheidern
wohl keine Zeit locker gemacht bekommst, weil sie darin keinen
Mehrwert sehen.  Wenn Eric sowas während seiner Arbeitszeit einbauen
wöllte, müsste er also wohl erstmal genügend Motive vorweisen können,
warum das gut ist und gebraucht wird.

> Stop. Mal ganz langsam und von vorne. Ein FSF-CA genügt nicht ?
> Braucht man da noch svn write access? Dachte immer das geht so:
> patch->review->maintainer macht den svn-kram.

Maintainer muss halt auch Zeit haben dafür, den SVN-Kram zu machen.

Ich glaube, Eric ist mittlerweile Co-Maintainer, insofern müsste er
den AVR betreffende Dinge auch selbst ins SVN schreiben können.  So
ganz genau kenne ich mich damit aber auch nicht aus, da ich noch nie
selbst in dieser Verlegenheit war ;-) (und sicher auch nicht kommen
werde).  Da braucht er dann halt nur noch behördlicherseits eine
Bewilligung für die entsprechende Arbeitszeit...

> Ich hatte Eric schon gefragt, wie man ne Testumgebung (dejagnu)
> sinnigerweise aufsetzt. Keine Antwort.

Wird er auch noch nicht gemacht haben.  Ja, ich habe deine Frage
gelesen.

> Vemutlich ist da die Ansprüchlichkeit bei Atmel viel zu hoch. Ein
> Simulator für diesen Zweck braucht doch nicht die komplette (interne)
> Peripherie zu simulieren mit allen Weiß-der-Teufel-was-für-Features.

Ist ihm schon klar, und es gibt wohl auch einen einfachen Simulator
für ebendiesen Zweck bereits.  Keine Ahnung, ob der schon komplett und
bugfrei genug ist, dass man ihn auch auf nicht-AVR-Entwickler
loslassen kann.

> Hehe, Atmel macht astudio als gdb-server übers Netz verfügbar :-)

Wäre auch mal eine Idee. ;-)  Das wird vermutlich dann wieder an
irgendeiner IT-Abteilung scheitern...

Autor: MR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ein Simulator für den Kern reicht doch

Müßte der "stand-alone" sein? Es gibt ja inzwischen auch noch den in GDB 
integrierten Simulator (zumindestens in der GDB-Version, die Adacore als 
Bestandteil von Gnat GPL 2010 verteilt. Keine Ahnung, ob der in dem 
"offiziellen" GDB inzwischen auch drin ist).

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MR schrieb:
>> Ein Simulator für den Kern reicht doch
>
> Müßte der "stand-alone" sein? Es gibt ja inzwischen auch noch den in GDB
> integrierten Simulator

Da hab' ich keine Ahnung.

Autor: MR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MR schrieb:
> Es gibt ja inzwischen auch noch den in GDB
> integrierten Simulator (zumindestens in der GDB-Version, die Adacore als
> Bestandteil von Gnat GPL 2010 verteilt. Keine Ahnung, ob der in dem
> "offiziellen" GDB inzwischen auch drin ist).

Ich habe jetzt mal in den letzten GDB-Versionen nachgesehen: Ein 
AVR-Simulator ("target sim") ist seit Version in 7.0 in GDB enthalten...

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MR schrieb:
>> Ein Simulator für den Kern reicht doch
>
> Müßte der "stand-alone" sein?

Nö, das nicht. Aber Testsuite-Ergebnisse sollten untereinander 
vergleichbar sein. Wenn unterschiedliche Simulatoren unterschiedliche 
Ergebnisse liefern (zB weil einer ein bestimmtes SFR unterstützt, ein 
anderer jedoch nicht), dann sind Testsuite-Ergebnisse schlecht, d.h. nur 
nur erhöhtem Zeitaufwand vergleichbar.

Daher ist es vorteilhaft, einen "Standard"-AVR-Simulator zu haben, auch 
wenn dieser evtl. hinter einem anderern Simulator zurückliegt. Ein 
Vergleich der Testsuite-Ergebnisse ist dann i.W. ein diff auf die 
Ausgabe.

Zudem: GCC-Entwicklung geschieht unter Linux, ein Simulator, der nur in 
Nicht-Linux-Umgebung funktioniert, bedeutet ebenfalls Aufwand.

Und alles, was Atmel an Aufwand externalisiert (etwa einen Sim nur für 
Win32 zu machen, der nicht unter Linux läuft), verlangsamt die 
Entwicklungsprozesse spürbar, weil die meisten avr-tools Entwickler die 
Entwicklung in der Freizeit machen (oder eben bei Atmel sitzen und wegen 
nicht-vorhandenem Copyright-Assignment nix zur Entwicklung beitragen 
können bzw. dürfen).

Übrigens ist "die Testsuite" Teil von GCC, d.h. ein Entwickler ohne 
FSF-Assignment kann noch nichtmal ein Testprogramm zur Testsuite 
hinzufügen.
Möglicherweise gibt es auch andere Testsuites, die auf C für AVR zielen, 
zB welche von IAR, Adacore, etc.

MR schrieb:
> MR schrieb:
>> Es gibt ja inzwischen auch noch den in GDB
>> integrierten Simulator (zumindestens in der GDB-Version, die Adacore als
>> Bestandteil von Gnat GPL 2010 verteilt. Keine Ahnung, ob der in dem
>> "offiziellen" GDB inzwischen auch drin ist).
>
> Ich habe jetzt mal in den letzten GDB-Versionen nachgesehen: Ein
> AVR-Simulator ("target sim") ist seit Version in 7.0 in GDB enthalten...

Momentan hab ich leider nicht die Resource, das mal näher anzuschauen 
oder irgendwas zu avr-gcc beizutragen...

"target sim" bedeutet, daß es ein Protokoll zum Reden mit einem 
Simulator gibt -- das kann ein Pseudo-Protokoll sein, das auf einen 
integrierten Simulator abbildet oder ein tatsächliches Protokoll, das 
ein definiertes Protokoll zu einem bestimmten Simulator implementiert.
Letzteres wäre eine Arbeitsweise ähnlich zu AVR-Studio, das "nur" eine 
Schnittstelle zu einem C-Compiler (avr-gcc) hat, selbst aber keinen 
C-Compiler implementiert.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn ich früher(tm) mal gesagt hab, GCC ist kaum mehr zu pflegender 
Clusterf*ck in Reinkultur, und die FSF dreht hier und da recht 
aktionistisch am Rad, hat man mich schief angeschaut...

Ich hab auch schon mal versucht, irgendein kleineres Problem "im GCC" 
aufzuspüren und zu beheben. Danach hab ich voll und ganz verstanden, 
wieso Entwickler so rar sind und, salopp gesagt, kein Schwein Bock hat, 
sich in den Clusterf*ck einzuarbeiten.

Wenn nicht schon so viele Mannstunden im GCC stecken würden, wärs 
vielleicht noch Zeit, woanders anzubauen. Vielleicht LLVM oder sowas.

Autor: jw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BTW, nachdem ich WinAVR gegen die Atmel Toolchain ausgetauscht habe, 
zeigt avr-objdump keine "Chip-Belegung in %" mehr an.
Liegt das an Atmel oder an mir?
Grüsse,
Jürgen

Autor: Richard G. (gggggg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte um Unterstützung !

Ich möchte das AVR studio4 gemeinsam mit dem AVR Dragon zum JTAG proggen 
(C/ASM) und debuggen eines ATmega169P verwenden.

1. Im Forum (fragt mich nicht welcher draht ;-) habe ich gelesen, dass 
die Atmel AVR Toolchain nicht alle Elemente/tools wie sie WinAVR hat, 
beinhaltet.
Nun bin ich als Neuling verwirrt ob ich nun winavr2010 oder die 
avr-toolchain-installer-3.0.0.240-win32.win32.x86 verwenden soll.

2. Weiters gibt es angeblich eine neuere Toolchain 
avr8-gnu-toolchain-3.1.0.206 
http://distribute.atmel.no/tools/avr32/beta/avr8-g..., 
die aber so nirgends gefunden habe...
Angeblich soll sie hieraus 
http://distribute.atmel.no/tools/avr32/beta/as4e-i... 
zu extrahieren sein ... für mich als Neuling jedenfalls nicht so ohne 
Weiteres ....

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Und wenn ich früher(tm) mal gesagt hab, GCC ist kaum mehr zu pflegender
> Clusterf*ck in Reinkultur, und die FSF dreht hier und da recht
> aktionistisch am Rad, hat man mich schief angeschaut...

Ja. GCC ist kein Ponyhof.

Die Komplexität und Allgemeinheit der Software findet eben Niederschlag 
in der Quelle. Paradoxerweise genügt die Quelle nicht, um ein wirklich 
gutes Verständis vom GCC zu bekommen. Hierzu ist auch lange 
Einarbeitung/Erfahrung nötig und die Möglichkeit, sich mit erfahrenen 
Entwicklern austauschen zu können.

Davon zu trennen ist die FSF. GCC ist nicht die FSF und die FSF ist 
nicht GCC. Jeder, der irgendeine Ausprägung von GCC oder von Linux 
verwendet -- ob direkt auf seinem Rechner oder via Server im Internet -- 
profitiert von GCC und von seiner freien, aber auch sehr strikten 
Lizenz. Freilich braucht man etwas Sitzfleisch um erst mal rein formal 
beim GCC mitspielen zu dürfen. Zumindest war das bei mir der Fall.

Und der Entwicklungsprozess ist eben auch mit Aufwand verbunden. Ich 
glaube aber nicht, daß es ohne Richtlinien möglich ist, ein so großes 
Projekt erfolgreich übers Internet zu entwickeln. In meinem Job würd ich 
an vielen Stellen die Stringenz von z.B. GCC dem "Wildwuchs der kurzen 
Wege" vorziehen, auch wenn es die "eigentliche" Arbeit verlangsamt.

> Ich hab auch schon mal versucht, irgendein kleineres Problem "im GCC"
> aufzuspüren und zu beheben. Danach hab ich voll und ganz verstanden,
> wieso Entwickler so rar sind und, salopp gesagt, kein Schwein Bock hat,
> sich in den Clusterf*ck einzuarbeiten.

Ja, es ist ne Ochsentour. Kein Ponyhof eben. Aber ich denke, es kann 
auch Spaß machen, was beizutragen. Die Tage hab ich meine ersten 
einfachen Patches abgesetzt und bin gespannt, wie es denen ergehen wird 
:-)

> Wenn nicht schon so viele Mannstunden im GCC stecken würden, wärs
> vielleicht noch Zeit, woanders anzubauen. Vielleicht LLVM oder sowas.

LLVM hat doch auch ein AVR-Backend (oder wie auch immer die dortige 
Diktion ist) an welchem man mitarbeiten kann.

Und ob LLVM, wenn er das Alter -- also weit über 20 Jahre -- und die 
Allgemeinheit von GCC erreicht hat (unterstützte Maschinen und Derivate, 
Plattformen und Sprachen, Plugins, Debug-Möglichkeiten, 
Maschinenbeschreibung, etc.) immer noch so unbeschwert daherkommt wie 
heute, sei mal dahingestellt.

Was GCC 4 angeht, kann ich nur sagen, daß die Internals, also die 
Dokumentation, viel näher an der Funktionalität und vollständiger ist 
als dies noch bei GCC 3 der Fall war, und daß es viele Erweiterungen 
gibt, die eine Maschinenbeschreibung wesentlich übersichtlicher machen.

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richard G. schrieb:
> Bitte um Unterstützung !
>
> Ich möchte das AVR studio4 gemeinsam mit dem AVR Dragon zum JTAG proggen
> (C/ASM) und debuggen eines ATmega169P verwenden.
>
> 1. Im Forum (fragt mich nicht welcher draht ;-) habe ich gelesen, dass
> die Atmel AVR Toolchain nicht alle Elemente/tools wie sie WinAVR hat,
> beinhaltet.
> Nun bin ich als Neuling verwirrt ob ich nun winavr2010 oder die
> avr-toolchain-installer-3.0.0.240-win32.win32.x86 verwenden soll.
>

Wenn du AVR Studio benutzen willst, brauchst du kein WinAVR mehr, 
allerdings die Toolchain schon. Dazu also Toolchain fürs Studio laden 
und installieren (siehe Seite von AVR Studio 4 auf Atmel), dann das 
Studio installieren. In der aktuellen Version wüsste ich jetzt nicht was 
du großes vermissen würdest, du kannst dort in C bauen, proggen, und 
simulieren. Das ganze Betazeugs würd ich garnicht erst anfassen, bevor 
nicht irgendein Bug oder Problem oder Unzulänglichkeit im offiziellen 
Release dir einen konkreten Grund gibt.

Zumal der Link den du unten angabst in einem Fall schon ein Jahr alt 
ist, und im zweiten Fall sich auf das AVR32 Studio bezieht, nicht AVR 
Studio 4.

Hier findet sich alles was du brauchst:

http://www.atmel.com/dyn/products/tools_card.asp?t...

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moritz E. schrieb:
> Richard G. schrieb:
>> Bitte um Unterstützung !
>>
>> Ich möchte das AVR studio4 gemeinsam mit dem AVR Dragon zum JTAG proggen
>> (C/ASM) und debuggen eines ATmega169P verwenden.
>>
>> 1. Im Forum (fragt mich nicht welcher draht ;-) habe ich gelesen, dass
>> die Atmel AVR Toolchain nicht alle Elemente/tools wie sie WinAVR hat,
>> beinhaltet.
>> Nun bin ich als Neuling verwirrt ob ich nun winavr2010 oder die
>> avr-toolchain-installer-3.0.0.240-win32.win32.x86 verwenden soll.
>>
>
> Wenn du AVR Studio benutzen willst, brauchst du kein WinAVR mehr,
> allerdings die Toolchain schon. Dazu also Toolchain fürs Studio laden
> und installieren (siehe Seite von AVR Studio 4 auf Atmel), dann das
> Studio installieren. In der aktuellen Version wüsste ich jetzt nicht was
> du großes vermissen würdest, du kannst dort in C bauen, proggen, und
> simulieren. Das ganze Betazeugs würd ich garnicht erst anfassen, bevor
> nicht irgendein Bug oder Problem oder Unzulänglichkeit im offiziellen
> Release dir einen konkreten Grund gibt.

Die Atmel-Toolchain würde ich mit Vorsicht geniessen; Atmel scheint den 
Fokus eher auf neue Features zu legen als auf das Beheben von Fehlern.

Mit der lezten Version von WinAVR sollte man gut versorgt sein, die 
Priorität würde ich nicht beim "Alter der Toolchain" oder "Aler von 
Links" festmachen.

Gleich, welche Version von avr-gcc man verwendet (WinAVR, Atmel-Tools, 
Linux-Distribution, eigene Builds), sollte man zwei Dinge beachten

1. -fno-split-wide-types zu den Compileroptionen hinzufügen, auch wenn
   das hie und da etwas schlechteren Code gibt.
2. Keine 64-Bit Typen wie long long oder [u]int64_t verwenden.

Hier kann es zu schwer auffindbaren und schwer zu lokalisierenden 
Fehlern kommen, d.h. es wird falscher Code erzeugt -- auch mit 
gepatchten Versionen wie WinAVR! Jeder, der mit avr-gcc arbeitet, sollte 
diese beiden Punkte beherzigen.

Zum Glück werden 64-Bit Typen recht selten verwendet, und eine Option 
wie -fno-split-wide-types zu setzen ist kein Aufwand.

> Zumal der Link den du unten angabst in einem Fall schon ein Jahr alt
> ist, und im zweiten Fall sich auf das AVR32 Studio bezieht, nicht AVR
> Studio 4.

AVR32-Studio bringt nach der Atmel-Website auch AVR-Tools mit. Wobei ich 
nicht nachvollziehen kann, warum man AVR mit AVR32 verbäckt, was ja 
bereits bei jüngeren Releases won WinAVR der Fall war.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Die Atmel-Toolchain würde ich mit Vorsicht geniessen; Atmel scheint den
> Fokus eher auf neue Features zu legen als auf das Beheben von Fehlern.

Naja, das kannste so auch nicht sagen.  Der sagenumwobene Bug mit
dem delay.h geht nun nicht auf deren Konto, das wäre mit der
nächsten WinAVR-Version (wenn es sie gegeben hätte) ganz genauso
passiert.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Die Atmel-Toolchain würde ich mit Vorsicht geniessen; Atmel scheint den
>> Fokus eher auf neue Features zu legen als auf das Beheben von Fehlern.
>
> Naja, das kannste so auch nicht sagen.  Der sagenumwobene Bug mit
> dem delay.h geht nun nicht auf deren Konto, das wäre mit der
> nächsten WinAVR-Version (wenn es sie gegeben hätte) ganz genauso
> passiert.

hmmm... ich bin da vielleicht zu sehr auf den Compiler fixiert. Fehler 
in der delay.h finde ich nicht sooo schlimm. Es ist ja ein leichtes, die 
Datei gegen eine funktionierende Auszutauschen. Das Problem ist eher, 
überhaupt mitzubekommen, daß die delay.h buggy ist.

Mit dem 64-Bit Problem ist das nicht so einfach: hier reicht es nicht, 
eine Datei auszutauschen oder auf eine andere Compiler-Version zu 
wechseln. Mir ist erst die Tage klar geworden, daß 64-Bit auf avr-gcc 
überhaupt nicht zuverlässig funktionieren kann und ich hab keine Idee, 
wie das Problem aus der Welt geräumt werden kann. long long finden zwar 
keine so große Verwendung, aber hier gibt es ja auch einen 
Image-Schaden, wenn gewisse Basistypen überhaupt nicht verwendbar sind.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Mir ist erst die Tage klar geworden, daß 64-Bit auf avr-gcc
> überhaupt nicht zuverlässig funktionieren kann und ich hab keine Idee,
> wie das Problem aus der Welt geräumt werden kann.

Ich glaube, ich habe da auch seit Urzeiten noch einen Bug offen dafür.

Autor: Kai S. (zigzeg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Jörg Wunsch schrieb:

> wechseln. Mir ist erst die Tage klar geworden, daß 64-Bit auf avr-gcc
> überhaupt nicht zuverlässig funktionieren kann und ich hab keine Idee,
> wie das Problem aus der Welt geräumt werden kann. long long finden zwar
> keine so große Verwendung, aber hier gibt es ja auch einen
> Image-Schaden, wenn gewisse Basistypen überhaupt nicht verwendbar sind.

Nun bin ich neugierig: Kannst Du kurz beschreiben, warum 64 bit nicht 
funktionieren kann ? Oder wo man mehr info darueber finden kann ?

Danke,
ZigZeg

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai S. schrieb:
> Johann L. schrieb:
>> Jörg Wunsch schrieb:
>
>> wechseln. Mir ist erst die Tage klar geworden, daß 64-Bit auf avr-gcc
>> überhaupt nicht zuverlässig funktionieren kann und ich hab keine Idee,
>> wie das Problem aus der Welt geräumt werden kann. long long finden zwar
>> keine so große Verwendung, aber hier gibt es ja auch einen
>> Image-Schaden, wenn gewisse Basistypen überhaupt nicht verwendbar sind.
>
> Nun bin ich neugierig: Kannst Du kurz beschreiben, warum 64 bit nicht
> funktionieren kann ? Oder wo man mehr info darueber finden kann ?

Momentan hab ich da noch Klärungsbedarf mit anderen gcc-Entwicklern 
bezüglich der Semantik bestimmter internet GCC-Konstrukte.

Ich bin dabei die Bugliste durchzugehen und Fehler nachzuvollziehen und 
zu lokalisieren und zu fixen falls sie im AVR-Teil sind. Es sieht nun so 
aus, daß einige Fehler, die gegen das avr-Backend gemeldet wurden, 
tatsächlich Probleme im maschinenunabhängigen Teil sind, die sich nicht 
einfach beheben lassen. Das alles ist für 32-Bit-Maschinen kein Thema, 
und daher dort auch nicht aufgetreten bzw. aufgefallen. In ein paar 
Tagen weiß ich hoffentlich mehr und kann das alles besser bewerten. 
Zumindest sind PR45291 und PR46779 keine Fehler in der 
AVR-Maschinenbeschreibung.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Das alles ist für 32-Bit-Maschinen kein Thema,
> und daher dort auch nicht aufgetreten bzw. aufgefallen.

Zu GCCs Rechtfertigung muss man dabei natürlich einwenden, dass
dieser seinerzeit mal angetreten war, auf beliebige 32-bit-CPUs
portabel zu sein.  Dass man ihn überhaupt (und das doch noch recht
sinnvoll) auf einer 8-bit-CPU als Ziel zum Arbeiten bekommt, ist
in diesem Lichte eigentlich schon eine große Leistung.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Das alles ist für 32-Bit-Maschinen kein Thema,
>> und daher dort auch nicht aufgetreten bzw. aufgefallen.
>
> Zu GCCs Rechtfertigung muss man dabei natürlich einwenden, dass
> dieser seinerzeit mal angetreten war, auf beliebige 32-bit-CPUs
> portabel zu sein.  Dass man ihn überhaupt (und das doch noch recht
> sinnvoll) auf einer 8-bit-CPU als Ziel zum Arbeiten bekommt, ist
> in diesem Lichte eigentlich schon eine große Leistung.

Im konkreten Fall hängt es davon ab, was ein "word" ist... Ich hoffe 
mal, daß in dem o.g. Zusammenhang 8 Bits gemeint sind.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Jörg Wunsch schrieb:
>> Johann L. schrieb:
>>> Das alles ist für 32-Bit-Maschinen kein Thema,
>>> und daher dort auch nicht aufgetreten bzw. aufgefallen.
>>
>> Zu GCCs Rechtfertigung muss man dabei natürlich einwenden, dass
>> dieser seinerzeit mal angetreten war, auf beliebige 32-bit-CPUs
>> portabel zu sein.  Dass man ihn überhaupt (und das doch noch recht
>> sinnvoll) auf einer 8-bit-CPU als Ziel zum Arbeiten bekommt, ist
>> in diesem Lichte eigentlich schon eine große Leistung.
>
> Im konkreten Fall hängt es davon ab, was ein "word" ist... Ich hoffe
> mal, daß in dem o.g. Zusammenhang 8 Bits gemeint sind.

So, ich hab's abgeklärt. Für 64-Bit Typen gibt's Entwarnung :-))

Für das -fsplit-wide-types (das standardmässig für Optimierung > O1 
gesetzt ist), leider noch nicht. Wobei das Problem erst in einem 
späteren Pass ist, der sich am mit -fsplit-wide-types erzeugten Code 
verschluckt.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:

> Erics Ziel seit langem ist es, einen Simulator so verfügbar zu haben,
> dass ihn jeder X-beliebige GCC-Entwickler bei sich installieren und
> damit das AVR-Target testen kann.  Erst dann wäre er in der Lage, den
> AVR als "2nd tier"-Target aufwerten zu lassen, sodass er stärker in
> automatisierten Tests aufschlägt, was wiederum "lack of optimization"
> Fehler den GCC-Entwicklern früher gewahr machen würde.  Bislang drehen
> praktisch all diese Dinge erst eine komplette Runde über einen "mature
> release" zu den Anwendern, und von da zurück als PR.


MR schrieb:

> Ich habe jetzt mal in den letzten GDB-Versionen nachgesehen: Ein
> AVR-Simulator ("target sim") ist seit Version in 7.0 in GDB enthalten...

Ich hab avr-gdb 7.2 angetestet: Funktioniert out of the Box, zumindest 
für einzelne Programme. Damit gibe es doch einen Brauchbaren Simulator, 
der zudem noch einfach enzuwenden ist. Leider finde ich keine Doku, was 
alles (nicht) unterstützt wird und in welchem Zustand der Simulator ist.

Das einzige was fehlt, ist eine brauchbare Implementierung von _exit 
(macht momentan CLI+Endlosschleife, in libgcc) und abort (springt zu 
_exit, aus avr-libc.)

D.h. man müsste _exit ändern, abort in der libgcc implementieren und es 
in beiden irgendwie schaffen, den Simulator anhalten zu lassen, falls es 
kein BREAK gibt. Illegal Opcode ist hässlich und führ bei reales 
Programmausführung zu undefiniertem Verhalten :-(

Vielleicht kamm man auch in den Sim was einbauen, daß er bei einer 
"sinnlosen" Sequenz wie CLI CLH CLH CLH stoppt.

Notfalls müsste man die Testsuite auf ATmega128 oder so festnageln, wo 
es ein BREAK gibt.

Autor: Richard G. (gggggg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Die Atmel-Toolchain würde ich mit Vorsicht geniessen; Atmel scheint den
> Fokus eher auf neue Features zu legen als auf das Beheben von Fehlern.
> Mit der lezten Version von WinAVR sollte man gut versorgt sein, die
> Priorität würde ich nicht beim "Alter der Toolchain" oder "Aler von
> Links" festmachen.

> Gleich, welche Version von avr-gcc man verwendet (WinAVR, Atmel-Tools,
> Linux-Distribution, eigene Builds), sollte man zwei Dinge beachten
> 1. -fno-split-wide-types zu den Compileroptionen hinzufügen, auch wenn
>    das hie und da etwas schlechteren Code gibt.
> 2. Keine 64-Bit Typen wie long long oder [u]int64_t verwenden.

> Hier kann es zu schwer auffindbaren und schwer zu lokalisierenden
> Fehlern kommen, d.h. es wird falscher Code erzeugt -- auch mit
> gepatchten Versionen wie WinAVR! Jeder, der mit avr-gcc arbeitet, sollte
> diese beiden Punkte beherzigen.
>
> Zum Glück werden 64-Bit Typen recht selten verwendet, und eine Option
> wie -fno-split-wide-types zu setzen ist kein Aufwand.

> AVR32-Studio bringt nach der Atmel-Website auch AVR-Tools mit. Wobei ich
> nicht nachvollziehen kann, warum man AVR mit AVR32 verbäckt, was ja
> bereits bei jüngeren Releases won WinAVR der Fall war.

Vielen Dank für eure Infos... werde dann bei der WinAVR2010 Toolchain 
bleiben.
Aus der Unwissenheit heraus gefragt ... Würde es Sinn machen nur einen 
aktuelleren Compiler bzw. GCC einzusetzen. Ich habe allerdings trotz 
Hinweise auf der GCC-Webpage keine GCC binaries für Windoof gefunden...

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richard G. schrieb:

> Vielen Dank für eure Infos... werde dann bei der WinAVR2010 Toolchain
> bleiben.
> Aus der Unwissenheit heraus gefragt ... Würde es Sinn machen nur einen
> aktuelleren Compiler bzw. GCC einzusetzen. Ich habe allerdings trotz
> Hinweise auf der GCC-Webpage keine GCC binaries für Windoof gefunden...

http://sourceforge.net/projects/winavr/files/WinAVR/

Die WinAVR-20100110 ist wohl die am häufigsten eingesetzte Version von 
WinAVR. Auch wenn es gegen diese Version noch Bugreports gibt, so 
scheinen die in der Praxis nur sehr selten zuzuschlagen. Ansonsten 
würden sich hier die Beschwerden garantiert häufen ;-)

Um ne neuere Version zu erhalten, müsstest du die selber generieren...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Die WinAVR-20100110 ist wohl die am häufigsten eingesetzte Version von
> WinAVR. Auch wenn es gegen diese Version noch Bugreports gibt, so
> scheinen die in der Praxis nur sehr selten zuzuschlagen. Ansonsten
> würden sich hier die Beschwerden garantiert häufen ;-)

Moment mal, hat Eric nicht die ganzen Tracker zugemacht, sodass man
keine neue mehr posten kann?

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> 1. -fno-split-wide-types zu den Compileroptionen hinzufügen, auch wenn
>    das hie und da etwas schlechteren Code gibt.
> 2. Keine 64-Bit Typen wie long long oder [u]int64_t verwenden.

kann bitte jemand die beiden Probleme noch mal erläutern?
(bzw warum Entwarnung)

Johann L. schrieb:
> So, ich hab's abgeklärt. Für 64-Bit Typen gibt's Entwarnung :-))

hängt das zweite mit dem ersten zusammen?
wass muss ich tun, wenn ich doch uint64_t verwenden will? eigene 
Operationen schreiben?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> Johann L. schrieb:
>> 1. -fno-split-wide-types zu den Compileroptionen hinzufügen, auch wenn
>>    das hie und da etwas schlechteren Code gibt.
>> 2. Keine 64-Bit Typen wie long long oder [u]int64_t verwenden.
>
> kann bitte jemand die beiden Probleme noch mal erläutern?
> (bzw warum Entwarnung)

1. -fsplit-wide-types bewirkt ein s.g. Subreg-Lowering, d.h. es wird 
versucht, größere Datentypen wie DI (64-Bit), SI (32-Bit) oder HI 
(16-Bit) in Maschinenworte, also QI (8-Bit), zu zerbröseln. Dagegen ist 
zunächst nix einzuwenden. Aufgrund älterer, fragwürdiger Patches darf 
Y-Reg keine QI speichern, was schliesslich dazu führt, daß es in 
seltenen Fällen zu falschem Code kommt. Nämlich eben dann, wenn der 
Register-Allokator ein QI-Stückchen nach Y allokieren will. In dem Falle 
wird das erste QI-Stückchen überschrieben, weil der Allokator einen 
16-Bit Zugriff macht (andere sind ja nicht erlaubt). Mit 
-fno-split-wide-types werden weniger solcher QI-Schnipsel erzeugt als 
mit -fsplit-wide-types (default). Allerdings verbleiben andere Stellen, 
die QIs erzeugen wie in http://gcc.gnu.org/PR41894 Auch da soll ein QI 
nach Y gespeichert werden.

2. beruhte auf einer Unklarheit in der internen GCC-Doku, die aber 
inzwischen geklärt ist.

> Johann L. schrieb:
>> So, ich hab's abgeklärt. Für 64-Bit Typen gibt's Entwarnung :-))

2. ist kein Problem und hat nix mit 1. zu tun.

64-Bit-Typen können problemlos verwendet werden -- zumindest was die 
Korrektheit des Codes angeht. Die Effizienz von DI ist nicht dolle, und 
daran wird sich in näherer Zukunft auch kaum was ändern. Zumindest ich 
hab nicht vor, eine Unterstützung für DI zu schreiben. Das ist tierisch 
viel Arbeit (auch das Testen), fehleranfällig, und DI wird sehr selten 
in AVR-Anwendungen verwendet (zumindest ist das mein Eindruck) und 
avr-gcc hat momentan andere Probleme als eine effizientere 
DI-Implementierung.

> hängt das zweite mit dem ersten zusammen?

Nein.

> wass muss ich tun, wenn ich doch uint64_t verwenden will? eigene
> Operationen schreiben?

Nein.

Jörg Wunsch schrieb:
> Johann L. schrieb:
>
>> Die WinAVR-20100110 ist wohl die am häufigsten eingesetzte Version von
>> WinAVR. Auch wenn es gegen diese Version noch Bugreports gibt, so
>> scheinen die in der Praxis nur sehr selten zuzuschlagen. Ansonsten
>> würden sich hier die Beschwerden garantiert häufen ;-)
>
> Moment mal, hat Eric nicht die ganzen Tracker zugemacht, sodass man
> keine neue mehr posten kann?

Keine Ahnung. Ich poste Fehler gegen den jeweiligen primus motor ;-) 
also gcc, binutils, etc.

Jedenfalls gibt es nicht für alle Bugs Patches (s.o.). Wie es mit 
Linux-Distributionen aussieht weiß ich net. In WinAVR-20100110 gibt es 
ca. 20 Patches (einige davon sind "nur" Erweiterungen für Ada oder so), 
also deutlich weniger als die etwas längere Bugliste von avr-gcc [1]:

Wie ist die avr-libc Liste [2] eigentlich entstanden? Scheint nur ein 
copy & paste aus den Origninal-Bugzillas zu sein. Oder wird die 
automatisch generiert? Jedenfalls ist http://sourceware.org/PR12494 
nicht drinne. Also handgeklöppelt?

Johann

--

[1]
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status...

[2]
http://www.nongnu.org/avr-libc/bugs.html

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> [...]

Danke für die Erklärungen.

Also kann man ohne Bedenken (abgesehen von Effizienz) 64bit-Berechnungen 
durchführen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Wie ist die avr-libc Liste [2] eigentlich entstanden? Scheint nur ein
> copy & paste aus den Origninal-Bugzillas zu sein.

Ja, die hat Eric wohl mit der Hand gepflegt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:

> . Aufwändige Patch-Suites wie Xmega oder mittlerweile wohl tiny10;
>   hier genügt es einfach mal nicht, dass man da eine GPL drüber
>   schreibt, sondern du hast wieder das gleiche Dilemma wie auch schon
>   beim AVR32: GCC besteht auf diesem blöden Copyright-Assignment, und
>   wenn Atmel das Copyright hält, weil der Patch in deren Auftrag und
>   mit deren Geld kreiert worden ist, dann bist du wieder bei der
>   Rechtsabteilung...

Gute Nachrichten: Eric hat vor einigen Stunden den Xmega-Patch in
die GCC-Codebasis eingepflegt.  Offenbar ist also der Segen von
Atmels Rechtsabteilung nun wirklich endlich amtlich.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:

> Gute Nachrichten: Eric hat vor einigen Stunden den Xmega-Patch in
> die GCC-Codebasis eingepflegt.

Sorry, hab' ich vermasselt.  Nicht GCC, sondern erstmal binutils.

>  Offenbar ist also der Segen von
> Atmels Rechtsabteilung nun wirklich endlich amtlich.

Das bleibt aber trotzdem richtig.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:

>> Gute Nachrichten: Eric hat vor einigen Stunden den Xmega-Patch in
>> die GCC-Codebasis eingepflegt.
>
> Sorry, hab' ich vermasselt.  Nicht GCC, sondern erstmal binutils.

Bei avr-gcc ist's auch am brodeln -- zumindest unter der Oberfläche. 
Eric ist dabei die builtin-Unterstützung vorzubereiten :-)
(Hatte schon in meinen Patches gekramt und überlegt die dortige 
Builtin-Unterstützung zu posten, weil ich das von Atmel nicht mehr 
erwartete)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guckguck.

Da WinAVR 20100110 jetzt mittlerweile auch gut 1,5 Jahre alt ist, wollte 
ich mal fragen, ob es schon weitere Fortschritte in der AVR-Toolchain zu 
verzeichnen gibt? Ich habe sie letztens mal drauf gehabt, aber WIMRE war 
der delay-bug immer noch vorhanden.

Auf mich macht es ein wenig den Eindruck eines toten Pferdes. Täuscht 
mich meine Wahrnehmung?

Werde ich wohl weiterhin den 20100110 benutzen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.