Bei der Suche nach den deb Paketen für den avr-gcc bin ich in dieser Datei über einen Hinweis gestolpert http://www.wrightflyer.co.uk/avr-gcc/avr-gcc-4.3.4-avrfreaks-30-apr-2010-u10.04.i386.txt Da steht drin > Thank you to Eric Weddington , for maintaining WinAVR , though it seems > like WinAVR-2010 will be the last one. Stimmt das? Ist das die Letzte WinAVR Version? Oder gibt es einen neuen Maintainer?
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.
Das ganze betrifft den avr-gcc ansich aber nicht, oder?
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.
Vielleicht sollte man einfach mal die AVR "Unterstützung" in Linux mal etwas forcieren. Speziell so Sachen wie Simulation sind doch eher nicht existent. Dinger wie Simulavr kann man nicht wirklich ernst nehmen
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...
Das man simulavr nicht mit dem AVR Studio vergleichen kann ist klar. aber es werden ja nichtmal alle Kerne unterstützt. Und was "man" tun kann tut "man" auch. Aber "man" hat auch nicht beliebig viel Zeit
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.
Jörg Wunsch schrieb: >> aber es werden ja nichtmal alle Kerne unterstützt. > > Naja, es fehlen vor allem die neueren: Xmega und Tiny10. naja, es dürfte auch ein kleines Problem sein, einen Mega328 auf einem Mega8 zu simulieren. Oder wie löst man das? > >> 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. Ich bin durchaus am 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?
Jörg Wunsch schrieb: > 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. Das die Peripherie problematisch ist weiß ist. Aber die Register sollten ja wohl am richtigen Fleck sein, sonst nutzt das nix. Oder wird das komplett ignoriert. > > Davon abgesehen, ein ATmega88 ist mittlerweile dabei, es sollte im > Zweifelsfalle also nicht viel Aufwand sein, daraus einen ATmega328 > zu clonen. Ok, das muss in der neuesten Version sein. Die ist noch nicht bei mir angekommen. > > 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? Herrje, in welche Wunde hab ich denn da Salz gestreut? Ich weiß doch, dass fast alles von Freiwilligen nach Feierabend gemacht wird. Und ich weiß wie schwer es ist, Leute für sowas zu mobilisieren. Das war auch nicht als Kritik an einzelnen gedacht. Auch nicht am gesamten.
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.
Atmel hat mit dem AVR Studio halt angefangen, als Linux noch völlig bedeutungslos war. Eine nachträgliche Portierung für Linux wäre aufwändig. Hab halt nach dem AVR32 Studio etwas gehofft, dass auch für normale AVR was in der Richtung kommt. Naja, werd mir bei Gelegenheit mal Simulavr ziehen und compilieren. Mal schauen
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
Es liegt daran, dass Atmel eigentlich nur Controller verkaufen will. Alles andere muss sich diesem Ziel unterordnen. Abwarten und Tee trinken. Meine persönlicher Erfahrung nach ist das Entwicklungskit mit dem eingebundenen GCC-Toolkit etwas altbacken. Das Atmel lieber eine IDE aus dem Hause IAR beim Kunden sehen würde, ist durchaus nachvollziehbar. Es soll jetzt nicht falsch Verstanden werden - Ich benutze WinAVR ebenfalls und habe schon ein paar Kleinigkeiten damit realisiert. Verglichen mit dem IAR-Kit ist Winavr und GCC rudimentär. 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.
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: > Mir auch. Ich will meine Freizeit auch nicht mit der Administration > irgendwelcher Virenscanner, Service Packs etc. verbringen. ;-) Na das war aber genau so schlecht getrollt ;-) Ich hab auf meinem PC in dem letzen 3 Jahren genau einmal einen Virenscanner und 1 Service Pack installiert.
Seit kurzem gibt es von Atmel die AVR Toolchain. Anscheinend entspricht das weitgehen WinAVR. Nur mfile + Tcl/Tk scheinen zu fehlen. Der gcc wurde auf v4.4.3 aktualisiert. AVR-Studio ab v4.18 SP3 unterstützt/findet die AVR Toolchain, kann aber auf WinAVR zurückfallen. Hier die Downloadlinks: http://www.atmel.com/forms/software_download.asp?family_id=607&fn=dl_avr-toolchain-installer-3.0.0.240-win32.win32.x86.exe Bzw. hier auch ohne Registrierung: http://www.atmel.no/beta_ware/
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).
Unter http://www.makehackvoid.com/group-projects/mhvavrtools bietet jemand einen Windows AVR-Toolchain auf Basis des GCC 4.5.1 an. Bisher war ich, auch wegen des ziemlich frischen GCCs, nicht motiviert, den Toolchain zu verwenden. Vielleicht traut sich jemand anders.
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 :-)
Bisher gab es leider keine neue Version und es sieht aktuell nicht danach aus.
Johann L. schrieb: > WinAVR wird fortgesetzt: Der Thread ist von Mai 2011 ..... ..... also wenn bis heute nichts gekommen ist .....
Win avr vielleicht nicht, aber die daraus abgeleitete Toolchain von Atmel schon.
@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).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.