WinAVR-2010 soll die letzte Version sein?

hmm...
hat mich auch gewundert was hier auch Jörg geschrieben hat (letzter 
Satz)

........... beim Herausbringen
eines neuen WinAVR (oder was auch immer dessen Nachfolger wird).

Beitrag "Re: Windows-Build von avr-gcc 4.5.0"

Eine schnelle Google-Suche ergab folgendes:
> I am pleased to announce that the GCC Steering Committee has
> appointed Eric Weddington as AVR co-maintainer.

Führt zu der Frage: Wie geht es mit WinAVR weiter?

mfG
Markus

Markus J. schrieb:
> Wie geht es mit WinAVR weiter?

Gar nicht, also nicht unter diesem Namen, wie's scheint.

Eric Weddington hat das doch seit einigen Jahren mittlerweile
dienstlich als Angestellter von Atmel auf dem Tisch liegen.  Als
solches wird er es mit seinem Team künftig nun nicht nur von Atmel
bezahlt herausbringen, sondern auch irgendwie unter dem Namen
"Atmel", auch wenn noch niemand bis jetzt Details der entsprechenden
Pläne öffentlich erfahren hat.

WinAVR selbst bestand ja im Wesentlichen aus zwei Dingen: dem Know-How,
wie man all die Tools unter Windows baut, sowie der Integration in
einen Windows-typischen Installer.  Das erste ist alles mehr oder
weniger gut dokumentiert worden, das zweite war nie wirklich Opensource,
sondern stets Eric's privates Ding.

Die eigentlichen Tools, die WinAVR zusammen packt, haben ja nur
mittelbar mit WinAVR selbst was zu tun, deren Entwicklung vollzieht
sich separat in ihren jeweiligen Opensource-Projekten (GCC, binutils,
avr-libc), teils natürlich unter Mitarbeit von sowohl Eric als auch
weiteren Atmel-Mitarbeitern, die er mittlerweile in seinem Team hat.
Wer einigermaßen aufmerksam die avr-libc-Mailingliste verfolgt, dem
ist möglicherweise der Name Anitha Boyapati mal aufgefallen, die in
letzter Zeit sich auch mal um diverse kleinere Bugs gekümmert hat,
die oft längere Zeit liegen geblieben waren.

Lou Bega schrieb:
> Das ganze betrifft den avr-gcc ansich aber nicht, oder?

Höchstens insofern, dass WinAVR der wohl mit Abstand größte "Kunde"
von AVR-GCC geworden ist im Laufe der Jahre.

Deine allgemeinen Behauptungen nützen keinem was.  Das aktuelle
simulavr dürfte alles andere sein als "kann man nicht ernst nehmen".
Dass es sich nicht mit einem AVR Simulator V2 messen kann, der sein
komplettes Digitaldesign aus den IC-Entwurfsdaten beziehen darf, ist
keine Frage, aber derartigen Luxus haben ja wohl nicht einmal alle
AVRs.

Ansonsten scheitert Simulation jenseits trivialer Probleme in aller
Regel ganz schnell an der fehlenden Simulation der Umgebung des
Controllers.  Selbst in einem Hardware-Software-Co-Simulator wie
VMlab hat man es ziemlich schwer, viel mehr als vielleicht eine
einfache PWM zu simulieren.

Simulation taugt am besten zur Simulation reiner Algorithmen (und
Aufdeckung der entsprechenden algorithmischen Fehler), aber dafür
brauche ich keine ausgefeilte Peripherie-Simulation, da muss nur der
Prozessorkern ordentlich simuliert werden (und dann ist es fast wieder
egal, ob ich nur einen alten ATmega128 simulieren kann oder einen
neumodischen ATmega1284).

Wenn "man" hier etwas ändern "sollte", dann fasse "man" sich bitte an
die eigene Nase: Opensource-Projekte leben ausschließlich von
denjenigen, die etwas tun.  Nutzer, die das Ergebnis des Tuns dann
benutzen und neue Wünsche haben, finden sich immer ganz von allein...

Lou Bega schrieb:
> ...
> aber es werden ja nichtmal alle Kerne unterstützt.

Naja, es fehlen vor allem die neueren: Xmega und Tiny10.

> Und was "man" tun kann tut "man" auch. Aber "man" hat auch nicht
> beliebig viel Zeit

Ja, und bei wem willst du jetzt etwas "forcieren"?

Bitte begieb dich zurück auf den Boden der Realität.

Lou Bega schrieb:

> naja, es dürfte auch ein kleines Problem sein, einen Mega328 auf einem
> Mega8 zu simulieren. Oder wie löst man das?

Vom CPU-Kern her sind die gleich (und du schriebst etwas, dass nicht
alle "Kerne" simuliert würden)..  Nur die Peripherie unterscheidet
sich, aber s. o., alles, was draußen dran hängt, ist ohnehin immer
schwer zu simulieren.

Davon abgesehen, ein ATmega88 ist mittlerweile dabei, es sollte im
Zweifelsfalle also nicht viel Aufwand sein, daraus einen ATmega328
zu clonen.

> Ich bin durchaus am Boden der Realität.

Kannst mir jedoch die Frage nicht beantworten, wie "man" etwas
"forcieren" will, wenn "man" keine Zeit hat, was zu tun.  Ist dir
jemals der Gedanke gekommen, dass es den anderen "man" genauso gehen
könnte wie dir?

Lou Bega schrieb:

> Ok, das muss in der neuesten Version sein. Die ist noch nicht bei mir
> angekommen.

Ja, es gibt einfach noch keine "Version" davon, man muss sich das
derzeit direkt aus dem git holen.

Wenn du nur das uralte simulavr-0.1.x meinst, das gibt's eigentlich
nur noch, weil die Testsuite in der avr-libc dies benutzt (und auf
einigen sehr speziellen Features dabei aufsetzt).

> Ich weiß doch,
> dass fast alles von Freiwilligen nach Feierabend gemacht wird.

Nicht alles, wie ich oben schon schrieb (Atmel hat nun selbst einige
Leute, die da teilweise mitarbeiten), aber im Bereich der Simulation
halt schon.  Da hat Atmel kein weiteres Interesse, da aus deren Sicht
die Anwender mit dem Simulator von AVR Studio ausreichend bedient
sind.  Anwender, die nicht Windows benutzen oder denen vielleicht das
Design von AVR Studio hinten und vorn nicht gefällt, spielen derzeit
bei Atmel nur eine untergeordnete Rolle.

Lou Bega schrieb:
> Atmel hat mit dem AVR Studio halt angefangen, als Linux noch völlig
> bedeutungslos war.

Das ist, mit Verlaub, Quatsch.  Davon abgesehen, dass ich als FreeBSD-
Nutzer dem Linux-Hype seit jeher etwas abseits stand, im Jahr 2000
war dieser bereits in vollem Gange.  Es war die Zeit der großen
"new market"-Blasen, als Linus Torvalds damit noch reich werden konnte.

Spätestens beim völligen Rewrite namens AVR Studio 4 hätte man das
durchaus anfangen können, wenn man nur gewollt hätte.  Nein, die
Nutzer anderer Systeme als Windows wurden dort einfach ignoriert
seinerzeit, und selbst AVR-GCC wurde als Vehikel, um AVRs zu
verkaufen, erst einige Jahre später entdeckt (letztlich auch dank
Eric Weddingtons WinAVR-Portierung).  Anfangs hatte man voll und
ganz auf den Mercedes namens IAR gesetzt.

> Eine nachträgliche Portierung für Linux wäre
> aufwändig.

Klar, bei dem Design, kein Wunder.  Es gibt ja praktisch kein
Windows-API, was da nicht benutzt worden wäre...  Daher ist es ja
auch nicht ganz unaufwändig, es unter Wine zum Spielen zu bekommen
(gibt's aber wohl mittlerweile eine Anleitung dafür).

Ein Cross-Plattform-Ansatz wäre seinerzeit durchaus ebenso
praktikabel gewesen, Qt hatte beispielsweise bereits einige Jahre
auf dem Buckel, in denen es bewiesen hat, dafür tauglich zu sein.

(Das heißt nicht, dass sich nicht mittlerweile auch dort die
Ansichten geändert hätten, wie wir ja gut bei der Akzeptanz des
AVR-GCC sehen oder durch die Tatsache, dass Eric nun seit einigen
Jahren von Atmel bezahlt wird dafür.)

Jörg, herzlichen Dank für die Informationen, es ist gut zu wissen dass 
es weitergeht - ich bin ja einmal gespannt, wie Atmel das ganze in 
Zukunft gestaltet haben möchte.
Es wundert mich, dass diese Änderung einem Update auf der News-Seite von 
WinAVR nicht würdig war ...

Man kann euer Engagement gar nicht genug würdigen, danke euch allen die 
ihr die Entwicklung von avr-gcc (und den ganzen anderen Programmen 
"drumherum") vorantreibt!

mfG
Markus

GW; DD4DA schrieb:
> ...
> Um Atmel Controller programmieren zu können, möchte ich kein Linux
> benutzen müssen denn ich verfüge über nur begrenzte (Frei)Zeit die ich
> nicht mit der Linux-Administration und dem bauen von Makefiles
> verschwenden möchte. Gleiches gilt auch für eine Eclipse-Integration. Es
> ist nur "ein" Hobby.

Komisch, mir geht es genau andersrum: In der Firma "muss" ich Windows 
benutzen und ärgere mich andauernd darüber. Mittlerweile bin ich dort 
zum Programmieren auf avrdude umgestiegen, weil mich AVRStudio/avrprog 
einfach ankotzt (Stürzt mit dem JTAG ICE mkII immer mal wieder ab, 
unterstützt Batchprogramming nur bedingt, ...).
Auf jeden Fall kann ich jedem, der sich etwas mehr mir 
Computern/Programmierung befasst, wärmstens raten, sich auch mal etwas 
mit Linux auseinanderzusetzen.

GW; DD4DA schrieb:
> Um Atmel Controller programmieren zu können, möchte ich kein Linux
> benutzen müssen denn ich verfüge über nur begrenzte (Frei)Zeit die ich
> nicht mit der Linux-Administration und dem bauen von Makefiles
> verschwenden möchte. Gleiches gilt auch für eine Eclipse-Integration. Es
> ist nur "ein" Hobby.

Kann ich so nicht nachvollziehen, ich habe die IAR-IDE auch nie genutzt.
Deine Anmerkung zur Eclipse-Integration und Makefiles (habe ich bis dato 
nur einmal gebraucht, AVR-Eclipse sei dank) deckt sich nicht mit meinen 
Erfahrungen, und dass WinAVR kein Linux erfordert steckt schon im Namen 
...

mfG
Markus

Philipp Burch schrieb:
> Komisch, mir geht es genau andersrum

Mir auch.  Ich will meine Freizeit auch nicht mit der Administration
irgendwelcher Virenscanner, Service Packs etc. verbringen. ;-)

GW; DD4DA schrieb:
> Es liegt daran, dass Atmel eigentlich nur Controller verkaufen will.

Nicht nur diese, aber auch diese. ;-)  (Atmel verkauft ja noch mehr
als nur Controller.)  Es ist denen wohl aber klar, dass man Controller
nur dann verkaufen kann, wenn man sie auch programmieren kann.  Die
Zeiten, in denen man einfach mal annahm, dass sich jeder Kunde
ohnehin problemlos einen IAR hinstellen würde, sind mittlerweile
vorbei.  IAR baut gute Compiler, das ist außer Frage, aber es gibt
auch Gründe, warum man sowas nicht benutzen will:

. das ganze Lizenz-Getue ist ätzend; einen Build-Server damit
  aufsetzen, der regelmäßig mal alles compiliert, kann schnell
  zum Halbtagsjob werden

. der Preis ist nicht ganz unerheblich, insbesondere natürlich für
  Firmen mit weniger als 10000 Beschäftigten

. der Kram läuft nur auf Windows (obwohl das für den reinen Compiler
  technisch sicher nicht notwendig wäre, denn der muss weiter nichts
  als Dateien verarbeiten; ein Job, den man mit ANSI-C bereits portabel
  realisieren konnte)

Jörg Wunsch schrieb:
> Ich will meine Freizeit auch nicht mit der Administration
> irgendwelcher Virenscanner, Service Packs etc. verbringen. ;-)

Stimmt, da hast du auch keine Zeit für, weil du dir den Compiler, die 
Toolchain und weiteres Zubehör erstmal mühsam selber bauen mußt. Nicht 
mühsam? Ich lese viele Berichte, "ich bekomme die Toolchain nicht gebaut 
weil Script xy nicht tut". Und wenn das dann alles fertig ist, dann mußt 
du das auf einem anderen Rechner, wo wieder ein anderes Linux drauf 
läuft (ja, ich weiß daß du BSD nutzt :-) nochmal machen, weil das Zeugs 
nicht kompatibel ist. Ja das hat schon was und ist auch praktisch und 
spart Zeit ;-)

Ich finde den WinAVR so ein klasse Werkzeug, weil es auf Windows läuft.

So ich geh dann mal leise :-)

900ss D. schrieb:
> So ich geh dann mal leise :-)

Besser so, das war nämlich schlecht getrollt ... wenn ich noch Hoffnung 
für dich hätte würde ich dir ja Mal empfehlen eine moderne 
Linux-Distribution auszuprobieren aber da findest du mit Sicherheit eine 
Möglichkeit das ganze gegen die Wand zu fahren ...

Btw. Linux != Windows ...

mfG
Markus

Markus J. schrieb:
> 900ss D. schrieb:
>> So ich geh dann mal leise :-)
>
> Besser so, das war nämlich schlecht getrollt. ...

";-)" übersehen?

900ss D. schrieb:
> Stimmt, da hast du auch keine Zeit für, weil du dir den Compiler, die
> Toolchain und weiteres Zubehör erstmal mühsam selber bauen mußt.

Nee, du, ich lasse bauen. :-)

Jörg Wunsch schrieb:
> Nee, du, ich lasse bauen. :-)

grummel, "entwaffnet" :-)

Christoph H. schrieb:
> Nur mfile + Tcl/Tk scheinen zu fehlen.

Dann dürfte aber auch Insight fehlen, denn das war der ursprüngliche
Anlass, dass Tcl/Tk mit dabei waren (und der Grund, warum Mfile in
Tk geschrieben ist).

Christoph H. schrieb:
> Hier die Downloadlinks:
> http://www.atmel.com/forms/software_download.asp?f...
>
> Bzw. hier auch ohne Registrierung:
> http://www.atmel.no/beta_ware/

Über diese "offizielle" Seite

http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=13029&family_id=607

klappt der Download auch ohne Registrierung

http://www.atmel.com/dyn/resources/prod_documents/avr-toolchain-installer-3.0.0.240-win32.win32.x86.exe

Christian.

ich habe es nicht geschafft die atmel suchfunktion dazu zu bewegen den 
toolchain installer anzuzeigen ...

Jörg Wunsch schrieb:

> Wer einigermaßen aufmerksam die avr-libc-Mailingliste verfolgt, dem
> ist möglicherweise der Name Anitha Boyapati mal aufgefallen, die in

"die" oder "der"? da bin ich am rätseln. Rein statistisch würde ich auf 
"der" tippen, immerhin gibt es Anitha auch aln männlichen Vorname:

http://en.wikipedia.org/wiki/Anitha_R._Radhakrishnan

Johann L. schrieb:
> Jörg Wunsch schrieb:
>
>> Wer einigermaßen aufmerksam die avr-libc-Mailingliste verfolgt, dem
>> ist möglicherweise der Name Anitha Boyapati mal aufgefallen, die in
>
> "die" oder "der"?

Da Eric Weddington, der sie schon in Indien getroffen hat, über sie
als "she" schreibt, gehe ich davon aus, dass diese Information
authentisch ist. ;-)

Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Jörg Wunsch schrieb:
>>
>>> Wer einigermaßen aufmerksam die avr-libc-Mailingliste verfolgt, dem
>>> ist möglicherweise der Name Anitha Boyapati mal aufgefallen, die in
>>
>> "die" oder "der"?
>
> Da Eric Weddington, der sie schon in Indien getroffen hat, über sie
> als "she" schreibt, gehe ich davon aus, dass diese Information
> authentisch ist. ;-)

Ok, danke für die Klarstellung. Bei Vornamen aus anderen Kulturkreisen 
weiß man das ja nie genau, und mit der Aussage gibt's nen Fettnäpfchen 
weniger :-)

WinAVR wird fortgesetzt:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=107269

Win avr vielleicht nicht, aber die daraus abgeleitete Toolchain von 
Atmel schon.

Falk Brunner schrieb:
> daraus abgeleitete

Sehr wagemutige Behauptung. :-)

@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite

>> daraus abgeleitete

>Sehr wagemutige Behauptung. :-)

Ist das nicht so? Man findet die Doku der libc nahezu 1:1 bei Atmel, nur 
in etwas anderem Layout. Da lag der Schluß nahe. Trugschluß?

Falk Brunner schrieb:
> Trugschluß?

Ja.  Sowohl WinAVR als auch die Atmel-Toolchain sind natürlich von
den gleichen Projekten abgeleitet (binutils, GCC, avr-libc).