Moin Moin, Hab grad gesehen, dass es das AVR-Studio seit eben als Beta gibt. http://www.atmel.com/microsite/avr_studio_5/default.asp?source=cms&icn=hmap1-AVR_STUDIO&ici=mar_2011 Mal sehen wie's ist. Gruß Rob
Ich guck´s mir mal auf der 'embedded world' an, bevor ich hier ein halbes GiB durch die Leitung sauge...
It is based on Visual Studio 2010 shell[...] Hardware Requirements: • Computer that has a 1.6GHz or faster processor • 1 GB RAM for x86 • 2 GB RAM for x64 • An additional 512 MB RAM if running in a Virtual Machine • 3GB of available hard disk space • 5400 RPM hard disk drive • DirectX 9-capable video card that runs at 1024 x 768 or higher display resolution Klingt nach einem ganz schön großen Brocken. http://www.atmel.com/dyn/resources/prod_documents/release_note_as5.0.pdf
Für den gebotenen Funktionsumfang ist es eifnach zu groß und hat viel zu hohe Systemanforderungen. Die Eclipse IDE bietet denselben Funktionsumfang und ist wesentlich kleiner und genügsamer. Wieso hat man das AVR Studio nicht darauf aufgebaut statt auf Visual Studio 2010?
Deswegem vielleicht Beta-version. Vielleicht springen sie noch um bei genügend negativen Rückmeldungen. Hoffnung habe ich aber nicht wirklich.
Vielleicht ist das File auch einfach so groß weil 32 Bit UND 64 Bit (nativ) Version enthalten sind. Alleine die 64-Bit binaries sind ja ~30% größer als die 32 Bit binaries.
Naja, aber "3GB of available hard disk space" und "2 GB RAM for x64" sprechen auch schon für sich. In den Release Notes taucht übrigens mehrmals "JTAGICE 3" auf. Sieht so aus, als ob es dort bald einen neuen Debugger gibt. Weiß hier jemand mehr dazu?
Nachdem Atmel da ein Jahr oder länger dran gebastelt hat, werden die nichts mehr umstellen. Ich glaube, es war eine ganz bewusste Entscheidung allen Benutzern anderer Betriebssysteme mit diesem Frankenstein aus Visual Studio Shell mit .NET 4.0 in den Arsch zu treten. Atmel sagt damit, dass aus Sicht von Atmel * Nicht-Windows-User kein vernünftiges Debugging verdienen, * Nicht-Windows-User keine Dokumentation für Atmel-Tools verdienen * Nicht-Windows-User keine Firmware-Updates für Atmel-Tools verdienen * Nicht-Windows-User das ASF nicht verdienen (ok, ASF ist so schlecht, dass hat eigentlich niemand verdient :-)) Das ist eine klar kalkulierte Botschaft, dass Atmel nur "Profis" bedienen möchte, denn "Profis" verwenden natürlich alle Windows (ha, ha, ha) und der Rest geht Atmel am A... vorbei. Atmel möchte, dass sich die "Freaks" mit ihrem Linux gefälligst zum Teufel scheren. Gut, können sie haben. Es gibt genug preiswerte Alternativen.
Hallo zusammen, meiner Meinung nach kocht doch jeder Hersteller sein eigenes Süppchen, was die dazugehörige Entwicklungs-Umgebung angeht. Aber was ist letztendlich so schlimm daran, das sich ATMEL nur Windows als Background ausgesucht hat? Gruß Norbert
Norbert schrieb: > Hallo zusammen, > > meiner Meinung nach kocht doch jeder Hersteller sein eigenes Süppchen, > was die dazugehörige Entwicklungs-Umgebung angeht. Aber was ist > letztendlich so schlimm daran, das sich ATMEL nur Windows als Background > ausgesucht hat? > > Gruß Norbert Sehe ich auch so... Lieber für ein System ein gutes Tool bereitstellen als wieder Zwickelkrimskrams für zig andere Systeme. Ich finde die Entscheidung gut und richtig!
Chris schrieb: > Hardware Requirements: > • Computer that has a 1.6GHz or faster processor > • 1 GB RAM for x86 > • 2 GB RAM for x64 > • An additional 512 MB RAM if running in a Virtual Machine > • 3GB of available hard disk space > • 5400 RPM hard disk drive > • DirectX 9-capable video card that runs at 1024 x 768 or higher display > resolution Das sieht ja schlimmer aus als bei High-End Computerspielen -.- Hat denn das AVR Studio 5 irgendwelche Features, die dermassen Resourcen brauchen? Oder liegt es einfach an ineffizienter Programmierung mit einem noch ineffizienteren GUI-Framework? Seltsam finde ich übrigens, dass in der heutigen Zeit immer noch Taktfrequenzen für den Prozessor angegeben werden. Die ersten Celerons von ca. 2001 mit 1.6 GHz und heutige niedrig getaktete Multi-Core-64-Bit-Prozessoren sind leistungsmässig einfach um Welten entfernt.
P. M. schrieb: > Hat denn das AVR Studio 5 irgendwelche Features, die dermassen Resourcen > brauchen? Its not a bug, its a feature ;)
Auf der einen Seite finde ich das auch sehr merkwürdig, wohin Version 5 geht, auf der anderen Seite muss ich sage, dass mir Version 4.16 völlig ausreicht und ich nicht wirklich sehe warum ich mir Version 5 holen sollte. Ich denke, dass bleibt jetzten Endes jedem selbst überlassen welche Version er nutzt.
Immer dasselbe dumme Gesülze, wenn irgendwas neues kommt. Zu groß, zu viele Resourcen, ich benutze sowieso noch die Version von vorgestern, bla, bla, bla. mfg.
Hat schon jemand die Option: "Preserve EEPROM contents when reprogramming device" in AVR Studio 5 gefunden? Der überschreibt mir immer den EEPROM beim start der debug Funktion.
Also ich finde, auf den ersten Blick sieht es ja sehr einladend aus. Der Editor scheint um einiges komfortabler zu sein! Na mal vorsichtig gucken...
Ich hab mir gerade mal die Videos angeschaut. Es sind viele neue interessante Funktionen enthalten. Hat einer von euch das neue Studio 5 parallel zum alten Studio 4.18 installiert? Geht das überhaupt?
Wenn der STK500 nicht mehr unterstützt wird, dann kann ich gerne auf Studio5 verzichten. Vielleicht kommen die von Atmel ja noch dahinter daß das STK500 recht weit verbreitet ist und bauen die Unterstützung noch nachträglich ein. Oder liegt es daran daß SW mit der das Studio5 entwickelt wurde keine RS232 mehr unterstützt???? Je mehr sich bei Atmel melden desto besser. (Oder liest ein kompetenter Atmel Mitarbeiter hier mit???)
P. M. schrieb: > Chris schrieb: >> Hardware Requirements: >> • Computer that has a 1.6GHz or faster processor >> • 1 GB RAM for x86 >> • 2 GB RAM for x64 >> • An additional 512 MB RAM if running in a Virtual Machine >> • 3GB of available hard disk space >> • 5400 RPM hard disk drive >> • DirectX 9-capable video card that runs at 1024 x 768 or higher display >> resolution > > Das sieht ja schlimmer aus als bei High-End Computerspielen -.- Was für ein Quatsch. Das ist ein Rechner, wie er vor vielleicht 4 bis 5 Jahren mal aktuell war. Nur weil einige Freaks hier meinen, dass die IDE auch noch auf ihrem Rechner von anno Tobak laufen muss, wird Atmel keine kompaktere Software entwickeln. Kopfschüttelnd, Rainer
Grübler schrieb: > Hat einer von euch das neue Studio 5 parallel > > zum alten Studio 4.18 installiert? > > Geht das überhaupt? Ja. Das geht. Problem ist nur der JTAGICE. Für 5.0 braucht man ein Upgrade. Wenn man dann wieder 4.18 benutzen will, muß man den wieder downgraden. mfg.
>> Das sieht ja schlimmer aus als bei High-End Computerspielen -.- >>> • 3GB of available hard disk space Ein echter Skandal. Der raubt mir glatt 1% meiner Festplattenkapazität. Rainer Z. schrieb: > Nur weil einige Freaks hier meinen, dass die IDE > > auch noch auf ihrem Rechner von anno Tobak laufen muss Vor allen Dingen unter Linux. mfg.
Leute, es zwingt euch doch keiner das kostenlose Tool zu nehmen. Dann ladedt doch einfach die gnu toolchain standalone runter und nutzt den Editor den ihr magt und debugt in der Kommandozeile.
Tzz... ware Tuxer kennen sowieso keine GUI ;) Aber was mich nun wirklich stört ist das fehlen der STK500 Unterstützung :/ DAS darf nun wirklich sein! Aber sonst sieht es recht nett aus, ein wenig ungewöhnlich noch, aber sehr frisch!
im avr-freaks-thread wurde mehrfach bestätigt, dass STK500 in der final supportet wird. darf ich fragen woher ihr die videos habt? ich habe nur 2 auf der atmel-seite gefunden, das blöde werbevideo und "how to install..."
> darf ich fragen woher ihr die videos habt? Hier: http://www.atmel.com/microsite/avr_studio_5/default.asp?source=cms&icn=hmap1-AVR_STUDIO&ici=mar_2011
Rainer Z. schrieb: > P. M. schrieb: >> Chris schrieb: >>> Hardware Requirements: >>> • Computer that has a 1.6GHz or faster processor >>> • 1 GB RAM for x86 >>> • 2 GB RAM for x64 >>> • An additional 512 MB RAM if running in a Virtual Machine >>> • 3GB of available hard disk space >>> • 5400 RPM hard disk drive >>> • DirectX 9-capable video card that runs at 1024 x 768 or higher display >>> resolution >> >> Das sieht ja schlimmer aus als bei High-End Computerspielen -.- > > Was für ein Quatsch. Das ist ein Rechner, wie er vor vielleicht 4 bis 5 > Jahren mal aktuell war. Nur weil einige Freaks hier meinen, dass die IDE > auch noch auf ihrem Rechner von anno Tobak laufen muss, wird Atmel keine > kompaktere Software entwickeln. Es gibt wohl im AVR Studio 5 kein einziges Feature, das einen Rechner von "anno Tobak" überfordern würde. Ich jedenfalls sehe nichts, was es nicht schon seit 10 oder gar 20 Jahren in gängigen IDEs gibt oder sonstwie nicht schon vor 10 Jahren problemlos lief. Der exorbitante Resourcenverbrauch muss also woanders liegen, vermutlich an aufgeblasenen GUI-Frameworks. Das hat überhaupt nichts mit Freaks zu tun, sondern mit der Forderung, dass die Hersteller doch bitte sauber und effizient programmieren mögen. "Seltsamerweise" sind nämlich die resourcenfressendsten und unperformantesten Softwareprodukte der jeweiligen Gattung auch die verbuggtesten...
das finde ich schon komisch, bei den Autos möchte man weniger Verbrauch haben bei mehr Komfort und bei seinem PC ist man bereit einfach so Resourcen zu verblasen. Der Fortschritt sieht anders aus.
P. M. schrieb: > Es gibt wohl im AVR Studio 5 kein einziges Feature, das einen Rechner > von "anno Tobak" überfordern würde. Ich jedenfalls sehe nichts, was es > nicht schon seit 10 oder gar 20 Jahren in gängigen IDEs gibt oder > sonstwie nicht schon vor 10 Jahren problemlos lief. Der exorbitante > Resourcenverbrauch muss also woanders liegen, vermutlich an > aufgeblasenen GUI-Frameworks. Genau, vor 20 Jahren gab's das alles schon! Wenn ich mich recht erinnere, war damals Borland C++ der Standard, vor dem Sprung von DOS auf Windows. Codeergänzung? Referenzen? Refactoring? Klar, war alles schon dabei... :-) > Das hat überhaupt nichts mit Freaks zu tun, sondern mit der Forderung, > dass die Hersteller doch bitte sauber und effizient programmieren mögen. > "Seltsamerweise" sind nämlich die resourcenfressendsten und > unperformantesten Softwareprodukte der jeweiligen Gattung auch die > verbuggtesten... Und was haben diese Anforderungen bitte mit "ressourcenfressend" zu tun? Jeder professionelle Entwickler hat Hardware auf oder unter dem Tisch stehen, für die diese Anforderungen keinerlei Herausforderung darstellen. Selbst ein 0815 PC für unter € 300,- aus der Restekiste beim Discounter lacht sich über diese Anforderungen schlapp.
... - - - ... schrieb: Was soll das heißen? "s t t t s" in Morsetelegrafie? > das finde ich schon komisch, bei den Autos möchte man weniger Verbrauch > haben bei mehr Komfort und bei seinem PC ist man bereit einfach so > Resourcen zu verblasen. Der Fortschritt sieht anders aus. Komisch. In der Welt, in der ich lebe, werden PCs immer billiger und leisten dafür immer mehr. Vor 20 Jahren, um mal bei der Zahl oben zu bleiben, kostete ein Standard PC mit Monitor um die 1500 DM. Heute liegen die Standard PCs deutlich darunter. Über die Leistung brauchen wir nicht zu reden.
micro1 schrieb: > es zwingt euch doch keiner das kostenlose Tool zu nehmen. Eben, und keiner zwingt einen bei der alten Version zu bleiben wenn einem die neue nicht zusagt. Ich find den Festplattenplatz weniger dramatisch. Dramatisch finde ich eigentlich die Anforderung, dass das Studio 1 GB bzw. 2 GB RAM brauchen soll. DAS ist das, was ich ein wenig überzogen finde. Aber in der heutigen Zeit achtet man, so mein Eindruck, immer weniger auf die Resourcen wenns nicht unbedingt erforderlich ist und bei diesen Anforderung ists absolut gesehen ja nix was der Rechner hier können muss. Relativ gesehen ists aber ne Menge was da benötigt wird.
Rainer Z. schrieb: > Genau, vor 20 Jahren gab's das alles schon! Wenn ich mich recht > erinnere, war damals Borland C++ der Standard, vor dem Sprung von DOS > auf Windows. Codeergänzung? Referenzen? Refactoring? Klar, war alles > schon dabei... :-) 20 Jahre waren vor meiner Zeit. Vor 10 Jahren hingegen: Ja, gabs alles. Rainer Z. schrieb: > Und was haben diese Anforderungen bitte mit "ressourcenfressend" zu tun? Mir ist einfach nicht klar, warum eine Software so viel mehr Resourcen brauchen soll als noch vor 10 Jahren, wenn sie keine neuen, entsprechend aufwendigen Features mitbringt. Eine Waschmaschine wird ja auch nicht plötzlich doppelt so gross.
Thomas Eckmann schrieb: > ... - - - ... schrieb: >> Der Fortschritt sieht anders aus. > > Kommandozeile, oder was? Teilweise läge er genau da, nämlich an dem, auf dem das Zeug aufsetzt: Nämlich Kommantozeilen-Werkzeuge wie GCC. Anstatt Energie in riesige Tools zu blasen, hätte Atmel auch was für Fehlerbehebung in den den Basistools tun können. Stattdessen gammeln einige Bugs seit Jahren im avr-gcc rum. Aber egal, da wird sich eh nix mehr dran ändern... Zu Software selberrate ich jetzt mal: da ist auch das ganze AVR32-Zeug dabei
> 20 Jahre waren vor meiner Zeit. Vor 10 Jahren hingegen: Ja, gabs alles. Vor 10 Jahren waren erste Ansätze zu erkennen. Und weißt Du, was die Freaks damals geschrien haben: "Das ist Verschwendung von Ressourcen. Das braucht kein Mensch.". Merkst Du was? > Mir ist einfach nicht klar, warum eine Software so viel mehr Resourcen > brauchen soll als noch vor 10 Jahren, wenn sie keine neuen, entsprechend > aufwendigen Features mitbringt. Eine Waschmaschine wird ja auch nicht > plötzlich doppelt so gross. Wie groß war denn eine Festplatte vor 10 Jahren. Ich meine mich erinnern zu können, dass das so um die 20 GB waren. Und wo sind wir heute? 1 TB Festplatten sind Einstiegsmodelle. Locker mal das 50-fache Volumen. Heute ist das AVR Studio rund 500 MB groß. Im Verhältnis würde das 10 MB vor 10 Jahren entsprechen. Wo ist denn hier was aus der Relation gerutscht?
P. M. schrieb: > Der exorbitante Resourcenverbrauch muss also woanders liegen, > vermutlich an aufgeblasenen GUI-Frameworks. Vergessen, Optimierung zu aktivieren und den Code zu strippen. duck und weg
Johann L. schrieb: > Stattdessen gammeln einige Bugs seit Jahren im avr-gcc rum. Ist halt Open-Source Frickelkram und keine professionelle Software. Duck und weg... :-)
Jonas M. schrieb: > Muss man sich für den DL anmelden? Oder gibts irgendwo noch nen > inoffiziellen DL? Einfach einen Fantasie-Namen angeben und eine E-Mail Adresse von spambog.com. Dann gibt's später auch keinen Spam... ;-)
Windows-Programmierern, also solchen, die nichts anderes kennen, ist einfach jegliches Gefühl für adäquaten Resourceverbrauch abhanden gekommen. 0,5 GB für eine IDE sind einfach völlig übertrieben. Dazu kommt dann noch die Generation Gamer, die sich alle sechs Monaten einen neuen PC kaufen, und nicht verstehen können, dass es ökonomisch und ökologisch sinnvoller ist einen PC ein paar Jahre zu nutzen. Was dabei rauskommt ist so eine Dummheit wie Studio 5. Einfach nicht nehmen ist keine Alternative. Atmel-Programmer können nur über Studio upgedatet werden. Atmel hat die Update-Protokolle nie veröffentlicht. Genau so sind wichtige Teile der Debugging-Protokolle zwischen PC und ICE noch immer proprietär. Daher kann nur Studio alle AVRs debuggen. Studio 4 wird keine Updates mehr bekommen, damit ist man bei zukünftigen neuen AVRs auf das Monster Studio 5 angewiesen. Ach ja, dass das STK500 (noch?) nicht unterstützt wird, ist eine Zeichen der Arroganz von Atmel. Genau wie die fehlende Unterstützung von Usern alternativer Betriebssysteme. Insgesamt ein Schlag ins Gesicht vieler Entwickler.
Hannes Jaeger schrieb: > Windows-Programmierern, also solchen, die nichts anderes kennen, ist > einfach jegliches Gefühl für adäquaten Resourceverbrauch abhanden > gekommen. Eigentlich sollten wir auch in Höhlen leben und ab und zu mit einem Knüppel in den Wald gehen, um ein Tier zu erschlagen, oder ein paar Beeren zu sammeln. Hausbesitzern ist einfach jegliches Gefühl für adäquaten Resourceverbrauch abhanden gekommen.
Rainer Z. schrieb: > Hannes Jaeger schrieb: >> Windows-Programmierern, also solchen, die nichts anderes kennen, ist >> einfach jegliches Gefühl für adäquaten Resourceverbrauch abhanden >> gekommen. > > Eigentlich sollten wir auch in Höhlen leben und ab und zu mit einem > Knüppel in den Wald gehen, um ein Tier zu erschlagen, oder ein paar > Beeren zu sammeln. Hausbesitzern ist einfach jegliches Gefühl für > adäquaten Resourceverbrauch abhanden gekommen. Wenn wir Menschen mit den natürlichen Ressourcen genau so umgehen würden, wie die Entwickler bei Atmel, bräuchten wir wohl alle paar Jahre 'ne neue Erde.
Rainer Z. schrieb: > Vor 10 Jahren waren erste Ansätze zu erkennen. Und weißt Du, was die > Freaks damals geschrien haben: "Das ist Verschwendung von Ressourcen. > Das braucht kein Mensch.". Merkst Du was? Ich habe damals viel mit JBuilder gearbeitet. Die Live-Anzeige von Fehlern und Methoden sowie ein GUI-Designer waren dabei. Das lief erstens schon auf den damaligen Maschinen flüssig und war eine riesen, riesen Hilfe, die wohl nur API-Auswendiglerner als Verschwendung betitelt hätten. Beim neuen AVR-Studio hingegen konnte mir nach wie vor niemand ein Feature nennen, das nicht schon seit 10 Jahren resourcenmässig völlig problemlos läuft. Rainer Z. schrieb: > Wie groß war denn eine Festplatte vor 10 Jahren. Ich meine mich erinnern > zu können, dass das so um die 20 GB waren. Und wo sind wir heute? Ich möchte umgekehrt fragen: Warum soll eine IDE heute 2 GB RAM erfordern, wenn sie das gleiche kann, wie eine IDE von 2001, die auf 128 MB RAM lief? Wie gesagt: Ich sehe nichts, das so viel mehr Resourcenverbauch rechtfertigt.
Luk4s K. schrieb: > Wenn wir Menschen mit den natürlichen Ressourcen genau so umgehen > würden, wie die Entwickler bei Atmel, bräuchten wir wohl alle paar Jahre > 'ne neue Erde. Der Unterschied ist, dass die natürlichen Ressourcen begrenzt sind. Eine Ende der Hardware-Ressourcen sehe ich ehrlich gesagt noch lange nicht. Obwohl: im Studium vor etlichen Jahren hat mal ein Prof. gesagt, dass CMOS spätestens bei 20 MHz am Ende ist. :-)
P. M. schrieb: > Ich möchte umgekehrt fragen: Warum soll eine IDE heute 2 GB RAM > erfordern, wenn sie das gleiche kann, wie eine IDE von 2001, die auf 128 > MB RAM lief? Wie gesagt: Ich sehe nichts, das so viel mehr > Resourcenverbauch rechtfertigt. Ganz einfach: Setz' Dir heute noch mal einen PC mit Hardware und OS von vor 10 Jahren auf und installier' Dir den JBuilder. Dann arbeitest Du einmal eine Stunde damit. Wahrscheinlich wirst Du es nicht so lange schaffen, da Du vorher einen Brechreiz bekommst. Ich fand meinen 286er damals auch sehr schnell. Heute würde ich das Ding aus dem Fenster werfen. :-)
Rainer Z. schrieb: > Luk4s K. schrieb: >> Wenn wir Menschen mit den natürlichen Ressourcen genau so umgehen >> würden, wie die Entwickler bei Atmel, bräuchten wir wohl alle paar Jahre >> 'ne neue Erde. > > Der Unterschied ist, dass die natürlichen Ressourcen begrenzt sind. Eine > Ende der Hardware-Ressourcen sehe ich ehrlich gesagt noch lange nicht. > Obwohl: im Studium vor etlichen Jahren hat mal ein Prof. gesagt, dass > CMOS spätestens bei 20 MHz am Ende ist. :-) Hardwareressourcen gründen sich auf natürliche Ressourcen... Wenn manche Entwickler derzeit noch an nem Uraltrechner Arbeiten, muss nen neuer her. Das ganze lässt sich allerdings auch von der AVR-Studio-Ebene auf die gesamte Softwarebranche transzendieren, in der der Trend zu immer fetterer und aufgeblasener Software geht, oder würde bei MS wer daran denken, nen Datenbankserver auf nem 10 Jahre alten Pentium 3 laufen zu lassen?
Rainer Z. schrieb: > Johann L. schrieb: >> Stattdessen gammeln einige Bugs seit Jahren im avr-gcc rum. > > Ist halt Open-Source Frickelkram und keine professionelle Software. Es gibt ja auch keine profesionellen (bezahlten) avr-gcc Entwickler. Das ist nicht dem GCC-Projekt anzulasten. Atmel hat sowohl Knete als auch Know-How für beides.
Rainer Z. schrieb: > Ich fand meinen 286er damals auch sehr schnell. Die waren ja auch schnell. Nur ist die Software entsprechend langsamer/resourcenfressender geworden. Gibt's eigentlich ein Analogon zu Moore's Law? Eines, das beschreibt, wie der Resourcenhunger von Software exponentiell mit der Zeit wächst?
Luk4s K. schrieb: > Hardwareressourcen gründen sich auf natürliche Ressourcen... Mir war nicht bewusst, dass uns bald der Sand ausgeht. :-) > Wenn manche Entwickler derzeit noch an nem Uraltrechner Arbeiten, muss nen > neuer her. Das kurbelt die Wirtschaft an und sorgt dafür, dass ein Großteil der Leute hier im Forum einem geregelten Beruf nachgehen können. Eine Firma, die sich heute keine aktuelle Hardware für ihre Entwickler leisten kann oder will, ist morgen sowieso insolvent. Ich habe als Abteilungsleiter kein Interesse daran, dass meine Mitarbeiter während des Kompilierens den Bildschirm hypnotisieren, nur weil die Hardware schlapp ist. Bei einem Stundenlohn von 50 bis 70 Euro die ein guter Entwickler heute locker kostet, hat man eine brauchbare Hardware in einem Monat locker wieder drin.
Rainer Z. schrieb: > Das kurbelt die Wirtschaft an und sorgt dafür, dass ein Großteil der > Leute hier im Forum einem geregelten Beruf nachgehen können. Aha, ein Freund von geplanter Obsoleszenz also... Nein, die Wirtschaft kann, wenn nicht gar muss auch ohne jene funktionieren Die neue Hardware würde es erst überhaupt nicht brauchen, wenn Atmel keine Bloatware entwickelt, was für die Firmen ebenfalls kosten sparen würde...
Hannes Jaeger schrieb: > Insgesamt ein Schlag ins Gesicht vieler Entwickler. Sehe ich auch so. Uns wieso man zur Entwicklung von Software für z.B. den ATmega8 mit gerade mal 8KB Flash ein halbes GB Tools brauchen soll, ist nicht wirklich nachvollziehbar. Man bräuchte 64000 ATmega8, um diesen Klotz im Flash zu speichern.
Luk4s K. schrieb: > Die neue Hardware würde es erst überhaupt nicht brauchen, wenn Atmel > keine Bloatware entwickelt, was für die Firmen ebenfalls kosten sparen > würde... Endlich sagts mal einer. Was für ein Handy hast du eigentlich? Andreas schrieb: > Uns wieso man zur Entwicklung von Software für z.B. > den ATmega8 mit gerade mal 8KB Flash ein halbes GB Tools brauchen soll, > ist nicht wirklich nachvollziehbar. Noch nie mit CPLDs gearbeitet?
Johann L. schrieb: > Gibt's eigentlich ein Analogon zu Moore's Law? Eines, das beschreibt, > wie der Resourcenhunger von Software exponentiell mit der Zeit wächst? Das Wirtsche Gesetz: "Die Software wird schneller langsamer als die Hardware schneller wird." mfG Markus
Luk4s K. schrieb: > Die neue Hardware würde es erst überhaupt nicht brauchen, wenn Atmel > keine Bloatware entwickelt, was für die Firmen ebenfalls kosten sparen > würde... Und hätte Microsoft nicht Windows entwickelt wären wir heute noch mit einem 286er zufrieden. Das Stichwort lautet Fortschritt. Schau Dir an, was das neue AVR Studio kann, was das alte nicht konnte. Da sind jede Menge Features bei, die die Arbeit erleichtern. Gewiss, hätte man sicher auch mit geringeren Anforderungen an die Hardware realisieren können. Aber was wären die Folgen gewesen? Atmel hätte wahrscheinlich ein vollständig eigenes System aufsetzen müssen, anstatt auf einen existierenden Unterbau aufzubauen. Wer soll das bezahlen? Sicher nicht die Leute, die das Tool kostenlos runterladen wollen, oder? Also ist das für Atmel unattraktiv. Alternativen? Klar, die Eclipse! Schade nur, dass das auch wieder ein zig 100 MB großer Brocken ist. Wäre zwar auch auf anderen Systemem lauffähig, aber Atmel wird wohl seine Gründe dafür gehabt haben, es so zu machen, wie es ist. Überlege Dir mal wer die eigentliche Zielgruppe ist, und worauf deren Systeme laufen. Linux? Sicher nicht.
> Also ist das für Atmel unattraktiv. Alternativen? Klar, die Eclipse! Schade nur, dass das auch wieder ein zig 100 MB großer Brocken ist. Man beachte die Download Grössen: http://www.eclipse.org/downloads/
Michael G. schrieb: > Luk4s K. schrieb: >> Die neue Hardware würde es erst überhaupt nicht brauchen, wenn Atmel >> keine Bloatware entwickelt, was für die Firmen ebenfalls kosten sparen >> würde... > > Endlich sagts mal einer. Was für ein Handy hast du eigentlich? Siemens S45, nachdem es mehrmals durch die Familie gewandert ist, davor hatte ich praktisch kein Händie Rainer Z. schrieb: > zig 100 MB großer Brocken Wäre noch vertretbar Gewesen im Gegensatz zu 3GB. Ich komme für meinen Teil mit Geany als besserem Texteditor, gcc, avrdude und ner Makefile aus. So spontan fällt mir nichts ein, was mir fehlt, zugegeben, ich habe mir noch nie groß drüber Gedanken gemacht. Und ja, es muss nicht immer Aufwärts, höher, schneller, weiter gehen, irgendwann knallt es ganz gewaltig. Alle reden immer nur vom "wachsen" doch irgendwann hat sich's halt ausgewachsen...
Frank schrieb: > Man beachte die Download Grössen: Ja und? 177 MB gegenüber 522 MB. Benutzt du noch ein Modem oder ISDN? Dann würde ich vom Download beider Varianten abraten. Bei DSL und Co. spielt's keine Rolle.
Rainer Z. schrieb: > Ja und? 177 MB gegenüber 522 MB. Eclipse IDE for C/C++ Developers, 87 MB + GNU tools dürfte so ~100MB sein. Nur falls es auf die Grösse ankommt - kommt es ja nie an.
Rainer Z. schrieb: > Frank schrieb: >> Man beachte die Download Grössen: > > Ja und? 177 MB gegenüber 522 MB. Benutzt du noch ein Modem oder ISDN? > Dann würde ich vom Download beider Varianten abraten. Bei DSL und Co. > spielt's keine Rolle. Dann wäre auch der Bildformate Artikel überflüssig und alle würden Ihre Bilder als unkomprimierte 6Mpix TIFFs hochladen... Das streben nach kleinen und schnellen Programmen, was einst Ziel der Informatiker war, wird von jenen die solche Monster wie AVR-Studio 5 erschaffen mit Füßen getreten. Durch Einsatz von ein wenig mehr Grips ließe sich das bestimmt kleiner bekommen
Luk4s K. schrieb: >> zig 100 MB großer Brocken > Wäre noch vertretbar Gewesen im Gegensatz zu 3GB. Wer sich über das Fehlen von 3 GB auf der Festplatte Gedanken machen muss, hat normalerweise ganz andere Probleme. :-) > Ich komme für meinen Teil mit Geany als besserem Texteditor, gcc, > avrdude und ner Makefile aus. Dann bleib doch auch einfach dabei. Zwingt dich ja keiner zum Umstieg. > So spontan fällt mir nichts ein, was mir > fehlt, zugegeben, ich habe mir noch nie groß drüber Gedanken gemacht. Andere offensichtlich schon. > Und ja, es muss nicht immer Aufwärts, höher, schneller, weiter gehen, > irgendwann knallt es ganz gewaltig. Alle reden immer nur vom "wachsen" > doch irgendwann hat sich's halt ausgewachsen... Da gibt es (zum Glück) auch noch andere Meinungen. ;-)
Luk4s K. schrieb: > Dann wäre auch der Bildformate Artikel überflüssig und alle würden > Ihre Bilder als unkomprimierte 6Mpix TIFFs hochladen... Sieht man oft genug hier. Und würde nicht ständig irgendein Gutmensch darüber meckern, würde es mir beim Download noch nicht mal auffallen. :-) > Das streben nach kleinen und schnellen Programmen, was einst Ziel der > Informatiker war, wird von jenen die solche Monster wie AVR-Studio 5 > erschaffen mit Füßen getreten. Durch Einsatz von ein wenig mehr Grips > ließe sich das bestimmt kleiner bekommen Über dieses Thema habe ich bereits weiter oben geschrieben. Machbar schon, aber wahrscheinlich nicht wirtschaftlich. Und wozu? Über die Größe wird nur in Foren wie hier gestänkert. Professionelle Anwender nutzen es einfach und verstehen nicht, was das Gejammer soll.
Rainer Z. schrieb: > Da gibt es (zum Glück) auch noch andere Meinungen. ;-) Bedauerlicherweise sind die natürlichen Ressourcen nicht unendlich... OT: Ich hab's grad mal ausgerechnet: Der ganze AVR-Krams macht bei mir Installiert 82MB aus.
Rainer Z. schrieb: > Wer sich über das Fehlen von 3 GB auf der Festplatte Gedanken machen > muss, hat normalerweise ganz andere Probleme. :-) Kommt halt drauf an, mit was man unterwegs ist. Die bisherige Entwicklungsumgebung passte mitsamt Betriebssystem auf eine 4GB SD-Card, die in einer virtuellen Maschine auf einem mit 1GB RAM ausgestatteten Netbook lauffähig war. Das jedenfalls kann man mit der 5er Version abhaken. In jedem einzelnen verdammten Parameter.
Rainer Z. schrieb: > Sieht man oft genug hier. Und würde nicht ständig irgendein Gutmensch > darüber meckern, würde es mir beim Download noch nicht mal auffallen. > :-) Du kreideste mir an, nur meine eigene Meinung in den Argumenten Niederschlag finden zu lassen. Du hingegen gehst davon aus, dass jeder (wie vielleicht Du) 32Mbit (übetrieben) DOCSIS hat; es gibt auch Leute oder Nutzergruppen, die nur DSL Light oder das Forum hier über GPRS/UMTS benutzen wollen. Da macht sich 4MB / 100k schon bemerkbar. Außerdem kostet der Speicherplatz auf Andreas' Server. Um deine Argumentation fortzuführen, wäre es sinnvoll, fette Bilder hochzuladen, da dann Andreas mehr Speicherplatz bestellen müsste, was die Wirtschaft ankurbeln würde.
A. K. schrieb: > Kommt halt drauf an, mit was man unterwegs ist. Die bisherige > Entwicklungsumgebung passte mitsamt Betriebssystem auf eine 4GB SD-Card, > die notfalls in einer virtuellen Maschine auf einem mit 1GB RAM > ausgestatteten Netbook lauffähig war. > > Das jedenfalls kann man mit der 5er Version abhaken. In jedem einzelnen > verdammten Parameter. Ich würde jetzt mal wetten, dass das auch gar nicht die Zielsetzung bei der Entwicklung war. Glaubst Du wirklich, dass Atmel es interessiert, wenn ihre IDE nicht mehr in einer VM auf dem Netbook eines Hobbyentwicklers läuft? Wohl kaum. Meistens ist das nämlich der gleiche Personenkreis, der versucht seine 1 bis 5 Stück AVRs als Sample zu schnorren. Mach Dir nichts vor: Atmel entwickelt die Software, und finanziert sie auch damit, für Firmen, die später einige 10.000 µC kaufen. Und diesem Kundenkreis sind die Kosten für die Entwicklungsplattformen egal, da die Preise verglichen mit den EW-Kosten lächerlich gering sind.
Rainer Z. schrieb: > Ich würde jetzt mal wetten, dass das auch gar nicht die Zielsetzung bei > der Entwicklung war. Glaubst Du wirklich, dass Atmel es interessiert, > wenn ihre IDE nicht mehr in einer VM auf dem Netbook eines > Hobbyentwicklers läuft? Wohl kaum. Nee, ich fands aber schön dass es für den Mobileinsatz damit ging. Ganz so unwichtig scheint es Atmel aber doch nicht zu sein, sonst hätten sie die DIP-Gehäuse schon vor 10 Jahren endgültig entsorgt. Oder welcher 10000er Kunde verwende die?
Luk4s K. schrieb: > Außerdem kostet der Speicherplatz auf Andreas' Server. Das ist übrigens das einzige Argument, das ich für die Verwendung von kleinen Grafiken gelten lasse. > Um deine Argumentation fortzuführen, wäre es sinnvoll, fette Bilder > hochzuladen, da dann Andreas mehr Speicherplatz bestellen müsste, was > die Wirtschaft ankurbeln würde. Falsch. Das ankurbeln der Wirtschaft wäre nur ein beiläufiger Effekt. Wenn das Hochladen großer Bilder einen Vorteil hätte (so wie die neue AVR Studio Version gegenüber der alten), würde ich es unterstützen. Für die meist verwackelten Handy-Aufnahmen die man hier jedoch überwiegend findet, macht es wirklich keinen Sinn.
Hannes Jaeger schrieb: > Der Herr beschütze mich vor Software die von Rainer Z. stammt. Kannst Du auch gar nicht bezahlen. ;-)
Atmel wendet nur Architectural Best Practices an. http://geekandpoke.typepad.com/geekandpoke/2011/03/architectural-best-practices.html
Guten Abend, war heute auf der Embedded, ein Atmel-Ma hat erzählt, mit dem AVR-Studio 5 seinen nun die IDEs für 8bit und 32bit-Cores in einer IDE vereinigt...
Hat hier denn irgendwer das ganze mal ausprobiert? Oder könnt ihr wie immer nur rummeckern und -jaulen? Freut euch doch mal das Atmel so etwas kostenlos zur Verfügung stellt. Wenn ihr unzufrieden seit, kauft euch doch nen IAR Compiler und nutzt zum Entwickeln Keil oder Eclipse oder was auch immer. "Buhuu. 500MB sind soooo viel. Das schafft mein 16MBit DSL nicht. Und 3GB hab ich auch nicht auf meiner 1TB Festplatte frei. Das brauch ich alles für heruntergeladene Musik und Filme! *schief*" Herrje ist dieses Forum schlimm! Gute Nacht!
Helfer schrieb: > http://geekandpoke.typepad.com/geekandpoke/2011/03/architectural-best-practices.html Danke!
Helfer schrieb: > Atmel wendet nur Architectural Best Practices an. Wirklich innovative Halbleiter hat es seit rund 40 Jahren nicht mehr gegeben. http://www.national.com/rap/files/datasheet.pdf
Luk4s K. schrieb: > "Solution Explorer" nennst du Vorteil? Auf jeden Fall. Wenn die ganzen Einsteiger und Amateure hier im Forum ihn nutzen würden, und daraus dann auch lernen, bleiben uns sicher viele Fragen erspart.
Hi >Guten Abend, >war heute auf der Embedded, ein Atmel-Ma hat erzählt, mit dem AVR-Studio >5 seinen nun die IDEs für 8bit und 32bit-Cores in einer IDE vereinigt... Eben. AVR-Studio32 272 MB AVR-Studio+SP1...3 ca.206 MB --------- 478 MB MfG Spess
kopf schütel. diese diskosionen sind doch immer wieder amüsant. ich kenn das avr studio nicht. was mir aber nur aufgefallen ist. CDT + avrgcc verses avrStudi5. Documentation beispielcode ... werden hier irgendwie unterschlagen. zu fehlern im gcc: nicht gross rum mekern. selber suchen und ausmerzen wenn sie so nervend sind. ist doch schliesslich open source, und du hast zugriff auf die sourcen. patch an den maintainer schicken und mit etwas glück ist der fehler dann in zukunft drausen. und zu früher war alles besser: da hat man auch keinen compiler für lau bekommen, sondern hat meist zahlen dürfen, und der war genauso verbugt wie heute / ggf sogar noch schlimmer. zur entscheidung wieso auf VS2010 aufsetzen anstelle auf der CDT. Plugin entwicklung für eclipse ist aufwendig und kompliziert. Aktuell wird die API von Eclipse überarbeitet. ggf funktioniert eine aktuell entwickeltes plugin für die cdt mit der neuen dann nicht mehr. Eclipse ist ein java programm. bestehenden code für den debugger in der cdt / eclipse zu integrieren wäre sicher nicht ganz einfach geworden.
Genervt schrieb: > Hat hier denn irgendwer das ganze mal ausprobiert? Oder könnt ihr wie > > immer nur rummeckern und -jaulen? Ich hab's installiert. Und deswegen meckere und jaule ich auch nicht. Mal ganz nebenbei: Speicherplatz auf der HD 700MB, RAM während der Ausführung 53 MB. Luk4s K. schrieb: > "Solution Explorer" nennst du Vorteil? Ich auch. mfg.
apropo hat mal jemand die anforderunen mit denen vom VS2010 verglichen. ggf sind die nur von dort übernommen worden. ich vermute dotNet4 muss installiert sein, IE x.y auch und noch ein paar andere sachen. ggf lassen sich dan so die 3gb had erklären oder hat das mal einer "nach gemessen"
Rainer Z. schrieb: > Auf jeden Fall. Wenn die ganzen Einsteiger und Amateure hier im Forum > ihn nutzen würden, und daraus dann auch lernen, bleiben uns sicher viele > Fragen erspart. Geschmackloses Gesabbel.
Der Rainer Z, der sich hier so ereifert ist nicht zufällig freier Mitarbeiter von Atmel? Wenn dein Fortschritt so ausssieht, daß man jetzt bei einem Speicher eines PCs der nicht älter als 1 höchstens 2 Jahre ist tatsächlich 4 Programme gleichzeitig laufen lassen kann bevor er das swappen anfängt (Mist das Betriebssystem braucht ja auch noch 1 G) dann hatten wir aber seit 1983 kein Fortschritt. CCPM86 für den PC XT mit 4,7MHz hatte schon 4 virtuelle Konsolen und konnte 4 Anwendungen gleichzeitig laufen lassen. Rainer Z. schrieb: > Hannes Jaeger schrieb: >> Der Herr beschütze mich vor Software die von Rainer Z. stammt. > > Kannst Du auch gar nicht bezahlen. ;-) > > > > Beitrag melden | Bearbeiten | Löschen | Warum, kommen die eigentlichen Kosten nach dem Kauf :-))
Also die Download und Installationsgröße ist doch heutzutage sowas von scheiß egal. So lange das Studio endlich die Funktionen bietet die ich schon lange vermisse juckt mich das nun wirklich nicht. Also: Bitte mal etwas auf dem Boden bleiben. Die geben was raus was kostenlos zu bekommen ist und Ihr macht nichts anderes als über die Downloadgröße zu meckert - unfassbar. Tim
Tim schrieb: > Also die Download und Installationsgröße ist doch heutzutage sowas von > scheiß egal. Der Atmel Server sieht das anscheinend anders und lässt die Daten mit nur 80-100kByte/s aus der Leitung tröpfeln.
>Tim schrieb: >> Also die Download und Installationsgröße ist doch heutzutage sowas von >> scheiß egal. >Der Atmel Server sieht das anscheinend anders und lässt die Daten mit >nur 80-100kByte/s aus der Leitung tröpfeln. Wo ist das Problem? Nach 60 bis 90 min bist du fertig mit dem Download.
Report #13722: STK500 is not supported in beta release. STK500 support is scheduled for final release of AVR Studio 5.0
Hi, also ich finde diese Anforderungen auch heftig! Da fehlen einen die Worte- Wobei mich nicht der Platz auf der Festplatte stört - der ist tasächlich relativ egal. Aber was da an CPU und RAM Resourcen verlangt wird... Man darf es ja nicht nur aus der Sicht des Einzelprogramms sehen. Wie oft laufen auf dem Rechner mit dem man entwickelt noch andere Programe mit. Das kann der IE bzw. FF sein weil man im Web was nachschauen will. ODer ein Programm zum generieren von Testsignalen oder dem Loggen beim LogicAnalyzer oder... oder... oder... Und dann wird es mit diesen Anforderungen schon bei einem 2Jahre alten Rechner knapp - von 4Jahre alten ganz zu schweigen. Rainer Z. schrieb: > ... > Eine Firma, die sich heute keine aktuelle Hardware für ihre Entwickler > leisten kann oder will, ist morgen sowieso insolvent. Ich habe als > Abteilungsleiter kein Interesse daran, dass meine Mitarbeiter während > des Kompilierens den Bildschirm hypnotisieren, nur weil die Hardware > schlapp ist. Bei einem Stundenlohn von 50 bis 70 Euro die ein guter > Entwickler heute locker kostet, hat man eine brauchbare Hardware in > einem Monat locker wieder drin. Wenn du tatsächlich Abteilungsleiter bist, dann sollte dir erst recht bewusst sein das es in vielen Fällen - gerade in der Entwicklung ebend NICHT nur mit dem Kauf eines neuen Rechners getan ist. Die 300 Eur. spielen absolut keine Rolle. Selbst im Privatbereich ist das nur selten ein echtes Problem. Klar, wer den Rechner nur für AVR Programmierung, ein wenig Internet Email und Office nutzt, der hat da kein Problem. Aber schaue dir doch mal die Rechner der meisten Hardwareentwickler an. Da findet sich dann nicht nur das AVR Studio darauf, sondern oft noch zig andere Umgebungen. Sie es die Entwicklungsumgebung für FPGA oder CPLD. Das Gerät zum EEPROM beschreiben, je nach Schwerpunkt noch diverse Bussysteme (IEE488/PROFIBUS/SCSI). Der schon beschriebene Logic Analyzer, Der Anschluss für das DSO und ggf. noch weitere Tools für Hardware anderer Anbieter. Wenn es eine Firma ist die auch Support für ältere Produkte ernst nimmt kommen dann noch diverse ältere Tools zum Einsatz wo vieleicht die IDE oder die Hardware gar nicht mehr mit den superschnellen Rechnern ordentlich läuft und es selbst wenn man gewillt wäre es zu kaufen kein kompatibles Nachfolgeprodukt gibt. Will man dann einen neuen Rechner kaufen ist es ebend NICHT mit den 300 Eur. getan. Dann fängt es an das die anderen Hardwaretools keine USB Schnittstelle haben, zwingend RS232 oder Parallel brauchen. Natürlich -man könnte diese Tools auch erneuern, bei günstigen macht es sogar Sinn- aber für einige Dinge gibt es keinen modernen Ersatz oder er kostet weit mehr als ein neuer Rechner... Also -sofern man Glück und noch freie Steckplätze hat- eine zusätzliche COM / LPT Interfacekarte verbauen. In meinem Falle sogar zwei da ich jetzt schon eine drin habe. Wenn man jetzt aber bedenkt das Steckplätze auf modernen Boards immer mehr zur Mangelware werden, dann wird es kritisch. Selbst wenn man die zwei Karten noch reinbekommt- Wo kommt die IEEE488 oder die SCSI KArte rein? Natürlich gibt es wohl auch moderne Motherboards mit zahlreichen Slots. Aber die sind halt kein Standart mehr und alles andere als Günstig. Ich habe mal ein Foto meiner PC-Rückseite meines momentanen Entwicklungsrechners angehangen, leider nur ein Handybild. Und es sind alle Schnittstellen in Benutzung! Als Karten sind Verbaut IEE488 / Schnitstellenkarte 2x RS232 1XParallel/ IEEE1294 SCSI TV_IN / und noch eine Einzelne VGA Karte (wg. TV Out) (OK, statt der analogen Videokarte könnte ich auch ein USB Stick nehmen, aber der Rest. Benutzt wird diese zur Dokumentation bei Messtechnik mit Videoausgang) Und als Krönung- selbst wenn man die Hardware dann hat- Kann ich dir aus Erfahrung sagen das es ein riesen Spass ist so ein System erst einmal so einzurichten das es Stabil läuft und alles funktioniert anstelle sich gegenseitig zu blockieren. Da kannst du sehr sehr viele Programme für 8Bit Microcontrolle Compilieren bis du diese Zeit wieder drin hast. Wahrscheinlich so viele das der PC eher wieder alt ist als das du den Zeitnachteil durch weniger Wartezeiten beim Kompilieren hrausgeholt hast. Ich habe als Entwicklungs-PC einen 2,4 GHz SingleCore mit 512MB Ram, je 2x 1TB HDD, 1x1,44"FDD und 2x DVD RW. Und er erfüllt meine Anforderungen voll und ganz. Ich habe bis jetzt keine Anwendung die auch nur annähernd längere Wartezeit oder zögerliche Reaktion provoziert. Und mir kann keiner Erzählen das eine IDE für AVR Microcontroller nicht so programmiert werden kann das sie noch auf viel langsameren Rechner sauber laufen würde. Und ich bin froh das es noch läuft, denn ich sehe mich schon gegen den Tag an an dem ich alles umstellen muss. Ein weiterer Rechner ist aber auch keine Lösung. Es stehen schon zwei (langsamere) REchner daneben ebend für alte Anwendungen die ich zwingend benötige - auf einen vierten Rechner an dem Platz kann ich gut verzichten. Natürlich gibt es bei mir auch rechner die die Mindestanforderungen erfüllen - sogar mein Netbook packt das- aber diese stehen nicht am Elektronikplatz und mein Netbook will ich auch nicht immer dort stehen haben. Wenn AVR Studio dann jetzt auf diesem PC nicht mehr ordentlich läuft werde ich halt noch seltener AVRs verwenden. Ist nicht Weltbewegend aber doch ein paar hundert Bausteine die dann weniger verkauft werden. Und wenn viele so denken... Und das einfach bei Ver. 4zu bleiben ist auch keine Lösung... Denn dann kann man die neuen Bausteine glecih vergessen. Unter diesen Gesichtspunkten haben die Hobbyelektroniker es vieleicht sogar leichter! Rainer Z. schrieb: > A. K. schrieb: > > Ich würde jetzt mal wetten, dass das auch gar nicht die Zielsetzung bei > der Entwicklung war. Glaubst Du wirklich, dass Atmel es interessiert, > wenn ihre IDE nicht mehr in einer VM auf dem Netbook eines > Hobbyentwicklers läuft? Wohl kaum. Meistens ist das nämlich der gleiche > Personenkreis, der versucht seine 1 bis 5 Stück AVRs als Sample zu > schnorren. Mach Dir nichts vor: Atmel entwickelt die Software, und > finanziert sie auch damit, für Firmen, die später einige 10.000 µC > kaufen. Und diesem Kundenkreis sind die Kosten für die > Entwicklungsplattformen egal, da die Preise verglichen mit den EW-Kosten > lächerlich gering sind. Ich hoffe nicht das wirklich diese Gedankengänke bei Atmel dahinterstecken. Auch wenn die Hinweise immer öfter in diese Richtung gehen. Wenn dem so währe dann müsste man jedem Anfänger sofort davon abraten sich mit den AVRs zu beschäftiten. Und die Mittelständler sind dann auch gut beraten sich schleunigst um eine Umstellung zu kümmern. Eine Firma wo einzig die Großkunden zählen ist kein verlässlicher Partner. Als kleiner habe ich andere Belange als die Großen und müsste jederzeit mit einer Entscheidung rechnen die mich ohne Vorwarnung vor die Wand fahren lässt. Zudem wäre die Focussierung auch Größtkunden eine sehr kurzsichtige Entscheidung. Zwar ticken die Uhren dort anders und es wird das genommen was am günstigsten / verlässlichsten ist und nicht nach Beliebtheit. Und alle Hobbybastler Deutschlands zusammen sind tatsächlich nur Peanuts. Aber schon der Mittelstand ist in der Summe auch eine große Nummer. Es würde mich nicht einmal wundern wenn zusammengerechnet im bereich Mittelstand mehr AVRs abgesetzt werden als an die Großkunden. Gerade im Mittelstand ist es aber nicht selten so das die Entscheidung welcher µC zur Anwendung kommt nicht von Nachkommastellen beim in Cent ausgedrückten IC Preis abhängt - sondern zu großen Teilen von den Vorlieben des Entwicklers. Aber fast jeder Entwickler hat mal klein angefangen - als Hobbybastler oder Student mit kleinen Projekten. Wenn ich diese aber in diesem Stadium schon verprelle dann haben die auch im Job keinen großen Elan mehr sich der Sache AVR anzunehmen. Andere Hersteller haben dies Kapiert. Und das hat eindeutig auch dazu geführt - obwohl ich für die µC von TI / ST Freescale AtmelAVR Atmel8051 Microchip und RENESAS Dev. Tools da habe - (bis auf Freescale jeweils incl. Debugger/JTAG/ICD) ergänzt von Cypress dev. Kits mit USB bootloader.- eindeutig Microchip bevorzuge. Denn da werde ich bei privater Anfrage genauso erst genommen wie damals als Vertreter des Kunden mit doch einiges an Umsatz. Und noch mehr bei Anfrage im Namen der FH. Aber jetzt ist aus der kurzen Antwort doch wieder ein Beitrag geworden der genauso Aufgeblasen ist wie das AVR Studio 5 - deshalb mache ich hier besser Schluss ;-) Gruß Carsten
Hannes Jaeger schrieb: > Windows-Programmierern, also solchen, die nichts anderes kennen, ist > einfach jegliches Gefühl für adäquaten Resourceverbrauch abhanden > gekommen. 0,5 GB für eine IDE sind einfach völlig übertrieben. Dem stimme ich komplett zu. Leider ist dieser Trend nicht nur bei AVR-Studio zu beobachten, hat mal jemand versucht den Altium Designer (legale Version - bevor einer fragt) und die Xilinx-Tools auf einem älteren PC zu benutzen? Selbst bei Programmen wie OpenOffice und Firefox habe ich das Gefühl der Trend geht zu immer gierigeren Programmen. :-( Viele Programme in denen wirklich Hirnschmalz steckt (z.B. der GCC) haben überhaupt keine IDE und laufen mit ein paar MB RAM in der Kommandozeile! Kann doch nicht sein dass "ein paar Fenster" 1GB RAM brauchen! Klar, "ein paar Fenster" ist bewusst provozierend, aber wenn man mal genau überlegt: Viel mehr ist das nicht. Die Programme im Hintergrund die die eingegebenen Daten wirklich verarbeiten (Compiler, Assembler,...) brauchen vermutlich viel weniger. > Dazu kommt dann noch die Generation Gamer, die sich alle sechs Monaten > einen neuen PC kaufen, und nicht verstehen können, dass es ökonomisch > und ökologisch sinnvoller ist einen PC ein paar Jahre zu nutzen. Ja. > Was dabei rauskommt ist so eine Dummheit wie Studio 5. Das Wort "Dummheit" ist gut gewählt. Und von wegen 300€: Was machen Studenten und Arbeitslose? 300€ sind eine Menge Geld - und das es dafür einen PC gibt der leistungsfähig genug ist wage ich eh zu beweifeln.
Was regt ihr euch denn alle auf? Die Anforderungen stehen doch so nur auf dem Papier. Es wurde doch schon geschrieben, dass ein gestartetes Studio5 nicht 1 oder 1GB sondern nur ~50MB Ram belegt (+ bisschen was von .NET und so vielleicht noch). Das sind doch nur pauschale Angaben. Und die Downloadgröße finde ich auch angemessen. AVRStudio4, AVRStudio32, WinAVR, 32Bit-Toolchain war in der Summe bestimmt auch nicht viel kleiner. Aber jedem seine Meinung... das hier war jetzt eben meine ;)
Fairerweise muss man sagen, dass GCCs ureigene IDE, der Emacs, einstmals ob seines erheblichen RAM-Verbrauchs als "Eight Megabytes And Constantly Swapping" verspottet wurde ;-).
kritiker schrieb: > Und von wegen 300€: Was machen Studenten und Arbeitslose? 300€ sind eine > Menge Geld - und das es dafür einen PC gibt der leistungsfähig genug ist > wage ich eh zu beweifeln. Weil Carsten Sch. (dg3ycs) es oben angesprochen hat: Jeder Entwickler hat mal klein angefangen, als Student oder - noch früher - als Schüler. Und spätestens da sind die xxx€ für einen neuen PC alle paar Monate dann plötzlich sehr viel Geld. Da fällt mir ein Zitat ein was in zig Versionen durchs Netz geistert: > Es braucht die Rechenpower eines Pentium IV, 256MB RAM und 10GB > Festplattenspeicher, um Windows XP halbwegs laufen zu lassen. Es brauchte > die Rechenpower von drei C64, um zum Mond zu fliegen. Irgendetwas stimmt > mit unserer Welt nicht.
Hallo, gibt es denn irgendwelche Infos, dass das STK500 vielleicht in späteren Versionen wieder unterstützt wird?
Mark schrieb: > Hallo, > > gibt es denn irgendwelche Infos, dass das STK500 vielleicht in späteren > Versionen wieder unterstützt wird? Ja. Beitrag "Re: AVR-Studio 5" An sich aber schon eine reife Leistung. Dafür, dass Atmel sich den C-Compiler schnorrt und die letzten Versionen des hauseigenen Debuggers immer noch unter steinalten Fehlern leiden... M.M.n. jede Menge Blendwerk dabei.
Tim schrieb: > Also: Bitte mal etwas auf dem Boden bleiben. Die geben was raus was > kostenlos zu bekommen ist und Ihr macht nichts anderes als über die > Downloadgröße zu meckert - unfassbar. Genervt schrieb: > Freut euch doch mal das Atmel so etwas kostenlos zur Verfügung stellt. > Wenn ihr unzufrieden seit, kauft euch doch nen IAR Compiler und nutzt > zum Entwickeln Keil oder Eclipse oder was auch immer. Sehe ich es auch so! So wie eure "Gerhard Schröder" damals sagte: -->>" Deutsche sollen aufhören zu jammern " Wenn die Software von Atmel nicht kostenlos wäre, hätte mit Sichertheit niemand hier was gemeckert in gegenteil würde sich jeder nach eine neue Update freuen aber so ist es halt! Gruß Martin
Ich kann irgendwie das NET Framework nicht installieren, weder manuell noch im Paket. Kommt immer die Meldung: "Algemeiner Vertrauensfehler" Ich habe schon versucht es direkt von Microsoft mit dem IE zu downloaden, trotzdem der gleiche Fehler. Was läuft das falsch?
Oh Mann!!! schrieb: > "Algemeiner Vertrauensfehler" Sieht nicht nur komisch aus, klingt auch komisch.
Oh Mann!!! schrieb: > Ich kann irgendwie das NET Framework nicht installieren, weder manuell > noch im Paket. Kommt immer die Meldung: > > "Algemeiner Vertrauensfehler" > > Ich habe schon versucht es direkt von Microsoft mit dem IE zu > downloaden, trotzdem der gleiche Fehler. > > Was läuft das falsch? Willkommen bei MS, it's not a bug, it's a feature. (SCNR) Nutzt du den "Online-Installer" (oder wie dieser Spion auch heißen mag)? Lad mal das komplette Setuppaket (ein paar hundert MB müssten das sein) runter und installier offline. Oh Mann!!! schrieb: > Grammatik & Rechtschreibung = 6-! ???
> Freut euch doch mal das Atmel so etwas kostenlos zur Verfügung stellt. > Wenn ihr unzufrieden seit, kauft euch doch nen IAR Compiler und nutzt > zum Entwickeln Keil oder Eclipse oder was auch immer. Ist natürlich ziemlicher Blödsinn, den du ohne nachzudenken hin schmierst. - Die Umgebung ist nicht kostenlos, da die Anwender Atmel Controller einsetzen - Keil unterstützt die AVR Famillie (leider) nicht Fazit: Was nichts kostet taugt nichts.
Carsten Sch. schrieb: > Ich hoffe nicht das wirklich diese Gedankengänke bei Atmel > dahinterstecken. Ich glaube mittlerweile, dass genau das - die ausschließliche Fokusierung auf Großkunden - dahinter steckt. > Auch wenn die Hinweise immer öfter in diese Richtung > gehen. Für mich sind das schon mehr als Hinweise. Atmel führt sich aus meiner Sicht seit einiger Zeit so auf, als ob sie es nicht nötig haben. Studio 5 ist nur ein weiterer Schlag ins Gesicht derer, die nicht mit Millionen Stückzahlen operieren. Ironischerweise ist diese IDE dann noch aus kostenlosen Teilen zusammengeklaubt, aber gerüchtweise mag Atmel die an gcc vorgenommenen Änderungen nicht so ohne weiteres ans gcc-Projekt zurückgeben. Etwas veröffentlichen vereinbart sich nicht mit Atmels proprietären Debugging-Protokollen, den proprietären Firmware-Update-Protokollen, der proprietären Tool-Dokumentation, dem proprietären ASF. > Wenn dem so währe dann müsste man jedem Anfänger sofort davon > abraten sich mit den AVRs zu beschäftiten. Das mache ich seit ich dass Gefühl habe, dass Atmel Einzelnutzer und Kleinmengenabnehmer richtiggehend hasst. > Und die Mittelständler sind > dann auch gut beraten sich schleunigst um eine Umstellung zu kümmern. > Eine Firma wo einzig die Großkunden zählen ist kein verlässlicher > Partner. Mikrocontroller gibt es mittlerweile wie Sand am Meer. Ob ich für eine 100er-Serie nun $1 oder $2 ist nun auch sowas von egal. Proprietäre Tools und Protokolle sind dagegen ein erhebliches Geschäftsrisiko. > Als kleiner habe ich andere Belange als die Großen und müsste > jederzeit mit einer Entscheidung rechnen die mich ohne Vorwarnung vor > die Wand fahren lässt. Siehe oben, erhebliches Geschäftsrisiko. Kleiner Spaß am Rande: Welcher uralte, aber populäre AVR wird laut Release-Note von der Kombination Studio 5 + AVR Dragon nicht mehr unterstützt? Nah? Richtig, der Mega8 (AVR Studio 5: Release 5.0.1038, Seite 8).
Oh Mann!!! schrieb: > Ich kann irgendwie das NET Framework nicht installieren, weder manuell > noch im Paket. Kommt immer die Meldung: > > "Algemeiner Vertrauensfehler" > > Ich habe schon versucht es direkt von Microsoft mit dem IE zu > downloaden, trotzdem der gleiche Fehler. > > Was läuft das falsch? Ist doch einfach: Dein Rechner traut Dir nicht zu!
Hi >Welcher uralte, aber populäre AVR wird laut >Release-Note von der Kombination Studio 5 + AVR Dragon nicht mehr >unterstützt? >Nah? >Richtig, der Mega8 (AVR Studio 5: Release 5.0.1038, Seite 8). Der ist lediglich unter Anfängern populär. Den würde ich, da es bessere Alternativen gibt, nur noch unter Zwang einsetzen. Aber trotzdem nette Verschwörungstheorie. MfG Spess
Carsten Sch. schrieb: > Ich hoffe nicht das wirklich diese Gedankengänke bei Atmel > dahinterstecken. Auch wenn die Hinweise immer öfter in diese Richtung > gehen. Wenn dem so währe dann müsste man jedem Anfänger sofort davon > abraten sich mit den AVRs zu beschäftiten. Und die Mittelständler sind > dann auch gut beraten sich schleunigst um eine Umstellung zu kümmern. > Eine Firma wo einzig die Großkunden zählen ist kein verlässlicher > Partner. Als kleiner habe ich andere Belange als die Großen und müsste > jederzeit mit einer Entscheidung rechnen die mich ohne Vorwarnung vor > die Wand fahren lässt. Es gibt da noch ein anderes Problem: Verfügbarkeit. Atmel hat jetzt nur noch eine einzige Fab in Colorado, in der sie Automotive-Zeugs fertigen. Versucht mal, Atmel Dataflashes zu kaufen. Hihi. Schweigen im Walde. Ich für meinen Teil habe Konsequenzen gezogen. Andere Mütter haben auch schöne Töchter. Und Microchip hat eigene Fabs und kann liefern. Und ein dsPIC ist auch eine nette Sache. fchk
Der Aktienkurs von Atmel hat sich seit Oktober fast verdoppelt. Vielleicht ist ja mal wieder eine Übernahme geplant und sie haben die Braut hübsch gemacht.
Hi, IchNix schrieb: > Richtig, der Mega8 (AVR Studio 5: Release 5.0.1038, Seite 8). Ist jetzt nicht wahr, oder??? Das gibt es doch nicht! Vor allem nicht das es wohl nicht den geringsten technischen Grund dafür gibt. Kündigt sich da eine Abkündigung an? spess53 schrieb: > Der ist lediglich unter Anfängern populär. Den würde ich, da es > bessere Alternativen gibt, nur noch unter Zwang einsetzen. Aber trotzdem > nette Verschwörungstheorie. Natürlich ahst du recht, wenn du sagst das die Anfänger die Haubtabnehmer sind. Im Profibereich wird den wohl niemand mehr für neue Designs einsetzen. Es gibt bessere Controller für weniger Geld. ABER: Es kommt doch mal vor das eine Firmware für alte Designs überarbeitet werden muss. So habe ich zum Beispiel bestimmt seit 5Jahren keinen neuen PIC16F84 mehr verbaut. Aber mehrmals im Jahr bearbeite ich noch Firmware die dann für den 16F84 übersetzt wird. Und ich denke das wird doch in so einigen Mittelständischen Firmen so sein. Allerdings eher weniger in den Firmen die MAsse produzieren als in denen die auf wenige hochwertige - sehr spezielle - Lösungen setzen. Aber wenn Atmel diese Kunden nicht mehr nötig hat... Und - ja ich sehe diesen Schritt als wirklich Anfängerfeindlich an. Nicht wenige machen doch ihre ersten Schritte mit dem Nachbau bestehender Projekte und sukzessiver Änderung bevor die mit ganz neuen eigenen Projekten anfangen. Und gerade bei diesen Projekten sind ganz oft noch MEGA8 eingesetzt. Natürlich kann man mit nur wenigen änderungen auch andere AVRs einsetzen. Z.B. den ´88er. Aber für denjenigen der den allerersten Kontakt mit µC hat kann diese Codeänderung schon etwas schwieriger sein. Und genau diese Trifft es also. Ich glaube aber nicht das jemand so dumm sein kann udn das bewusst so zu planen. Denn die Gruppe die man damit verprellt das sind die Einsteiger in der Frühphase. Diejeniegen die noch kaum Ausstattung und Spezialwissen haben und noch ohne mit der Wimper zu zucken auf jeden Beliebigen anderen Controllerhersteller umschwenken können. Aber dazu passt es auch das es immer noch problemlos möglich ist die Controller zu "verfusen" was jedem Bastler hin wieder mal passiert. Wenn man wollte hätte man das schon längst abstellen können. Will man aber wohl nicht - die Großkunden haben damit eher kein Problem. Das sind die Bastler insbesondere die Einsteiger! Aber ich habe ja auch meine Schlüsse daraus gezogen. ICh bin damals mit den PIC angefangen als von AVR noch keine REde war. Bin dann auf Atmel umgeschwenkt und als die erste Euphorie verflogen war wieder reumütig zu den PICs als Vorzugscontroller zurückgekehrt. Nicht weil die unbedingt technisch besser sind. Die sind schon gleichwertig.(Wobei die Pics mittlerweile die bessere Peripherieauswahl haben, damals aber noch nicht so...) Aber der Umgang mit den Kunden incl. das Bereitstellen von Informationen und die Verlässlichkeit bei Lieferungen ist bei Microchip eine ganz andere Nummer. Das sieht man auch bei den Dev. Tools. Bei Atmel sind die anscheinend selbst wieder als Einnahmequelle ausgelegt. Bei Microchip -und nicht wenigen anderen!- aber sind zumindest die einfachen sehr knapp kalkuliert -nahe an der Nullnummer. Und das ist nicht aus Sorge um die Großkunden sondern einzig nur um die kleinen für sich zu gewinnen. Denn wie schon geschrieben: Aus dem Heer der tausenden Kleinen kommen schließlich auch die meisten der wenigen Großkunden. Wen man als kleinen Verprellt hat -den bekommt auch nicht wieder zurück wenn der Groß geworden ist! Thomas Decker schrieb: > Was regt ihr euch denn alle auf? Die Anforderungen stehen doch so nur > auf dem Papier. Es wurde doch schon geschrieben, dass ein gestartetes > Studio5 nicht 1 oder 1GB sondern nur ~50MB Ram belegt (+ bisschen was > von .NET und so vielleicht noch). Das sind doch nur pauschale Angaben. Ich frage mich gerade was besser ist: Das die Software zwar meistens nur weng Ram braucht, aber bei speziellen Situationen plötzlich Speicherhungrig wird und dann instabil wird wenn nicht genug Speicher da ist. Also wirklich die Anforderungen korrekt angeschrieben sind. ODER: Der Halbleiterhersteller Atmel kennt die Anforderungen seiner eigenen IDE nicht und schätzt diese so falsch ein! Das flösst dann echt Vertrauen in die Produkte ein. Naja: Wie gesagt- das die IDE jetzt so groß ist das ist jetzt nicht wirklich das riesenproblem. Kritisch ist aber wohl der Gedankengang bzw. die Einstellung die da hinter steckt. Gruß Carsten
Carsten Sch. schrieb: > ABER: Es kommt doch mal vor das eine Firmware für alte Designs > überarbeitet werden muss. Wobei ich es für sinnvoll halte, für alte Konstruktionen die ursprünglich verwendete Entwicklungsumgebung zu konservieren, jedenfalls aber den damals verwendeten Compiler. Um Schmutzeffekte durch ggf. wachsenden Code und neue Bugs zu vermeiden.
An alle Verschwörungstheoretiker, die jetzt glauben auf ihren geliebten Atmega8 verzichten zu müssen: siehe Anhang. mfg.
Fortsetzung von eben: Das ist auch ein Motiv, für sowas eine spezifische VM zu bauen. Die VM ist auch dann noch einsetzbar, wenn der Originalrechner mitsamt IDE längst perdü ist.
Von den "3GB of available hard disk space" gehen doch schon mal 1,3GB für das Visual Studio drauf. Damit hat Atmel wirklich den Vogel abgeschossen! Ich habe schon garkeine Lust mehr die Installation fortzusetzen. Wenn Atmel nicht in der Lage ist, kleine und effiziente Software zu schreiben (wozu die Leute die das AVR Studio nutzen wollen gezwungen sind), wie sieht es dann sonst noch mit der Qualität aus?
Pete K. schrieb: > Der Aktienkurs von Atmel hat sich seit Oktober fast verdoppelt. > Vielleicht ist ja mal wieder eine Übernahme geplant und sie haben die > Braut hübsch gemacht. Hmm, das soll eher aufgrund des Booms bei Touchscreens sein. Atmel hat sich kurz bevor der Boom bei Smartphones mit Touchscreens richtig los ging einen Hersteller von Touchscreen-Chips einverleibt. Die Verkaufszahlen dieser Chips sollen dann mit dem Boom durch die Decke gegangen sein.
IchNix schrieb: > Kleiner Spaß am Rande: Welcher uralte, aber populäre AVR wird laut > Release-Note von der Kombination Studio 5 + AVR Dragon nicht mehr > unterstützt? Thomas Eckmann schrieb: > An alle Verschwörungstheoretiker, die jetzt glauben auf ihren geliebten > Atmega8 verzichten zu müssen: siehe Anhang. Dann sag ich auch mal "Siehe Anhang", Seite 8. spess53 schrieb: > Der ist lediglich unter Anfängern populär. Den würde ich, da es > bessere Alternativen gibt, nur noch unter Zwang einsetzen. Noch ein Kind der Wegwerfgesellschaft. Der wird x-fach in Produkten eingesetzt, die gelegentlich ein Firmware-Update brauchen und bei denen sich neue Hardware nicht rechnet, besonders nicht, wenn man sie durch irgendwelche Zulassungen bringen muss. Neu würde ich den, wie andere AVRs auch, nicht einsetzen.
IchNix schrieb: > Dann sag ich auch mal "Siehe Anhang", Seite 8. Und was steht da? Daß man den Atmega8 mit AVRISP und STK600 programmieren kann. Bis auf den Simulator, den gibt es noch nicht, funktioniert alles. Das Studio 5 ist eine Betaversion. Da ist noch nicht alles drin. mfg.
Thomas Eckmann schrieb: > Und was steht da? Und was schrieb ich? > Kombination Studio 5 + AVR Dragon Worauf dann prompt eine Verschwörungstheorie unterstellt wurde.
Oh mann, die Verschwörungstheorien sind echt der Hammer... Fehlt nur noch die Verbindung zur Guttenberg-Affäre und der Libyen-Krise... Warum sollte Atmel denn die kleinen Nutzer mit Abnahmemengen von Stückzahl 1 hassen? Immerhin stellen sie seit Jahren eine völlig kostenlose IDE zur Verfügung, die jeder nutzen kann. Auch die Programmer kosten nicht die Welt. Ich persönlich freue mich auf AVR Studio 5 und hoffe auf eine baldige Veröffentlichung der Final-Version. Und mal zum Thema Ressourcen: Ich glaube die heutigen Schüler haben viel bessere Rechner zu Hause als ich ;-) Und während ein hoher Ressourcenverbauch bei einem Computerspiel nahezu schon ein prädikat für seine Hochwertigkeit ist, wird es hier zum Mittelpunkt all unserer Probleme... Leute kommt mal klar - kann es denn sein, dass es soviel kritik an etwas gibt das gratis ist? Geht doch zum PIC, dann ist hier wenigstens Ruhe :-)
Sebastian M. schrieb: > hi, > > hat denn nun schon jemand das studio 5 dazu gebracht, c++ zu übersetzen? Läuft doch super, auch in einer VM. Allerdings sind noch ein paar Lücken in bezug auf das AVR32-Studio, wenn es um die Textformatierung und Sprünge zur Definition geht (bei MS-Visual Studio läuft das gut). Viiiiiieeeeeel besser sind aber die Prozessoransicht und die IO View, ähnlich wie bei AVR-Studio 4. Das AVR32-Studio war hier doch sehr bescheiden. Von mir eine 1* - in ca. 1 Jahr werde ich wohl ganz umsteigen. Und zum Platzproblem - hat von den Meckerern schon mal jemand einen Linux-kernel für einen µC gebastelt? - wohl eher nicht... Gruß UC3
"Jungs und ihre Spielzeuge..." (JB007 Goldeneye) Sonst gehts Euch allen noch gut? Das ist eine Beta-Version. Da packt man erstmal alles ohne Rücksicht auf Verluste rein, optimiert wird später! Es wird doch hier niemand gezwungen, das Tool einzusetzen. Wer nicht will der hat. Es gibt immer noch die alte Version 4 und die unterstützt die ganzen alten DIL-Bausteine, auf die Ihr so versessen seid. Reicht doch. Wer mehr will, und vor allem neue Teile einsetzen will, der steigt halt um. Der Rest bleibt bei 4.xx.
Kurt Bohnen schrieb: > Ich habe schon garkeine Lust mehr die Installation > fortzusetzen. Da wird Dir wohl nichts anderes übrig bleiben. Abbrechen der Installation wird nämlich auch nicht unterstützt: Report #9879: Canceling the installation - failed. The installer does not respond to canceling Quelle: http://www.mikrocontroller.net/attachment/102946/as5installer_stable-5.0.1038-readme-1.pdf
Ich gehe davon aus, dass die 4.x-Versionen noch lange Zeit erhalten bleiben werden. Die VSS-basierte Version 5 ist sicherlich ein "Testballon", um zu sehen, ob bzw. wie sich Microsoft Visual Studio besser im Embedded-Bereich etablieren lässt. Microsoft verstärkt dort ja auch ganz massiv sein Engagement. Und für die Windows-CE- und -Mobile-Entwicklung ist Visual Studio nun einmal die Entwicklungsumgebung der Wahl, egal ob man Microsoft toll findet oder nicht. Ich halte es für sehr wahrscheinlich, dass Microsoft auch stärker im Low-End-Bereich (.NET Micro) Fuß fassen will und daher mit wichtigen Halbleiterherstellern Allianzen schmieded. Gerade in Großunternehmen stoßen ja "unbekannte" Softwarepakete schnell auf Unmut der IT-Abteilungen, wohingegen Microsoft-Produkte ungesehen akzeptiert werden. Somit ist die administrative Hürde wesentlich geringer.
Ich verstehe das echt nicht. Gut. Der Installer ist groß. Guckt euch mal ISE an. Dann bekommt ihr das kotzen. Ich finde das Visual Studio eine sehr schöne Entwicklungsumgebung. Ich programmiere darin auch in C++, C# und Visual Basic und finde es schön, dass jetzt auch noch der AVR dazukommt. Dass man für 300 Euro keinen Computer bekommt, der das schafft, glaube ich nicht: 100€ Prozessor (Irgend ein billiger Dual/Quad von AMD) 50€ Mainboard (da reicht das billigste) 100€ Festplatte, Laufwerke, ... 50€ Gehäuse, Tastatur, Maus Bildschirm wird man wohl haben. Dass man alle sechs Monate den Computer wechseln sollte ist ein Mythos. Mein Computer (Laptop!) ist fast zwei Jahre als und schafft dennoch Visual Studio (sogar Crysis geht...). Und auch auf dem Rechner davor habe ich schon VB gecodet. Schön, dass die mittelalterliche GUI endlich abgelöst wird. Und alle anderen sollen doch Eclipse oder GCC nutzen! DANKE ATMEL! Mit freundlichen Grüßen, Valentin Buck
Ich kann mich Valentin nur anschließen. Das alte AVR Studio war von der Bedienung und der GUI her echt nicht das Gelbe vom Ei. Visual Studio hingegen ist eine erstklassige IDE. Leider ist der Atmel Server wohl sehr langsam ( 20 kb/sec ), da dauert es wohl noch ein paar Stunden bis ich das testen kann.
Ist ja zum Glück noch alles Beta. Das Frontend ist zwar hübsch aufgemotzt aber unter der Haube sind noch viele Baustellen offen, oder dort wurde noch nicht mal angefangen ;)
IchNix schrieb: > Ironischerweise ist diese IDE dann noch aus kostenlosen Teilen > zusammengeklaubt, Visual Affenzirkus ist wirklich kostenlos (wenn man ihn im eigenen Produkt weiter vertreiben möchte)? Kann ich mir beim Hause Microsoft nicht so recht vorstellen. > aber gerüchtweise mag Atmel die an gcc vorgenommenen > Änderungen nicht so ohne weiteres ans gcc-Projekt zurückgeben. Das ist Quark. Du kannst ihnen vielleicht vorwerfen, dass sie, seit es kein WinAVR mehr gibt, ihre Patches nicht ordentlich publik gemacht haben (aber das hat Eric selbst bei WinAVR immer nur zögerlich im Nachgang geschafft, vornehmlich aus Zeitgründen), aber falls du auf die Xmega- und AVR-32-Patches anspielst: dass diese sich nicht schon längst im Tree des GCC wiederfinden, hat sich die FSF mit ihrer (sorry) saudämlichen Anforderung, dass nur Code in den GCC-Tree darf, für den man eine Copyright-Abtretungserklärung unterzeichnet hat, selbst zuzuschreiben. Frag mal Georg Johann, wie lange es gedauert hat, bis er diesen Blödfug endlich in Sack und Tüten bekommen hat (der für einen europäischen Autor ob des sich vom US-amerikanischen Copyright fundamental unterscheidenden hiesigen Urheberrechts ohnehin juristisch komplett gegenstandslos ist), und dann extrapoliere von dieser Zeit mal, wie lange es dauert, bis sich ein Laden wie Atmel mit einer ausgeprägten Rechtsabteilung in dieser Hinsicht mit der FSF handelseinig geworden ist.
Hat schon jemand AVR 5 heruntergeladen? Der Hammer ist, das nur mit 19kb/s der Download geladen werden kann. Find ich von ATMEL richtig frech! Wenn denn einer schon irgendwo auf seinem Rechner oder Server hat könnter er diesen vllt. Bereitstellen?
Ja, mich nervt das auch ... 24 kb/sec habe ich im moment. Die hätten sich überlegen sollen, das ganze als Torrent anzubieten, wenn sie schon so geizig sind g
Wenn sich jemand mit dem Studio5 intensiv beschäftigt, soll er bitte mal Posen welche Einsellungen nötg gewesen sind bis es lief! Wollte vorhin nur einmal ein DDRA = 0; kompilieren, schon wusste das Ding nicht was DDRA ist, obwohl in der Vorlage das <avr\io.h> bereits includet wird! Merkwürdig...
Dennis schrieb: > Benutzt doch einen Downloadmanager. Ich zieh mit über 200kb/s. ...und nutzt den direkten Link: http://www.atmel.com/dyn/resources/prod_documents/avrstudio5.0.beta.exe Gruß...Maschinist
@Knut Also ich hab ein komplettes Projekt übernommen (händisch) und es hat eigentlich alles geklappt. Einzig das anscheinende "Fehlen" des F_CPU Eintrags macht ein wenig Probleme, da bei delays die richtige Freq nicht vorhanden ist. Alles andere wie Debuggen (mkII) und Proggen funzt einwandfrei. Der I/O View ist meines Erachtens besser geworden und auch die "Intellisense" ist gut, sie ist zwar noch nicht so gut wie beim orig. VS, aber das wird schon werden. Was mir noch sehr fehlt ist das automatische einrücken wenn man eine Funktion mit der geschwungenen Klammer schließt. Das ist bei VS einfach genial und MUSS drin sein. "Go to Definition" wäre auch nicht verkehrt wenn es rein käme. Allgemein muss ich sagen, dass es wirklich noch ne Beta ist, aber das wird sehr gut werden. Ich verstehe auch nicht warum man sich über 500MB aufregt. Heute ist es eben so, dass jede SW riesig ist. Lieber 500MB runter ziehen und dann besser arbeiten können, als 150MB und bei jeder Zeile aufregen weil Grundfunktionen nicht drin sind. Alle anderen können ja mir VI weiter proggen gg So denn, Gruß MB
Günter Rudigier schrieb: > Proggen funzt Komisch, ich kann Leute die proggen und funzt sagen nicht ernst nehmen.
@IchNix Was hab ich geschrieben was du nicht glaubst bzw. was davon kann man nicht ernst nehmen. Ich hab wenigstens die Beta ausprobiert und meine Meinung dazu nieder geschrieben. 99% der Nörgler hier haben sie noch nicht mal installiert und bilden sich dann schon eine Meinung. Ich find das ein wenig "ärmlich"...
Günter Rudigier schrieb: > Was hab ich geschrieben was du nicht glaubst Dass das "Proggen funzt". ;-)
Jörg Wunsch schrieb: > Günter Rudigier schrieb: >> Was hab ich geschrieben was du nicht glaubst > > Dass das "Proggen funzt". ;-) Nur um es klar zu stellen: Ich meinte damit, dass die verschiedenen Programmer problemlos FUNKTIONIEREN gg Aber egal, ich finde das neue Studio gut. Das alte war ja wirklich eine mittlere Katastrophe. Wenn es keine Alternativen geben hätte wär ich heute sicher grau aufm Kopf...
Wieso kann man eig den Atmega8/16 nicht simulieren? Weiß man da was? Und wieso kann man im AVR Assembler registerdefinitionen nicht autovervollständigen. z.B .def Hallo = r16 Ha Str-Leer wird nichts gefunden ???
Knut schrieb: > Müssen noch irgendwelche Pfade eingestellt werden? Ich hab nix eingestellt. Einfach "New Project" -> "Empty AVR GCC Project" -> "Controller auswählen" -> fertig. Danach hast du automatisch die leere main und ein paar Kommentare sind drin. Viel mehr kann ich dir nicht sagen, hab auch nicht viel mehr gemacht...
Ich weiß gar nicht was ihr habt wegen dem Atmega8. Der war schon alt als ich mit AVRs begonnen habe. Es gibt genügend aktuelle Pin-kompatible Modelle, die den Atmega8 ablösen. Ich nutz z.B. den Atmega88 und der wird voll unterstützt. Hobby-Bastler haben da meiner Meinung nach nichts zu befürchten.
Günter Rudigier schrieb: > Einzig das anscheinende "Fehlen" des F_CPU > > Eintrags macht ein wenig Probleme Das habe ich Atmel vorgestern nachmittag mitgeteilt. Gestern morgen bekam ich Antwort vom Support, daß das in die Buglist aufgenommen ist. Die Email hatte ich übrigends nur mit meinem Namen unterschrieben. Das auch mal zum Thema "Atmel liebt uns nicht mehr". Günter Rudigier schrieb: > "Go to Definition" Immerhin ist aber oben links ein Feld, wo man die Funktionen angezeigt bekommt und direkt anklicken kann. Vielleicht verbinden sie das ja noch mit der rechten Maustaste. Koal schrieb: > Wieso kann man eig den Atmega8/16 nicht simulieren? Ich denke mal, das muss NOCH nicht heissen. Günter Rudigier schrieb: > Ich hab nix eingestellt. Einfach "New Project" -> "Empty AVR GCC > > Project" -> "Controller auswählen" -> fertig. Danach hast du automatisch > > die leere main und ein paar Kommentare sind drin. Habe ich genauso gemacht: Läuft. Debuggen mit JTAGICE: Kein Problem. Das war allerdings nur auf meinem Desktop so. Auf meinem Notebook stürzte das Programm ab, sowie ich etwas angeklickt habe. Habe dann Windows Update laufen lassen und 41 Updates später lief es dann. Lag damit wohl eher an Visual Studio. mfg.
soundso schrieb: > Wehrmutstropfen: > > AVR Studio 5 Beta installiert sich nicht auf Win7 64Bit ... doch ... ich hab es auf Win7 64 Bit laufen, ohne Probleme. Installation lief auch einwandfrei.
Michael Köhler schrieb: > Ich weiß gar nicht was ihr habt wegen dem Atmega8 Der ist die Referenz hier und auf vielen Pollin und Consorten Boards ist der auch drauf. Da die meisten Hobbyisten sowieso keinen Debugger haben, ist denen das auch egal, daß der kein Debug-Wire kann. Für mich ist allein das ein absolutes Kill-Kriterium. Es müsste sich mal jemand finden, der das gesamte Tutorial auf Atmega 88 umstellt. Aber das müsstest du dann machen. Ich habe da nämlich auch keine Lust zu. Und wenn man damit fertig ist, ist der auch obsolet. mfg.
Thomas Eckmann schrieb: > Da die meisten Hobbyisten sowieso keinen Debugger haben, > ist denen das auch egal, daß der kein Debug-Wire kann. Für mich ist > allein das ein absolutes Kill-Kriterium. Geht mir genauso. Das Problem bemerkt man erst, wenn man sich doch mal einen Debugger angeschafft hat, dann will man plötzlich nicht mehr mit den Alt-Beständen an Mega8 arbeiten. > Es müsste sich mal jemand finden, der das gesamte Tutorial auf Atmega 88 > umstellt. Aber das müsstest du dann machen. Ich habe da nämlich auch > keine Lust zu. Kommen im GCC-Tutorial nicht auch noch häufig Register aus dem noch älteren AT90xxx vor?
Ich weiss nicht warum sich hier immer welche über die geringe Downloadgeschwindigkeit beschweren. Klar 500MB bei 20kB/s machen keinen Spass, aber es wurde ja schon mehrfach vorgeschlagen, einen Downloadmanager zu verwenden. Die gibts auch als portable version, dann muss man nicht mal etwas installieren. Habe das Paket heute morgen mit 2MB/s laden können.
Thomas Eckmann schrieb: > Immer dasselbe dumme Gesülze, wenn irgendwas neues kommt. > > Zu groß, zu viele Resourcen, ich benutze sowieso noch die Version von > vorgestern, bla, bla, bla. > > mfg. Der einzig sinnvolle Kommentar bisher
Und was ist mit dem Atmega16? Den 32 kann man ja auch nicht simulieren und welche Alternativen habe ich da? Im Prinzip läuft ja der Simulator im AVR Studio4 für den 8, 16, usw..., wieso ist das so schwer den ins neue Studio zu implementieren?
> Im Prinzip läuft ja der Simulator im AVR Studio4 für den 8, 16, usw..., > wieso ist das so schwer den ins neue Studio zu implementieren? Geduld, Geduld - die Beta-Dummies werden's schon herausfinden. Einfach auf die endgültige Version warten :)
Thomas Eckmann schrieb: > Es müsste sich mal jemand finden, der das gesamte Tutorial auf Atmega 88 > umstellt. Aber das müsstest du dann machen. Ich habe da nämlich auch > keine Lust zu. Das Tutorial umzustellen ist ja nun nicht wirklich das Ding, ist höchstens Zeitaufwendig aber sicher nicht kompliziert. Wie gesagt, ich hab den Atmega8 erst gar nicht verwendet, mich aber hier mit dem Tutorial zu diesem an die AVRs rangewagt. Die drei Register (Hausnummer, kein wahrer Wert), die beim Atmega88 etwas anders aufgebaut sind als beim Atmega8 sind nun wirklich nicht das Ding. Der Blick ins Datenblatt hilft hierbei ungemein. Ich mein, ein Amiga war seinerzeit auch ganz toll, ernsthaft verwendet wird der, wenn überhaupt noch, von Retro-Liebhabern.
Andy S schrieb: > wieso ist das so schwer den ins neue Studio zu implementieren? Weil die alten AVRs einen mehr oder minder handgefeilten Simulator benutzt haben. Diesen hat man (noch?) nicht auf AVR Studio 5 portiert, da offenbar (das kann man im englischen Thread auf avrfreaks.net nachlesen) das Debugging-Backend seinerzeit bereits multiplattformfähig implementiert worden ist, und der alte Code dafür nicht geeignet war/ist. Damit gibt's bislang nur das, was sich im AVR Studio 4 "Simulator V2" nannte. Dabei handelt es sich um eine maschinengenerierte Simulation, die auf dem HDL-Code des tatsächlichen ICs basiert, und diese Simulation ist offenbar auch plattformunabhängig realisiert. Die gute Nachricht dabei ist, dass das Debugging-Backend auch in der Windowsversion so weit entkoppelt ist, dass es einen eigenen Prozess belegt, und dass es darob Chancen gibt, dass Atmel vom Debugging- Backend vielleicht auch mal Releases für zumindest Linux und MacOS X machen könnte (binary only, kein Sourcecode).
LoL, das Ding ignoriert .cpp Dateien - die werden nicht compiliert und auch im Editor nicht mit Syntax-Highlighting versehen. Auch dann nicht, wenn man sie dem Projekt hinzufügt und explizit "Compile" für "Build Action" auswählt. => Kann man in die Tonne treten, besser man bleibt bei Eclipse
Andreas schrieb: > LoL, das Ding ignoriert .cpp Dateien - die werden nicht compiliert und > auch im Editor nicht mit Syntax-Highlighting versehen. Auch dann nicht, > wenn man sie dem Projekt hinzufügt und explizit "Compile" für "Build > Action" auswählt. > > => Kann man in die Tonne treten, besser man bleibt bei Eclipse LOL gibz dass? total verbuggt!! die beta. OMG!!
Hmm, kann es sein, dass es bei der Simulation auch bugs mit sich trägt? Ich simuliere z.B. den Atmega644P mit dem Coding im Anhang. Bei dieser Stelle:
1 | /Mein-Loop################################################### |
2 | while(1) |
3 | {
|
4 | sensoren_RE = PIND; |
5 | sensoren_LI = PINC; |
zeigt er mir immer 0 für beide Sensoren an auch wenn ich PIND und PINC im IO View ändere. Manchmal streicht er mir auch meine Änderungen raus und PINC wird zu 0 im IO View... Irgendwie komische Geschichte. Lieg das am Studio5? lg andy
Jörg Wunsch schrieb: > da offenbar (das kann man im englischen Thread auf > avrfreaks.net nachlesen) das Debugging-Backend seinerzeit bereits > multiplattformfähig implementiert worden ist, und der alte Code > dafür nicht geeignet war/ist. Was ist denn nun Multiplattformfähig? Bezog sich dein Kommentar auf die µControllerfamilien oder auf das Betriebssystem auf der die IDE läuft? mf
Mini Float schrieb: > Jörg Wunsch schrieb: >> da offenbar (das kann man im englischen Thread auf >> avrfreaks.net nachlesen) das Debugging-Backend seinerzeit bereits >> multiplattformfähig implementiert worden ist, und der alte Code >> dafür nicht geeignet war/ist. > > Was ist denn nun Multiplattformfähig? Das "Debugging Backend", also Simulator + Anbindung an die Emulatoren. Allerdings bislang offenbar nur intern bei Atmel; entsprechende Binaries für Linux oder MacOS X gibt es noch nicht, könnte es aber geben. Es wird wohl auch in Erwägung gezogen, sowas ggf. mal heraus zu geben, allerdings hat es keine hohe Priorität. > Bezog sich dein Kommentar auf die µControllerfamilien oder auf das > Betriebssystem auf der die IDE läuft? Betriebssystem ja, aber keine IDE. Die hamm'se fest an .NET und damit Winzigweich gebunden (so fest, dass sie dank MS's Policy nichtmal unter Wine laufen kann). p.s.: Nachzulesen in Roland Kruses Kommentar hier: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=103949&start=140#802119
Michael Köhler schrieb: > Ich weiß gar nicht was ihr habt wegen dem Atmega8. Der war schon alt als > ich mit AVRs begonnen habe. Wen interessiert wann du mit AVRs begonnen hast? > Es gibt genügend aktuelle Pin-kompatible Modelle, die den Atmega8 ablösen. > Ich nutz z.B. den Atmega88 Pinkompatibel aber nicht funktionskompatibel. Zum Beispiel ist die interne Spannungsreferenz des 88 kleiner als die des 8. Zahlst du für das Redesign des analogen Frontends das deswegen notwendig werden kann? Zahlst du für die dann notwendige Neuzulassung der Baugruppe? Also urteile nicht über Dinge, von denen du nichts verstehst.
Mit den "aufgeblasenen Ressourcen" geht wohl Atmel den Weg den ja alle gehen, das ist wohl der Lauf der Zeit den wir nicht aufhalten können. Wegen der Kompatiplität gegenüber älterer Harware (STKxxx) ist es auch nix neues wenn man Anwendungen anderer Hersteller nimmt , diese bedienen auch nicht mehr ältere Hardware, die bei diesem oder jenen noch ans herz gewachsen ist. Ich konnte die Version 5 leider nicht testen, es geht nicht unter XP-Prof. Sp3 bei mir zu intallieren.(komisch) Der Download lief eigendlich normal mit 350..380Kb/sec unter DSL-6000. Werde es vesuchen zu testen, weiss nur nicht warum es nichtinstallierbar ist. Vieleicht passen einige Dll's nicht, die auf meinen Programmier-PC wohl in Hülle und Fülle von anderen Anwendungen und MS zu finden sind, oder gar der Virenschutz, mal sehen was wird.. Kann es aber wegen dem STK 500 sowieso nicht recht einsetzen.. GRuss Gerhard
chNix schrieb: > Wen interessiert wann du mit AVRs begonnen hast? Es ging nicht darum, wann ich mit AVRs begonnen hab sondern wie einfach oder schwer das Tutorial, welches für den Atmega 8 geschrieben wurde, auf einen aktuelleren Atmega, wie dem 88er, übertragbar ist und ich finde, das ist sehr sehr leicht. Gesteh mir meine Meinung wenigstens zu. IchNix schrieb: > Pinkompatibel aber nicht funktionskompatibel. Zum Beispiel ist die > interne Spannungsreferenz des 88 kleiner als die des 8. Zahlst du für > das Redesign des analogen Frontends das deswegen notwendig werden kann? > Zahlst du für die dann notwendige Neuzulassung der Baugruppe? Ah, ich dachte ja, es geht hier um *Neuentwicklungen" und nicht um Dinge, die es schon gibt. Irgendwie ist mir das Forum grad nicht so recht suspekt...
Gerhard Hinze schrieb: > Ich konnte die Version 5 leider nicht testen, es geht nicht unter > > XP-Prof. Sp3 bei mir zu intallieren.(komisch) Bei mir funktionierte die Installation unter WinXP 32 Prof. mit SP3. Läuft bei mir in einer virtuellen Maschine (VMWare) unter XP64 als Host. Ein erstes (älteres) ASM Project (ATtiny13) ließ sich übersetzen und auch simulieren. Läuft auch parallel zum AVRStudio v4.18. Gruss Thomas
IchNix schrieb: > Atmel möchte, dass sich die > "Freaks" mit ihrem Linux gefälligst zum Teufel scheren. Eine weise Entscheidung, dieses "LinuxWuselZeug" braucht sowieso kein Mensch
Die ganze "Aufregung" über die Beta-Version von von Studio 5 (Bananen-Version, reift beim Kunden) ist für mich recht interessant, nur sollte die an Atmel weitergeleitet werden. DORT sitzen nämlich "diejenigen die Schuld sind". Und die lesen vermutlich nicht in einem deutschsprachigen Forum mit. "Die Atmels" wären vielleicht doch an der einen oder anderen Anregung interessiert. Vielleicht ist ja einer der Moderatoren so freundlich und "schiebt" (falls möglich (technisch und rechtlich)) die Diskussion den Atemel-Entwicklern ins Postfach. Danke schon mal für die Mühe. Für mich kommt wg. STK500 Studio 5 in der momentanen Version auch nicht in Betracht, werde aber diese Diskussion mit Interesse weiter verfolgen. Ein wunderschönes Wochenende!
Dem AVR Studio 4.x muss man ja nun keine Träne hinterherweinen, der Editor hatte immer ein paar unangenehme Fehler. Wenn man einen Block markiert und rückt ein, wird dadurch die Ende-Markierung geändert. Wenn man mit Alt-Buchstabe ins Menü geht und dann die Cursor-Tasten benutzt bewegt sich der Cursor im Editor-Fenster und nicht im Menü. Das Navigieren zwischen den Tabs mehrerer geöffneter Dateien war umständlich. Für das Debuggen war es ok, aber keine tolle IDE. Für die AVR32 brauchte man bisher Toolchain, IDE + Framework und das Erstellen von Anwendungen für ein nicht unterstütztes Board war auch nicht trivial. Mal sehen, vieleicht bewährt sich die IDE ja an der Stelle. Ein deutlicher Mehrwert ist zunächstmal für diejenigen sichtbar, deren Target xmega oder AVR32UC3 ist und die vorzugsweise EVK11xx oder STK600 oder xplain benutzen. </Meinung>
AVR-Studio 5 ist IMHO nicht mehr aufzuhalten. Die Frage ist, was diejenigen wollen, die Alternativen möchten oder brauchen. In Bezug auf den Standalone C-Compiler unter Windows bräuchte man eine Weiterentwicklung des WinAVR, die ja derzeit schläft. ABER eventuell kann sich das ändern - und zwar mit deiner Hilfe! Eric hat auf avrfreaks.net eine Umfrage laufen, ob die WinAVR Entwicklung wieder aufgenommen werden soll.... http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=104045
Ein Mango gibts doch! Atmega32 fehlt im Simulator warum auch immer. Sowas find eifach schwach von Atmel.
Hi >Ein Mango gibts doch Wenn schon, dann eine Mango. Und wer dem ATMega32 nachheult hätte eigentlich beim AVR-Studio 3.xx bleiben können. MfG Spess
Eine Entwicklungsumgebung für AVR und AVR32 AVR Studio 5 von Atmel ist eine neue Entwicklungsumgebung, die eine Kombination aus AVR Studio 4 und AVR32 Studio darstellt und sämtliche 8- und 32-Bit-Mikrocontroller der Baureihe AVR unterstützt. AVR Studio 5 erleichtert das Editieren sowie das Debugging von Source-Code dank folgender Neuerungen: Assisted Code-Writing, das heißt, dass der neue Editor den Entwickler beim Programmieren unterstützt, indem er ihm Vorschläge bezüglich des Codes macht; ein Wizard für das schnelle Anlegen und Entwerfen neuer Projekte; eine Source-Code-Bibliothek für das AVR Software Framework; einen GNU-C/C++-Compiler; einen Simulator und ein Frontend-Visualisierer für sämtliche AVR-Programmiergeräte und In-Circuit-Debugger von Atmel. Das Tool ermöglicht dem Anwender außerdem einen leichten Zugang zu Online-Dokumentationsmaterial wie Datenblätter, Bedienungsanleitungen und Handbücher für die Tools, dokumentierte Beispiel-Projekte sowie Einkaufsmöglichkeiten für Kits direkt im Atmel Online Store. Ein integraler Bestandteil von AVR Studio 5.0 ist das AVR Software Framework. Hierbei handelt es sich um eine Source-Code-Bibliothek für die 8-Bit-MCUs des Typs XMEGA sowie für die 32-Bit-MCUs des Typs AVR UC3, die über 400 umfassende Anwendungsbeispiele sowie ein komplettes Treiberpaket für die auf dem Chip integrierten Peripherieelemente und externe Komponenten enthält. Außerdem sind Kommunikations-Stacks für drahtgebundene und drahtlose Kommunikation, Audio-Decoder- und Grafik-Rendering-Elemente sowie mathematische Bibliotheken für Festkomma- und Gleitkomma-Operationen in dem Framework enthalten.
Gibts nen Grund ausgerechnet den Mega32 wegzulassen? Der ist kostengünstig und hat auch schon ein JTAG-Interface.
Ist bereits genannt worden: AvrStudio5 (beta) enthält nur den Simulator2. Und der unterstützt den m32 auch in AvrStudio4 nicht.
Wan kommt denn voraussichtlich die volle verbesserte version die das stk500 unterstützt??
Hi, ich denke es sollte klar sein das es sich hier nur um eine BETA handelt und es keinen Sinn macht über jeden einzelnen Fehler zu mosern. Auch wenn die Fehlerhäufigkeit eher an eine Alpha erinnert. ;-) Allerdings ist die klare Richtung doch schon eindeutig vorgegeben und darüber kann man diskutieren. Und das die SW Kostenlos ist, das ist Mumpitz. Wir bezahlen die mit jedem Controller den wir einsetzen. Es handelt sich nicht um eine großzügige Gabe sondern um ein Werkzeug das benötigt wird um mit den AVR Controllern überhaupt was anfangen zu können. Es ist ein Muss die zum freien Download anzubieten und keine gnädige Wohltat durch AVR. Ohne diese SW würde Atmel kaum einen AVR verkaufen. Im Gegenzug bedeutet es aber auch das der Nutzwert der SW und der Controller zusammen den Gesamtnutzwert bestimmten. Eine Sche... SW zusammen mit einem Spitzen Controller ist genauso Murks wie eine super SW und ein Krampfcontroller. Klar – der Hobbybastler der 5 Controller pro Monat verbaut ist die SW fast Kostenlos. Aufs jahr gerehnet macht sein Anteil vielleicht 1 – 2 Euro aus. Dieser kann auch mit so einer großen SW leben und problemlos alte Controller durch aktuelle ersetzen. Der Profi aber zahlt über den Controllerkauf durchaus dreistellige Beträge pro Jahr und kann gar nicht anders als viel höhere Anforderungen zu stellen. Wie schon geschrieben: Für den Hobbybastler sind die Hardwareanforderungen sicher kein Problem .Für den Profi der noch zig andere Anwendungen auf seinem Rechner laufen hat oft aber schon. Michael Köhler schrieb: > Ah, ich dachte ja, es geht hier um *Neuentwicklungen" und nicht um > Dinge, die es schon gibt. Irgendwie ist mir das Forum grad nicht so > recht suspekt... Ich denke -ohne jemanden Angreifen zu wollen- hier kann man diese Aussage nur noch einmal wiederholen: IchNix schrieb: > Zahlst du für > das Redesign des analogen Frontends das deswegen notwendig werden kann? > Zahlst du für die dann notwendige Neuzulassung der Baugruppe? ... > Also urteile nicht über Dinge, von denen du nichts verstehst. Bei allen Dingen hier im Forum sollte man bedenken das hier sowohl die Anfänger, die erfahrenen Semiprofessionellen Elektroniker und diejenigen Entwickler deren Entwicklungen tagtäglich in Stückzahlen produziert werden zusammenkommen. Man darf also nicht nur an seine eigenen Anforderungen denken. Für den erfahrenen Einsteiger für den Programmierung kein Neuland ist, der vielleicht schon auf anderen µC oder zumindest dem PC programmiert hat und zudem auch etwas Elektronik Vorwissen hat, für den stellt der Ersatz des A...8 durch den A...88 kein Problem dar. Die notwendigen Änderungen an der PSW sind bekannt und die kleinen Abänderungen an der Hardware – auch von bestehenden Projekten, sofern überhaupt nötig, sind auch beim Nachbau kein Thema. -Kann es sein das du beim Einstieg in diese Kategorie gefallen bist?- Für den absoluten Anfänger sieht das anders aus. Seine ersten Erfahrungen macht der in der Regel entweder mit einem der zahlreichen Tutorials die aber überwiegend alle noch auf dem A...8 basieren. Jetzt liest der zwar irgendwo der A...88 kann den A...8 ersetzen – aber er wundert sich das es einfach nicht läuft! Selbst wenn er mitbekommt das was geändert werden muss wird er bevor überhaupt irgendetwas passiert damit hadern und das ist frustrierend. Die modifikation der Schaltung sind dann auch noch mal ein Thema. Noch schlimmer wenn es sich nur um einen simplen 1-1 Nachbau eines im Web gefundenen Projektes handelt. Nicht wenige sind so zu den µCs gekommen. Der Erfolgreiche Nachbau hat das Interesse geweckt. Wenn der Nachbau dann nicht mehr funktioniert und diese sich nicht erklären können warum... Da ist Frust vorprogrammiert! Und wenn das PRG dann auch nur noch im HEX Format vorliegt wird es erst recht lustig. Oder ist das jetzt nicht nachvollziehbar ? Die andere Seite der Medaille sind die Unternehmen welche die AVR in Ihren Produkten Einsetzen. Auch wenn ich aus deiner Äußerung zu den „Neuentwicklungen“ schließe das du noch nie ernsthaft mit diese Bereich Kontakt gehabt hast. Aber das es zu bestehenden Produkten eher die Regel als die Ausnahme ist das es verschiedene Firmwareversionen gibt -teilweise als Update vom Nutzer selbst Einspielbar, teilweise nur bei der Produktion jeweils das aktuellste eingespielt- das ist dir sicher bekannt. Warum sollte dies bei Produkten mit ATMEGA 8 anders sein? Und diese überarbeiteten Firmwareversionen müssen ja irgendwo herkommen. Selbst wenn man jetzt nur die Firmwareversion bei der Produktion betrachtet. Klar der Hobbyelektroniker denkt sich dann- A...8 ist alt, warum bauen die nicht ab sofort A...88 ein. Aber in der Industrie ticken die Uhren anders! Zum einen wie IchNix schon schrieb kann es eine Änderung des Layouts nötig machen. Diese Änderung bedeutet zum einen einen neuen Design- und Testzyklus intern in der Fa, was zusätzliche Kosten verursacht und auch seine Zeit dauert bevor der erste „echte“ Produktionsauftrag an den LP Hersteller rausgeht. Dazu bestellen gerade Mitellständische Unternehmen oft Platinen in Stückzahlen die der Produktionsmenge von einigen Monaten bis hin zu über einem Jahr entsprechen, weil das massiv günstiger ist. Die Einzelne Platine ist aber immer noch teuer. Ist eine HW Änderung nötig müssten also mehrere hundert bis tausend Platinen entsorgt werden. Noch extremer wird es wenn erweiterte Zertifizierungen und Prüfungen nötig sind. Klar gibt es auch welche wo das nach jeder SW-Änderung schon eine zumindest teilweise Erneuerung nötig ist. Meist ist aber die Hardware entscheidend. Da reicht aber schon der simple Ersatz des ATMEGA8 durch den ATMEGA88 und alle bestehenden Zertifizierungen sind schlagartig erloschen. Das bedeutet wieder ettliche Tausend Euro an diversen Prüfungsgebühren und viele Stunden Schreibarbeit. Evtl. einen zeitweisen Lieferstop wenn die Zertifizierung durch den Abnehmer vorgeschrieben ist! Das ist ein ganzer Rattenschwanz der an so einer Simplen Sache wie dem genauen Typ des µC sitzt. Alles in allen kann das im Extremfall Mehrkosten von einigen 10K-Euro bedeuten. Gerhard Hinze schrieb: > Wegen der Kompatiplität gegenüber älterer Harware (STKxxx) ist es auch > nix neues wenn man Anwendungen anderer Hersteller nimmt , diese bedienen > auch nicht mehr ältere Hardware, die bei diesem oder jenen noch ans herz > gewachsen ist. Naja – es gibt aber auch genug Hersteller die wirklich noch alle Hardware selbst in der aktuellsten Version unterstützen. Meine Microchip Firmware pflege ich auschließlich mit der neuesten bei mri auf dem Rechner vorhandenen MPLAB Version. (Im Moment die aktuellste) Selbst die von mir ende der 90er Jahre geschriebene SW lässt sich damit problemlos übersetzen. Auch die alten Programmer wie PicStart oder ProMate werden weiterhin unterstütz. Gruß Carsten
Carsten Sch. schrieb: > Es > handelt sich nicht um eine großzügige Gabe sondern um ein Werkzeug das > benötigt wird um mit den AVR Controllern überhaupt was anfangen zu > können. Es ist ein Muss die zum freien Download anzubieten und keine > gnädige Wohltat durch AVR. Ohne diese SW würde Atmel kaum einen AVR > verkaufen. Würd ich keineswegs als Selbstverständlich betrachten. Das die Software nix kostet ist in erster Linie interessant für die Hobbybastler. Größere Firmen dürfte das jetzt nicht so sehr interessieren obwohl grade die eine Zielgruppe von Atmel sind. An den Peanuts, die sich der Heimwerker kauft, verdienen die nichts. Ganz anders wird das auch im SPS-Sektor gehandhabt, ohne Software keine Programmierung, trotzdem kostet die nochmal richtig Asche, und Siemens zieht einem damit richtig Geld aus der Tasche weil nach jedem scheizz Update nix mehr funktioniert und man wieder neue Software braucht. Vielleicht, nur vielleicht, will Atmel damit den Entwicklern der Zukunft einen billigen Einstieg in die bunte AVR-Welt geben, die könnten dann auch größere Chargen abnehmen.
Carsten Sch. schrieb: > Naja – es gibt aber auch genug Hersteller die wirklich noch alle > Hardware selbst in der aktuellsten Version unterstützen. Meine Microchip > Firmware pflege ich auschließlich mit der neuesten bei mri auf dem > Rechner vorhandenen MPLAB Version. (Im Moment die aktuellste) > Selbst die von mir ende der 90er Jahre geschriebene SW lässt sich damit > problemlos übersetzen. Auch die alten Programmer wie PicStart oder > ProMate werden weiterhin unterstütz. Ich habe mir übrigens mal das Konkurrenzprodukt zum AvrStudio5 von Microchip angesehen: MPLAB-X. mit PIC18 und PIC32 Support ist das ein 350MB Download. Auf der Platte belegt das Zeug 1.1GB, läuft nochmal langsamer als die Atmel beta und braucht ~270MB RAM. Mein Pickit2 scheint das übrigens nicht zu unterstützen. Stand heute werden wohl die meisten PIC Anwender das MPLAB 8.x verwenden. Genauso werden AVR Nutzer wohl noch einige Zeit beim AvrStudio4 bleiben, das sich immer noch downloaden und ausführen lässt. Ich verwende übrigens MPLAB 8.30 für PICs sowie (meist) Eclipse/avrdude für AVRs. AvrStudio ist mir also ziemlich gleichgültig. Aber angesehen habe ich es mir trotzdem. Die V4 habe ich auch installiert.
Hi, Andreas K. schrieb: > Würd ich keineswegs als Selbstverständlich betrachten. > Das die Software nix kostet ist in erster Linie interessant für die > Hobbybastler. Größere Firmen dürfte das jetzt nicht so sehr > interessieren obwohl grade die eine Zielgruppe von Atmel sind. > An den Peanuts, die sich der Heimwerker kauft, verdienen die nichts. > ... > Vielleicht, nur vielleicht, will Atmel damit den Entwicklern der Zukunft > einen billigen Einstieg in die bunte AVR-Welt geben, die könnten dann > auch größere Chargen abnehmen. Sicher - das steckt da zu nicht kleinen Teilen hinter. Und bei den anderen Anbietern ist das auch nichts anderes. Microchip, Renesas, Zilog & Co. haben da auch keine anderen Motive. Da ist ja auch nichts verkehrt dran. Wenn es gut durchgezogen wird, dann ist es ja auch eine WIN/WIN Situation. Die kleinen Bastler profitieren davon und ein Teil der zufriedenen Bastler wird mal Entwickler der dann "seinem" Favoriten treu bleibt! Klar - Kosten von tausend Euro sind für eine große Firma kein Problem. Aber trotzdem spielt es schon bei der Entscheidungsfindung eine Rolle. Wenn die Entwickler nach einem passenden µC ausschau halten ist einer der ersten Schritte nachdem die HW- Anforderungen abgeklappert sind von allen in Frage kommenden Typen sich die IDE anzuschauen. Dann werden Muster bestellt und die ersten Tests gemacht. Erst dann geht es in die HARTE Entscheidungsfindung. Gerade in diesem Vorfeld spielt es aber schon eine Rolle ob es reicht einfach ein Starterpaket incl. Programmer für 60Eur. bei Digikey zu bestellen und die SW runterzuladen - das geht in den Mesiten Firmen im Rahmen der Eigenverantwortlichen Tätigkeit ohne auch nur eine Rückfrage- Anders sieht es aber dann aus beim KAUF der 5000Eur. SW. Und Atmel hat da nun einmal das Problem das es auf dem Markt reichlich Prozessoren anderer Hersteller gibt alles genausogut können wie die AtmelAVR. Und Microchip, RENESAS, ZILOG (und viele weitere) bieten Ihre IDE nun einmal auch kostenlos an. Wer ist dann wohl als erstes raus? Vieleicht derjenige der eine Anfangsinvestition von x K-Euro verlangt? > Ganz anders wird das auch im SPS-Sektor gehandhabt, ohne Software keine > Programmierung, trotzdem kostet die nochmal richtig Asche, und Siemens > zieht einem damit richtig Geld aus der Tasche weil nach jedem scheizz > Update nix mehr funktioniert und man wieder neue Software braucht. > Das kommt halt immer auf die Mitbewerber an. Solange die Mitbewerber dieselbe Linie fahren oder deren Produkte deutlich schlechter sind kann man das machen. Aber was glaubst du wie schnell Siemens seine Firmenpolitik ändern würde wenn jetzt einer der Mitbewerber eine absolut gleichwertige SPS Lösung auf den MArkt bringen würde - ähnlicher Preisbereich oder gar günstiger- und dafür eine Super Software kostenlos bereitstellen würde. Wobei - man muss gar nicht mal so weit gehen wie zu den SPS Gerätschaften. Es reicht schon von den µC zu den FPGAs zu gehen. Schon dort ist der Anteil freier SW sehr eingeschränkt. Gibt es nur wenige spezielle Bausteine! BTW: Ich würde mal vermuten das auch längst nicht alle Anwender wirklich für die SW zahlen müssen. Eigendlich ist es in allen Branchen üblich das diejenigen die wirklich große Stückzahlen abnehmen oder aber aufgrunf ihrer Kontakte bei verschiedenen Anwendern die Entsccheidung beeinflussen kostenlos versorgt werden. Teilweise nicht nur mit der SW sondern im µC /FPGA bereich auch mit PROG & Debug-Hardware. Selbst kenne ich das sowohl aus dem µC bereich wie auch völlig andere Richtung aus dem Funktechniksektor wo die PSW der Geräte teilweise ettliche hundert Euro kostet, größere Kunden oder Händler die teilweise ohne NAchfrage aber kostenlos mitgeliefert bekommen. Gruß Carsten
Michael G. schrieb: > Ich habe mir übrigens mal das Konkurrenzprodukt zum AvrStudio5 von > Microchip angesehen: MPLAB-X. > > mit PIC18 und PIC32 Support ist das ein 350MB Download. Auf der > Platte belegt das Zeug 1.1GB, läuft nochmal langsamer als > die Atmel beta und braucht ~270MB RAM. Oh, seit wann ist das denn raus? Vor kurzem war das noch nicht da! Ich verwende MPLab 8.63. Ich werde aber jetzt auf diesem Rechner die SW noch nciht installieren, evtl. auf dem Netbook, mal schauen. Grund ist das es wie AVRStudio 5 auch noch eine BETA ist und dieser Rechner mein Arbeitsgerät ist das laufen muss. Ich hoffe aber starkt das die jetzt nicht denselben Weg gehen und eine reihe Werkzeuge herausschmeissen. Evtl. ist das ja hinsichtlich den Prog Tools genauso wie beim STK500 beim AVR 5. das die in der Final Relaese doch drin sind. Zur Download grösse sei Ergänzend gesagt das es 220MB Grundversion sind und dann die gewünschten Komponennten je nach Wahl zusätzlich dazukommen. Es kann also je nach Anwender weniger als 350MB- aber auch deutlich mehr auf der Platte sein! Auf dem ersten Blick sieht es jetzt aber so aus das Microchip nun diejeniger erhöhrt hat die nach "mehr" Open Source gerufen haben. Anahnd der Übersicht: http://www.microchip.com/en_US/family/mplabx/index.html Läuft die SW jetzt genauso unter MacOS und Linux. Dein Einbinden von freien (auch Open Source) Tools soll möglich sein und es basiert auf einen Open Source Framework. Wenn es denn so ist fällt ein immer zitiertes Argument dieser Gruppe für AVR nun weg. Gruß Carsten
Ich hab grad AVR Studio 5 auf der virtuellen maschine installiert und noch ein paar Minuten in einen ersten Blick investiert: Funktionen und mehrzeilige Kommentare zusammenklappen, Auto-Vervollständigen mit Hilfe, Cursorsensitives Einfärben des Quellcodes (zusammengehörige Klammern hervorheben zum Beispiel), Eine Drop-Down-Liste mit den Funktionen der angezeigten Quellcodeseite, Rechtschreibkorrektur für Kommentare (nur auf englisch), Einen Assistenten, der bei dem ganzen Kleinkram hilft (Funktionen udn Klammern setzen, Prototypen, wasweisich noch alles kann man sich damit ganz flott zusammenklicken) Eben so Sachen, die ich eher von Programmen wie dem C++-Builder kenne, macht also schon mal den Eindruck, das die beim Frontend viel von so dicken Eisen abgekupfert haben. Der Quellcode-Editor ist wohl auch schon auf C++ eingeschliffen, schätze das ist den neuen AVR-Dingern geschuldet. Also auf den Ersten Blick siehts nicht schlecht aus. Aber ohne Gewähr, ich hatte noch keine Gelegenheit mal unter die Haube zu gucken.
Jörg Wunsch schrieb: > IchNix schrieb: >> aber gerüchtweise mag Atmel die an gcc vorgenommenen >> Änderungen nicht so ohne weiteres ans gcc-Projekt zurückgeben. > > Das ist Quark. Du kannst ihnen vielleicht vorwerfen, dass sie, seit > es kein WinAVR mehr gibt, ihre Patches nicht ordentlich publik gemacht > haben (aber das hat Eric selbst bei WinAVR immer nur zögerlich im > Nachgang geschafft, vornehmlich aus Zeitgründen), aber falls du auf > die Xmega- und AVR-32-Patches anspielst: dass diese sich nicht schon > längst im Tree des GCC wiederfinden, hat sich die FSF mit ihrer > (sorry) saudämlichen Anforderung, dass nur Code in den GCC-Tree darf, > für den man eine Copyright-Abtretungserklärung unterzeichnet hat, > selbst zuzuschreiben. hmmm, das sind nun mal die Spielregeln. Was AVR32 abgeht, kann nur Atmel beurteilen, was auf lange Sicht weniger Aufwand ist: avr32-gcc selbst zu hosten (was momentan der Fall ist) oder innerhalb von FSF-GCC zu warten. Ersteres ist auf kurze Sicht einfacher, erlaubt schnelle Änderungen und vermeidet zähe Diskussionen mit Atmels Advokaten. Zweiteres ist auf lange Sicht deutlich weniger Arbeit. > Frag mal Georg Johann, wie lange es gedauert > hat, bis er diesen Blödfug endlich in Sack und Tüten bekommen hat (der > für einen europäischen Autor ob des sich vom US-amerikanischen > Copyright fundamental unterscheidenden hiesigen Urheberrechts ohnehin > juristisch komplett gegenstandslos ist), und dann extrapoliere von > dieser Zeit mal, wie lange es dauert, bis sich ein Laden wie Atmel mit > einer ausgeprägten Rechtsabteilung in dieser Hinsicht mit der FSF > handelseinig geworden ist. Ein FSF-Assignment ist nun mal Voraussetzung. Man kann darüber lamentieren (was ich ja auch ne Zeit lang gemacht hab) oder es angehen. Ich hatte eben auch Pech, weil der Wisch irgendwo in den Papierbergen versackte und es nicht meine Art ist, ständig da anzunerven. Nachdem mich Paolo Bonzini nochmals motiviert hatte und ich es nochmals versuchte, ging es dann ganz flott und inzwischen sind meine ersten Patches -- ein paar offensichtliche Bugfixes -- in GCC mainline drinne. Lustig in dem Zusammenhang finde ich Digital Mars, die ihr D-Frontend gerne in GCC haben würden, aber nicht bereit sind, ein Copyright-Assignment zu unterzeichnen. In einer Mail bieten sie dann an, ein paar Bucks an RMS rüberzuschieben um so ein "Arrangement" zu finden. Mich hat's vor Lachen vom Hocker gerissen als ich das las... Die Probleme an der Wurzel zu beheben -- also in der FSF-Quelle -- finde ich immer noch besser als den Sack voll Patches, die irgenwo rumschwirren. Wer an avr-gcc mithelfen will muss eben da durch, und für privat hat man ja auch keinen Streß mit irgend einer Rechtsabteilung. Jedem, der gerne Probleme in avr-gcc behebt oder gerne daran mitarbeitet, kann ich nur darin bestärken, das an der Wurzel des Übels zu tun, also ein FSF-Assignment einzureichen und dann "richtige" GCC-Patches zu erstellen. Wenn Fragen sind, kann ich die gerne beantworten. Im avr-gcc Projekt gibt es ja genug zu tun: Das Betätigungsfeld erstreckt sich von Fehlerbehebung/Lokalisierung/Bestätigung über Funktionserweiterung bis zu Dokumentation und Testing. OS_tast und OS_main sind zum Beispiel implementiert ohne daß die GCC-Doku ein Wort darüber verliert. Ich musste da durch die Quellen um zu erahnen, wozu das gut sein soll... keine Ahnung. Das Hauptproblem wird aber sein, sich in die Arbeitsweise von GCC einzuarbeiten und nen Überblick über die Maschinenbeschreibung zu bekommen. Für einen "Volunteer", der das aus Interesse/Idealismus oder woraus auch immer in seiner Freizeit macht und nicht dafür bezahlt wird, ist der Zeitaufwand schlicht so groß, daß die meisten wohl frustriert aufgeben.
Johann L. schrieb: > hmmm, das sind nun mal die Spielregeln. Die "Spielregeln" sind, dass du jedem, der dich danach fragt, die Patches, die du eingebracht hast, zu den Bedingungen der GPL weitergeben musst. Es gibt keine Regel, wonach jemand verpflichtet wäre, seine eigenen Beiträge zwingend in den GCC-Tree zurück zu liefern (was schon rein juristisch aufgrund der genannten Grundhaltung der FSF gar nicht möglich ist). Die Patches bekommst du, wenn du Atmel danach fragst. > Was AVR32 abgeht, kann nur Atmel > beurteilen, was auf lange Sicht weniger Aufwand ist: avr32-gcc selbst zu > hosten (was momentan der Fall ist) oder innerhalb von FSF-GCC zu warten. Du kannst dir versichert sein: wenn es einen einfachen Weg gegeben hätte, diesen Kram gleich im offiziellen GCC zu haben, wären sie den gegangen. Da hat keiner dran Interesse, den Krempel selbst zu hosten. Dass es beim 8-bit AVR relativ problemlos geklappt hat, lag einfach daran, dass dieser außerhalb Atmels entstanden ist. > Ein FSF-Assignment ist nun mal Voraussetzung. Man kann darüber > lamentieren (was ich ja auch ne Zeit lang gemacht hab) oder es angehen. > Ich hatte eben auch Pech, weil der Wisch irgendwo in den Papierbergen > versackte und es nicht meine Art ist, ständig da anzunerven. Genau. Sowas nervt einfach nur noch, und während du privat zumindest da noch nachtrittst, werden die Rechtsabteilungen großer Firmen sich da schnell hinstellen und sagen: "Wollen die was von uns oder wir was von denen?" Dem Vernehmen nach ist mittlerweile wohl der rechtliche Kram unter Dach und Fach, hat mir zumindest Eric Weddington mal gesagt. Nun brauch es "nur noch" jemanden, der das Standvermögen besitzt, im riesigen und wenig flexiblen GCC das Zeug dann auch wirklich durchzuboxen. > Lustig in dem Zusammenhang finde ich Digital Mars, die ihr D-Frontend > gerne in GCC haben würden, aber nicht bereit sind, ein > Copyright-Assignment zu unterzeichnen. Es beweist nur um so mehr, dass die starre Haltung der FSF da völlig kontraproduktiv ist. Das Argument, dass man auf diese Weise "die Rechte von freier Software besser verteidigen könnte" hat ungefähr die Überzeugungskraft einer Überschrift im "Neuen Deutschland" gegen Ende der 1980er Jahre ... Wenn es ihnen nur darum gehen würde, wäre es ganz sicher überhaupt kein Akt, sich statt einer Copyright-Abtretung im Einzelfall die Vertretungs- berechtigung desjenigen einzuholen. Wie oft gibt es juristisch relvante Rechtsstreite über GPL-Verletzungen, verglichen damit, wie vielen Leuten man durch diese dämliche Abtretungserklärungen bereits vorab auf den Senkel geht und ihnen so u. U. die Motivation nimmt, da überhaupt etwas beizutragen?
Oje, eine Wespennest ;-) Jörg Wunsch schrieb: > Johann L. schrieb: > >> hmmm, das sind nun mal die Spielregeln. > > Die "Spielregeln" sind, dass du jedem, der dich danach fragt, die > Patches, die du eingebracht hast, zu den Bedingungen der GPL > weitergeben musst. Die Quellen (incl. Patches) muss man ja nur denjenigen zur Verfügung stellen, die auch auf legalem Wege die Binaries von einem erhalten haben. > Es gibt keine Regel, wonach jemand verpflichtet > wäre, seine eigenen Beiträge zwingend in den GCC-Tree zurück zu > liefern (was schon rein juristisch aufgrund der genannten Grundhaltung > der FSF gar nicht möglich ist). Das stimmt. Ich bezog die "Spielregeln" von ober aber genau darauf: wenn jemand seine Änderungen/Patches gerne in gcc commitet haben möchte. Kleine externe Patches/Erweiterungen sind ja noch einigermassen überschaubar. Aber um avr-gcc wirklich weiterzuentwickeln, sind externe Patches absolut ungeeignet, weil nicht wartbar. Momentan ist ja schon die Situation daß Eric Commits von Bugfixes ablehnt, weil ds für ihn bedeuten würde, einen Großteil der Patches zu portieren -- jedenfalls nehm ich mal an, daß das der Grund ist. Er selbst sagt ja nix dazu. Eric sitzt da natürlich zwischen den Fronten und muss das alles ausbaden, und da geht er eben den Weg des geringsten Widerstands. Nichtsdestotzotz führt das dazu, daß Bugs nicht gefixt werden. >> Was AVR32 abgeht, kann nur Atmel >> beurteilen, was auf lange Sicht weniger Aufwand ist: avr32-gcc selbst zu >> hosten (was momentan der Fall ist) oder innerhalb von FSF-GCC zu warten. > > Du kannst dir versichert sein: wenn es einen einfachen Weg gegeben > hätte, diesen Kram gleich im offiziellen GCC zu haben, wären sie den > gegangen. Da hat keiner dran Interesse, den Krempel selbst zu hosten. Das einfach bezog ich auf die technische Komponente, nicht auf die juristische. Ich hab noch nicht ins avr32-Backend reingeschaut und weiß nicht, ob Atmel Änderungen gemacht hat, die übers Backend hinaus gehen. Ich hab nur vor einiger Zeit mal in pic-gcc vom Microchip reingeschaut... das käm so nie und nimmer in GCC rein, unabhängig von irgendwelchen lizenzrechtlichen Befindlichkeiten. > Dass es beim 8-bit AVR relativ problemlos geklappt hat, lag einfach > daran, dass dieser außerhalb Atmels entstanden ist. Ja, ein Glück. >> Ein FSF-Assignment ist nun mal Voraussetzung. Man kann darüber >> lamentieren (was ich ja auch ne Zeit lang gemacht hab) oder es angehen. >> Ich hatte eben auch Pech, weil der Wisch irgendwo in den Papierbergen >> versackte und es nicht meine Art ist, ständig da anzunerven. > > Genau. Sowas nervt einfach nur noch, und während du privat zumindest > da noch nachtrittst, werden die Rechtsabteilungen großer Firmen sich > da schnell hinstellen und sagen: "Wollen die was von uns oder wir was > von denen?" "Nachtreten" hört sich so gewallätig an. Sagen wir lieber "nachfragen" oder "nachhaken". Daß Rechtsabteilungen/Firmen es nicht wollen, ihr Copyright abzutreten ist ja auch durchaus nachvollziehbar. Andererseits hat Atmel auch vom GCC-Projekt profitiert. Einsteiger würden sehr viel seltener einen AVR verwenden, wenn's keinen avr-gcc gäbe, und es gäbe viel weniger Projekte wie Asuro. Zwar ist das kein großer Markt, aber aus Einsteigern werden ja mitunter auch professionelle Entwickler, die auch Erfahrungen/Vorlieben aus der Einsteigerzeit mitbringen. Für AVR32 kam Atmel relativ komfortabel an einen zeitgemässen C/C++ Compiler. Und im Gegensatz zu zB einer BSD-Lizens muss Atmel aufgrund des Copylefts auch die avr32-gcc Quellen verfügbar machen, ebenso wie Microchip seine pic-gcc Quellen. > Dem Vernehmen nach ist mittlerweile wohl der rechtliche Kram unter > Dach und Fach, hat mir zumindest Eric Weddington mal gesagt. Nun > brauch es "nur noch" jemanden, der das Standvermögen besitzt, im > riesigen und wenig flexiblen GCC das Zeug dann auch wirklich > durchzuboxen. Für AVR ist das ja nur der kleine Sandkasten avr-Backend, wo sich Denis, Eric und Anatoly prinzipiell beliebig austoben können ;-) Für den Rest der GCC-Entwickler ist das, was da passiert, uninteressant. Erik brauch für seine Änderungen nur ein "ist OK" von Denis oder Anatoly, und weils innerhalb des Backend ist eigentlich noch nicht mal das. Er darf selber commiten, und wenn Einvernehmen unter den AVR-Maintainern besteht, können sogar Änderungen eingepflegt werden, die üblicherweise nur in Stage=1 erlaubt sind. Eric ist bereits seit Anfang 2010 avr-Maintainer. Er fügt hin und wieder neue Derivate hinzu. >> Lustig in dem Zusammenhang finde ich Digital Mars, die ihr D-Frontend >> gerne in GCC haben würden, aber nicht bereit sind, ein >> Copyright-Assignment zu unterzeichnen. > > Es beweist nur um so mehr, dass die starre Haltung der FSF da > völlig kontraproduktiv ist. Das Argument, dass man auf diese Weise > "die Rechte von freier Software besser verteidigen könnte" hat > ungefähr die Überzeugungskraft einer Überschrift im "Neuen > Deutschland" gegen Ende der 1980er Jahre ... Wenn es ihnen nur > darum gehen würde, wäre es ganz sicher überhaupt kein Akt, sich > statt einer Copyright-Abtretung im Einzelfall die Vertretungs- > berechtigung desjenigen einzuholen. Es geht ja nicht nur ums Copyright sondern auch ums Copyleft. Ein Lizenzgeber ist nicht ans eigene Copyleft gebunden, und so eine Situation versucht die FSF eben zu verhindern. Nach einer Copyrightabtretung gewährt die FSF ein Copyback, daß dem Einreicher erlaubt, was-auch-immer mit den Quellen zu machen. Wenn es allerdings ein Mergeback aus einem FSF-Repository gibt, schlägt wieder die GPL zu. Was die "Kontraproduktivität" betrifft, würde GCC bestimmt schneller wachsen ohne GPL, aber die FSF versteht unter "freier Software" eben was anderes als "Open Source", z.B. das es ein Copyleft gibt.
Ich moechte nur zum Thema "Warum hat Ateml nicht Eclipse benutzt" sagen: Ich nutze sowohl Eclipse als auch das Visual Studio beruflich. Eclipse ist eine lahme, auf Java basierende Ente, bei der die Vielzahl an Koechen einfach den Brei verdorben hat. Bei diversen wichtigen Features wie dem Refactoring (z.B. bei Umbenennungen von Packages oder anderem Kram) versagt Eclipse oft, mit sehr grossen Projekten kommt es nicht gut klar. Vor einigen Jahren war das noch besser. Zugegeben, ich mache damit J2EE, vielleicht sieht es sonst anders aus. Eclipse ist jedenfalls Bloatware par execellence. Fuer C/C++ Entwicklung wuerde ich das Ding erst gar nicht anfassen. Die Probleme mit Eclipse haben uns schon Mannmonate gekostet. Das Visual Studio laeuft einfach, die Arbeit geht dann doch deutlich fluessiger von der Hand. Es startet nicht nur schneller und zeigt ein besseres Laufzeitverhalten, es hat auch sonst in allen ergonomischen Belangen die Nase vorne. Und das hat einen nicht zu unterschaetzenden Einfluss auf die Arbeitsgeschwindigkeit und die Code-Qualitaet.
Johann L. schrieb: > Aber um avr-gcc wirklich weiterzuentwickeln, sind externe > Patches absolut ungeeignet, weil nicht wartbar. Keine Frage. > Ich hab noch nicht ins avr32-Backend reingeschaut und weiß > nicht, ob Atmel Änderungen gemacht hat, die übers Backend hinaus gehen. > Ich hab nur vor einiger Zeit mal in pic-gcc vom Microchip > reingeschaut... das käm so nie und nimmer in GCC rein, unabhängig von > irgendwelchen lizenzrechtlichen Befindlichkeiten. Reingeschaut habe ich auch nicht, aber ich habe gehört, dass die, die AVR32-GCC entwickelt haben, zumindest davon ausgegangen waren, dass ihr Code da mal hin soll. Sie könnten sich also zumindest Mühe gegeben haben. ;-) > Andererseits hat Atmel auch vom GCC-Projekt profitiert. Einsteiger > würden sehr viel seltener einen AVR verwenden, wenn's keinen avr-gcc > gäbe, ... Ach, das kommt in einer Firma dieser Größe leider viel zu selten bei den Entscheidungsträgern an, und erst recht nicht bei den Rechtsabteilungen. Weiß nicht, ob du dich noch daran erinnerst, wie der AVR angefangen hat: da haben sie alles auf die Karte "IAR" gesetzt. Mit denen haben sie die Architektur durchgesprochen und noch modifiziert. Das Ergebnis haben wir heute noch vor uns: die Veränderungen, die daraus resultierten, waren sicher nicht schlecht (sind irgendwo dokumentiert), aber was ein IAR nicht gebraucht hat, ist halt auch nicht drin. Wenn ein IAR kein "single stack"-Modell unterstützt, so hat eben der Prozessor keine Möglichkeit erhalten, den Stack direkt und atomar zu erweitern/reduzieren. Dass der IAR letztlich so teuer ist (und so bescheu... mit seinem Lizenz-Handling), dass auch viele kommerzielle Unternehmen sich den entweder nicht leisten können oder auch nicht wollen (Stichwort: größere Übersetzungsaktionen nächtlich in einer Serverfarm, beispielsweise als "regression test"), hat eine Weile gebraucht, bis es sich bei den Entscheidern rumgesprochen hat. Erst danach bekam der GCC dann allmählich überhaupt den nötigen Stellenwert beigemessen dort. > Für AVR ist das ja nur der kleine Sandkasten avr-Backend, wo sich Denis, > Eric und Anatoly prinzipiell beliebig austoben können ;-) Naja, so er von seinem Brötchengeber dafür halt auch das Zeit-Budget erhält. > Es geht ja nicht nur ums Copyright sondern auch ums Copyleft. Ein > Lizenzgeber ist nicht ans eigene Copyleft gebunden, und so eine > Situation versucht die FSF eben zu verhindern. Politischer Humbug. Einen Autor kannst du ohnehin nicht daran hindern, dass er sein geistiges Eigentum mehrfach verwertet. RMS ist ein Möchtegern-Politiker, noch dazu ein recht starrsinniger.
Mr. Greenhorn schrieb: > Eclipse ist jedenfalls > Bloatware par execellence. Naja, wenn ich mir ansehe, wie dick das AVR-Studio-5-Paket geworden ist, dann kann man das wohl auch nicht gerade als Leichtgewicht bezeichnen ... Ob es nun besser ist als Eclipse vermag ich nicht zu sagen, da ich keinen Computer besitze, auf dem es laufen würde (und auch keinen besitzen möchte). Eclipse würde ich sicher auch persönlich eher nicht benutzen, aber es scheint sich einer recht großen Popularität zu erfreuen.
Jörg Wunsch schrieb: > Johann L. schrieb: >> >> Andererseits hat Atmel auch vom GCC-Projekt profitiert. Einsteiger >> würden sehr viel seltener einen AVR verwenden, wenn's keinen avr-gcc >> gäbe, ... > > Ach, das kommt in einer Firma dieser Größe leider viel zu selten bei > den Entscheidungsträgern an, und erst recht nicht bei den > Rechtsabteilungen. Weiß nicht, ob du dich noch daran erinnerst, wie > der AVR angefangen hat: nö, da war ich noch flüssig. Den ersten µC (8051) hab ich 2001 oder 2002 angefasst, und das auch nur, weil ich im Internet zufällig drüber gestolpert bin. Ich hatte noch nichtmal Suchbegriffe oder sowas :-) > da haben sie alles auf die Karte "IAR" > gesetzt. Mit denen haben sie die Architektur durchgesprochen und noch > modifiziert. Ein Glück. Jeder Hardwarehersteller ist gut damit beraten, nicht erst an Compiler/Entwicklungsumgebung zu denken, wenn Silizium verfügbar ist. In einer Co-Entwicklung können viele Schwächen und Fehler -- sowohl in Compiler als auch Hardware/Simulator -- beseitigt werden. Und dazu gehören auch Designschwächen. Also besser irgendein Compilerbauer als garkeinen :-) ISA-Designer können maximal bis zu einem Assembler-Programmierer denken und haben von einem Compiler Vorstellungen, wie sie schon vor 20 Jahren überholt waren. (á la Textersetzung etc) Ohne IAR hätte AVR ein segmentiertes Design wie PIC (was bei AVR erst mit ATmega256* Einzug hielt bzw. mit Bus-Interface) und die ISA viele andere Schwächen, die auch einem GCC die Codeerzeugung zumindest deutlich erschweren würden oder dazu geführt hätten, daß GCC überhaupt nicht mit AVR zurecht kommt. Hierzu gehört die reichliche Ausstattung mit Adress-Registern. > Das Ergebnis haben wir heute noch vor uns: die > Veränderungen, die daraus resultierten, waren sicher nicht schlecht > (sind irgendwo dokumentiert), aber was ein IAR nicht gebraucht hat, > ist halt auch nicht drin. Wenn ein IAR kein "single stack"-Modell > unterstützt, so hat eben der Prozessor keine Möglichkeit erhalten, den > Stack direkt und atomar zu erweitern/reduzieren. Immerhin hat Atmel das erkannt und nachgebessert bei Xmega. > Dass der IAR letztlich so teuer ist (und so bescheu... mit seinem > Lizenz-Handling), dass auch viele kommerzielle Unternehmen sich den > entweder nicht leisten können oder auch nicht wollen (Stichwort: > größere Übersetzungsaktionen nächtlich in einer Serverfarm, > beispielsweise als "regression test"), hat eine Weile gebraucht, bis > es sich bei den Entscheidern rumgesprochen hat. Erst danach bekam der > GCC dann allmählich überhaupt den nötigen Stellenwert beigemessen > dort. GCC wurde lange nicht ernst genommen weil er freie Software ist. Offenbar dachten die Entscheider in der Industrie dabei eher an "free beer" als an "freedom", nach dem Motto: was nix kostet taucht auch nix. Hier hat sich in den letzten Jahren ein deutlicher Wandel vollzogen, den Wikipedia so ausdrückt: > Several companies make a business out of supplying and supporting > GCC ports to various platforms, and chip manufacturers today consider > a GCC port almost essential to the success of an architecture. >> Für AVR ist das ja nur der kleine Sandkasten avr-Backend, wo sich Denis, >> Eric und Anatoly prinzipiell beliebig austoben können ;-) > > Naja, so er von seinem Brötchengeber dafür halt auch das Zeit-Budget > erhält. Eric macht eben nur "AVR-Support", nicht "Compilerbau". Anatoly und Denis scheinen kein Nerv und keine Zeit mehr für avr-gcc zu haben.
Johann L. schrieb: > Ohne IAR hätte AVR ein segmentiertes Design wie PIC Nein, ganz so schlimm ist es nicht. ;-) So viel Weitsicht haben die Autoren des AVR wohl bereits von vornherein gehabt. Die von IAR induzierten Änderungen sind hier dokumentiert: http://www.atmel.com/dyn/resources/prod_documents/compiler.pdf > GCC wurde lange nicht ernst genommen weil er freie Software ist. Nö. Wohl eher, weil die Controller-Leute komplett "Windows only" waren zu der Zeit (und ja auch heute leider noch sind, wie man an AVR Studio 5 sieht). Ich könnte mit dir auf einen Kasten Bier wetten, dass Alf-Egil Bogen und Vegard Wollan damals wohl noch nicht einmal eine Ahnung hatten, dass man GCC für einen Controller als Compiler benutzen kann, falls sie den Namen GCC denn überhaupt kannten. Dass ein GCC mal für den Erfolg ihres "Babys" mit verantwortlich sein könnte, war gewiss außerhalb ihres Horizonts. Ich habe GCC Anfang der 1990er Jahre kennengelernt, und zwar für den Motorola 88000. Data General (kennt heute keiner mehr) hatte damals Workstations mit diesem RISC-Prozessor gebaut, und die haben zu der Zeit bereits einen oder mehrere hauptamtliche Entwickler für den GCC gehabt, dieweil das ihr primärer Compiler für das gesamte Betriebssystem war. (Parallel haben sie noch Green Hills als Compilerhersteller gehabt.) Die wussten da bereits, dass nur das Ergebnis zählt, und das war ein guter Compiler, für den man überdies noch den Sourcecode besaß und auf diese Weise per "silicon filter" die zahlreichen Hardwarebugs des Prozessors umschiffen konnte ... Das war aber halt die Unix-Welt, da hatte GCC schon damals durchaus einen Namen. > Eric macht eben nur "AVR-Support", nicht "Compilerbau". Anatoly und > Denis scheinen kein Nerv und keine Zeit mehr für avr-gcc zu haben. Denis macht eigentlich mittlerweile komplett was anderes (habe vergessen, für welche Architektur). Insofern hat es mich schon gewundert, dass er deine Patche letztlich eingepflegt hat. Anatolyj macht das alles als Hobby, also nur dann, wenn er die Zeit dafür auch aufwänden kann oder will.
Jörg Wunsch schrieb: > Johann L. schrieb: > >> Ohne IAR hätte AVR ein segmentiertes Design wie PIC > > Nein, ganz so schlimm ist es nicht. ;-) So viel Weitsicht haben > die Autoren des AVR wohl bereits von vornherein gehabt. Leider nicht:
1 | In addition, there was a paged direct addressing mode for |
2 | accessing variables placed in the data memory. |
3 | [...] |
4 | To expand the reach of the displacement mode, we needed to change |
5 | other parts of the instruction set to get enough coding space. |
6 | At the same time, we were informed that the paged direct accessing |
7 | mode was difficult to use from the compilers point of view. |
8 | By removing the paged direct addressing mode, space was made |
9 | available for expanding the displacement to 64 locations, which is |
10 | large enough to meet most demands for indirect addressing. |
11 | The paged direct addressing mode was changed to a two word unpaged |
12 | direct addressing mode |
>> GCC wurde lange nicht ernst genommen weil er freie Software ist. > > Nö. Wohl eher, weil die Controller-Leute komplett "Windows only" > waren zu der Zeit (und ja auch heute leider noch sind, wie man an AVR > Studio 5 sieht). Ich könnte mit dir auf einen Kasten Bier wetten, > dass Alf-Egil Bogen und Vegard Wollan damals wohl noch nicht einmal > eine Ahnung hatten, dass man GCC für einen Controller als Compiler > benutzen kann, falls sie den Namen GCC denn überhaupt kannten. Dass > ein GCC mal für den Erfolg ihres "Babys" mit verantwortlich sein > könnte, war gewiss außerhalb ihres Horizonts. Immerhin war AVR das erste 8-Bit Target im GCC und damit ein Novum und Abenteuer. > [...] > Das war aber halt die Unix-Welt, da hatte GCC schon damals durchaus > einen Namen. Ja, in der Host-Welt. Mikrocontroller spiel(t)en aber in einer ganz anderen Liga. Proprietäre Compilerhersteller können einfacher die Eigenheiten einer Architektur nutzen wie zB ein segmentiertes Layout (PIC, C16x...). Im Moloch GCC ist sowas fast ausgeschlossen (inzwischen ist's einfach machbar, aber nicht bis vor 1-2 Jahren). Ich hab mich schon gefragt wie signnig es wäre, das in avr-gcc einzubauen, also erweiterte Funktionspointer-Typen für zB ATmega256 oder dedizierte Flash- und EEPROM-Pointer. Letzteres würde die ganzen pgm_read_* überflüssig machen und es wäre möglich, fast "normales" C hinzuschreiben und typsicher zu sein. >> Eric macht eben nur "AVR-Support", nicht "Compilerbau". Anatoly und >> Denis scheinen kein Nerv und keine Zeit mehr für avr-gcc zu haben. > > Anatolyj macht das alles als Hobby, also nur dann, wenn er die Zeit > dafür auch aufwänden kann oder will. Amatoly wuselt schon noch im GCC rum; wie's aussieht Aufräumarbeiten für den bevorstehenden Umstieg auf C++.
Ich habe AVRStudio5 mal getestet und bin "etwas" enttäuscht. Auf einem Rechner gab es reproduzierbare Installationsprobleme mit der Visual Studio Komponente und als ich das Teil auf dem anderen Rechner installiert habe war es extrem langsam. Von den versprochenen 400 Beispielprogrammen sind 360 für die AVR UC3, 40 für den Xmega und 0 (NULL) für die "alten" AVRs. Überhaupt werden die von der Software kaum mehr unterstützt. Will die Atmel loswerden?
Also ich habe AVRSTUDIO gestern auch mal runtergeladen. Ging recht flott ca. 12 min mit DSL. Dann schnell installiert ca. 15 min. Uh ich brauch Platz auf "C:\"...?! Ich kann auch nicht woanders installieren? Nicht gut. Ich muss löschen. Oder Verschieben. Verschiebe ich also mal das von hier nach da. So nun geht es. Installiere. Ach OK. Meine anderen Platten haben ca. 2TB Speicher. Da kann man es schon verstehen, wenn sich Leute über 500MB donwloads aufregen... ;) Vorallem weil zu Flatrate zeiten die Kosten dafür exorbitant sind... Also das Programm sieht aufgeräumt aus, mein xplain board wird direkt als avrisp mk2 erkannt und lässt sich proggen, readen und verifyen... SUPER! Der Editor bringt das mit, was eclipse's pdt daseinsberechtigung verlieh. SUPER! Oh man ich habe gerade festgestellt, dass bei mir um die Ecke keine Granaten aus dem zweiten Weltkrieg mehr verkauft werden. Dann warte ich halt auf den dritten! Auf ihr Freidenker!!! mfg jonas
jonas biensack schrieb: > Da kann man es schon verstehen, wenn sich Leute über 500MB donwloads > aufregen... ;) Vorallem weil zu Flatrate zeiten die Kosten dafür > exorbitant sind... Dummschwätzer! jonas biensack schrieb: > Oh man ich habe gerade festgestellt, dass bei mir um die Ecke keine > Granaten aus dem zweiten Weltkrieg mehr verkauft werden. Dann warte ich > halt auf den dritten! > > Auf ihr Freidenker!!! s.o.
@die wegen 500MB meckern... Aleine ~350MB verschling die Toolchain die mit dabei ist, also Compiler und so weiter... Also hier nicht Äpfel mit Birnen vergleichen
docean schrieb: > Aleine ~350MB verschling die Toolchain die mit dabei ist, also Compiler > und so weiter... Was dahingehend seltsam ist, dass das letzte WinAVR (das ja schon AVR32-Tools mit enthielt) ungefähr 1/10 davon gebraucht hat ...
Die AVR-Toolchain die mit dem AS5 ausgeliefert wird belegt ~350MB auf der Platte. Beim letzten WinAVR sind es ~250MB. Der Vollständigkeit halber: Das MPLABC für PIC18 braucht etwa 500MB. Der ARM-GCC von Codesourcery begnügt sich mit ~130MB und der PICC18 von HITECH mit rund 70MB. Und zu guter letzt der CCS-C für PIC18 mit ~20MB einschl. seiner bescheidenen IDE (v3.49 oder so). Der Codevision AVR dürfte auch in der Größenordnung liegen. Hat schon jemand ausgerechnet welchen Einfluss die vermehrte Bewegung des Schreib-/Lesekopfs der Festplatte bei den Monster-IDEs auf den jährlichen Stromverbrauch der Industrieländer hat? Vielleicht könnte man so einen direkten Zusammenhang zwischen Programmgröße und CO2 Ausstoß ermitteln. Möglicherweise sollte man die Software Industrie in den Emissionshandel mit einbeziehen. Das könnte auch einen Weg zu Steuererleichterungen für Assembler Programmierer eröffnen. Glücklicherweise habe ich andere Sorgen ;). PS: Ich habe gestern Abend mal etwas mit der V5 gespielt - hat schon wer rausgefunden wie man ein Programm flasht ohne jedes mal dieses Dialogfenster zu öffnen? Bei der V4 muß man das ja nur einmal machen und hat dann ein Icon in der Toolbar.
let schrieb: > PS: Ich habe gestern Abend mal etwas mit der V5 gespielt - hat schon > wer rausgefunden wie man ein Programm flasht ohne jedes mal dieses > Dialogfenster zu öffnen? Bei der V4 muß man das ja nur einmal machen > und hat dann ein Icon in der Toolbar. Nach genau dieser Möglichkeit suche ich auch. Auch ist das Flashen mittels HV-Programmierung nicht mehr möglich. Hoffentlich fehlt das nur in der beta und ist in der final integriert. Wo kann man eigentlich Verbesserungsvorschläge einreichen, das wären nämlich 2 Dinge, die echt nützlich waren in der Vergangenheit! Auch eine Hilfe fehlt mir, in der ich die Pinbelegung des AVR-Dragon erfahren kann, um Prozessoren im Sockel programmieren zu können. Scheinbar gibt es seitensAtmel garkeine hilfe, hoffentlich kommt diese mit der Final! Auch finde ich die Konfiguration recht umständlich. Einstellungen wie F_CPU und die Optimierung sind weit über verschiedene Registerkarten verstreut. Was mir aber richtig gut gefällt, ist die Möglichkeit Projektmappen zu erstellen, in denen mehrere Projekte zusammengefasst sind, sodass ich Programme zusammenfassen und gleichzeitig Kompilieren kann (Bootloader, Programm)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.