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
Angehängte Dateien:
-
PC_R__ck.jpg
80 KB
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.
Angehängte Dateien:
-
AVR-Studio5.JPG
67 KB
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)
Portabilität: Hat irgendwer Hinweise, ob die Projekte/Projectfiles des AVRS5 auf andere Rechner mit anderen Pfadnamen übertragbar sind? Das war nämlich bei AVRS4 bis zur Version 4.18 immer das Problem: Die Pfade der im Projekt enhaltenen Files sind in der .aps-Datei als Absolutpfade gespeichert, und man konnte den Kram nicht einfach mal auf einen anderen Rechner schieben und testen. Schlecht fürs Teamwork.. Irgendwelche Erfahrungen? Grüßle
Andreas Paulin schrieb: > Irgendwelche Erfahrungen? Mal ein kurzer Schnelltest. Projekt/Solution erstellen, speichern, schließen. Projektordner umbenannt und in zwei verschachtelte Unterordner verschoben. Projekt öffnen -> *.avrgccproj Datei suchen (ja, die Dateinamenerweiterung ist so lang) -> Alles wieder da. Scheint zu funktionieren...
Probiers selbst aus!! Funktioniert ohne Probleme, wenn sie die Dateien alle im Projektordner befinden. Bei Dateien, die sich nicht im Projektordner selbst befinden, wird der Pfad statisch eingebunden.
Christian L. schrieb: > Wo kann man eigentlich Verbesserungsvorschläge einreichen Dahin habe ich schon eine Anregung geschrieben: avr@atmel.com, Betreff: AVR-Studio 5.0 Antwort kam von heute auf morgen. mfg.
Thomas Eckmann schrieb: > Antwort kam von heute auf morgen. Jetzt bin ich neugierig: Wie viel die denn aus?
Andreas K. schrieb: > Jetzt bin ich neugierig: Wie viel die denn aus? Dear Mr. Eckmann, Thank you for contacting us and for your interest in Studio 5. I think you refer to the "Frequency" field under the project options in Studio 4. It defines the macro -D_FCPU to the value specified in that field. This has not been included in Studio 5, as you have noticed. However, you can do it manually in Project properties > Toolchain > AVR32/GNU C Compiler > Symbols, under the Defined symbols field, i.e. you can add this string: F_CPU=x where x is your frequency in Hz. I have raised a bug and hopefully it will be fixed in the next release. Best Regards, Alfonso Martinez del Hoyo Canterla Atmel Technical Support Team mfg.
Klingt sinnvoll und positiv, nicht nur das übliche "wird an entsprechende Stellen weitergeleitet".
mal eine kurze Zwischenfrage... hat jemand die Geschichte unter VirtualBox am Laufen? hab hier auf meinem LinuxRechner VirtualBox 4.0.4xxx laufen und eine Win7 HomePremium als 'Gast'... Installation geht reibungslos, aber dann sehe ich nach dem Start nur die Fensterumrisse ohne Inhalt.. ist das irgendein Direct(irgendwas)-Problem? Grüße
OK... hab noch ein bisschen rumgespielt... in der Anzeige-Konfiguration für die virtuelle Windows Maschine die 3D-Beschleunigung NICHT aktivieren, dann klapperts... Grüße
Vielleicht bin ich zu dumm und seh es nicht: Hat die neue Software die Funktion, dass die Syntax automatisch überprüft wird? Im moment wird erst gemeckert wenn ich auf Übersetzten geh, und da ist zB ein ";" vergessen. Im VS C# Express zB wird sofort rumgemeckert wenn schwachsinn programmier^^
Stefan schrieb: > Hat die neue Software die Funktion, dass die Syntax automatisch > überprüft wird? Im moment wird erst gemeckert wenn ich auf Übersetzten > geh, und da ist zB ein ";" vergessen. Wenns sowas gibt ist es per default jedenfalls nicht aktiviert. So sachen wie ein vergessenes Semikolon oder "vergleich statt zuweisen" ( == und = ) bleiben während des Schreibens erst mal unbelangt.
Habe die Beta-Version getestet: - Ohne Probleme beim Download und Installation auf XP SP3. - Habe durch Zufall etliche neue (tolle und mächtige) Features entdeckt. Vieles steckt anscheinend "unter der Haube". Das wird ein Grund für den hohen Sourcenverbrauch sein - Für den Xmega fehlen einige wichtige Sachen im Debugger IO-Fenster (DMA-Controller hat keine Kanäle, den Timern fehlen die CNT-, CCA- und PER-Register) - Außerdem noch etliche kleinere und größere Bugs entdeckt Fazit: Dieser Version würde ich (momentan) nur Alfa-Status geben.
Hallo, Ich finde das AVRS5 gut, es hat viele Funktionen die das Programmieren erleichtern wie z.B. die Codevervollständigung. Wenn man übrigens auf Release stellt, wird direkt auf den AVR programmiert, die Beschriftung des Buttons stimmt dann aber nicht. Da ich mich aber nicht gut genug auskenne, vermute ich das jetzt mal so. Zumindest geht das bei mir so. Hat jemand eine Möglichkeit gefunden die Rechtschreibkorrektur auszuschalten? Kann man irgendwo die Debugtiefe einstellen, ich lande immer wieder in der Delay.h wo ich eigentlich nicht rein will? VG Stefan
Stefan Rau schrieb: > Hallo, > > Ich finde das AVRS5 gut, es hat viele Funktionen die das Programmieren > erleichtern wie z.B. die Codevervollständigung. > > Wenn man übrigens auf Release stellt, wird direkt auf den AVR > programmiert, die Beschriftung des Buttons stimmt dann aber nicht. > Da ich mich aber nicht gut genug auskenne, vermute ich das jetzt mal so. > Zumindest geht das bei mir so. > > Hat jemand eine Möglichkeit gefunden die Rechtschreibkorrektur > auszuschalten? > Kann man irgendwo die Debugtiefe einstellen, ich lande immer wieder in > der Delay.h wo ich eigentlich nicht rein will? > > VG Stefan Hallo, was meinst du mit "Wenn man übrigens auf Release stellt, wird direkt auf den AVR programmiert, die Beschriftung des Buttons stimmt dann aber nicht." Mit Dank vorraus. WSHertwig
Hallo WSHertwig, du kannst von Debug auf Release umstellen, wenn man dann mit der Mouse over Funktion über den grünen Run Button geht, wird weiterhin Start Debugging angezeigt, müsste aber aber IMHO "Build Release" heißen. VG Stefan
Da das hier irgendwie zu einer schwachsinnigen Diskussion verflossen ist und ich keine Lust habe, mir zig Beiträge durchzulesen: Hat jemand im AVR-Studio 5 schon die Optimierungsoption gefunden. Alle meine alten Projekte hauen den Speicher einfach nur so voll. Danke für die hoffentlich erscheinende Antwort.
Hallo Toni, Du gehst oben auf den das Drop-Down mit dem Microcontroller. dort ein Doppelclick. Dann öffnet sich ein Menue, dort Toolchain. VG Stefan
Hi Toni, Optimierung findest du unter Projekt->"Projekt Name" Properties->Toolchain->Optimization PS: Achtung wenn der Debugger verreckt, der kann unbemerkt weiter werkeln ich hab mich schon gefragt warum meine CPU Auslastung nicht mehr unter 50% gegangen ist. Nach Virenscanner und co. bin ich mal der Sache auf den Grund gegangen und des war die avrdgb.exe die auch ohne AVR-Studio lief. Gruß Matthias
hallo zusammen, habe auch mal das AVR Studio5 getestet. Scheint ganz gut zu sein. Weiß jemand ob die Funktion "automatisches Formatieren" enthalten ist udn mit welcher Tastencombination die Funktion gestartet wird?
War das nicht Strg+A+K? Ist zumindest bei mir so, aber vielleicht habe ich mir das auch umbelegt... Mit freundlichen Grüßen, Valentin Buck
Ich finde die Visual Studio Oberfläche ganz gut... Ein bisschen langsam ist es jedoch beim Debuggen... Woraus ich nicht schlau wurde... -> Wo kann man die Prozessor Frequenz im Projekt einstellen? Im alten AVR Studio war das möglich, finde diese Option nirgends! sg
geht über den entsprechenden befehl in den projekteinstellungen. einfacher ist es, wenn du in deiner mainfile einfach in die erste zeile (auf jedenfall bevor die includes kommen) ein
1 | #define F_CPU 16000000UL
|
schreibst, dass hat den gleichen effekt und man sieht in der quelltestfile direkt was sache ist frage: kann man die optimierung auch auf diese weise festlegen?
Chriss schrieb: > Ein bisschen langsam > ist es jedoch beim Debuggen... Also auf meinem alten Dual Core läuft alles recht zügig. Das Gute am Studio 5 ist noch, dass es mit Windows7 64 Bit funktioniert. Mit Eclipse hat das nicht so richtig geklappt... .
ich debugge mit dem JTAG ICE MKII. Was genau ist denn Lahm? Wenn du von einer Codezeile in die nächste springst? Also bei mir ist es so wie in Studio4.
so habe meinen Drachen rausgehollt und damit getestet. Kann keinen Unterschied bezüglich der Schnelligkeit zwischen dem Drachen und dem JTAG ICE MKII feststellen. (sind quasi gleichschnell) Hast du dieses Firmware Update auf den Drachen gemacht? Bei mir dauert ein Steppvorgang ca. ne halbe Sekunde. Ich kann also beispielsweise drei mal hintereinander auf Stepp klicken (oder F11) und die Schritte werden relativ zügig ausgeführt. Mein Sytsem W7-64. Intel DualCore 6750. Studio5 Version 5.0.1038.1038
Hallo zusammen, z.Z.arbeite ich noch mit der Kombination Studio4 und Codevision. Nach dem compilieren mittels Cv holt sich Studio dieses File zum debuggen. Es ist also immer ein Ladevorgang nötig. Wie sieht das mit Studio5 aus? Welchen Compiler benutzt Studio? Wie sind die Vor- und Nachteile gegenüber Codevision? Kann man innerhalb des Editorfensters debuggen, ohne eine Datei nachzuladen?
AVR Studion 5 ist eine All in One Lösung. Debuggen und Code Erstellen läuft über die selbe Oberfläche. Mit einem Mausklick wird der Code erstellt und in den Debug Modus gegangen. Studio 5 benutz diesen GCC Compiler. Codevison kenn ich nicht. Der Vorteil ist jedoch, dass Studio5 kostenlos ist. Außerdem hat es zahlreiche Programierhilfen, wie automatische Kommentarerstellung bei neunen Files, Syntax highlighting usw. Viel besser als beim Studio4. Nachteil sind die relativ hohen Recorcenanforderungen. Wenn du einen Steinzeit-PC hast, wird es wahrscheinlich sehr langsam sein. Mein Rechner ist vier Jahre alt, mit einem älteren DualCore. Bei mir läuft das Programm sehr flüssig. Ich bin zur Zeit begeistert vom Studio5 obwohl es noch beta ist. Probier es doch einfach aus... .
Artur R. schrieb: > Probier es doch einfach aus... . Ja, besten Dank, werd ich machen. Schade um Codevision und hpinfotech...
Hallo also an meinem Rechner liegt es nicht, ich habe eine AMD Phenom II x6 Prozessor mit 3,3 GHz. Ich nutze das Debug Wire, könnte es daran liegen? Ich habe aber in jedem Fall einen deutlichen Geschwindigkeitsunterschied wenn ich AVR Studio4 oder Studio5 nehme. Daher arbeite ich mit dem Studio5 fast nur noch mit dem Simulator. uC ist ein Atmega88P. Bei dem ATmega328P habe ich noch das Problem, dass Studio5 den Debugmodus nicht aktivieren kann. Kennt sonst auch jemand dieses Problem?
Stefan Rau schrieb: > Ich nutze das Debug Wire Das wirds wohl sein. Ich benutze das normale JTAG. Habe noch nie DebugWire getestet. Kann man da vielleicht die Frequenz einstellen? Vielleicht ist sie zu niedrig.
Habe AVRStudio 5 installiert um einem Blick im Software zu bekommen. Das Ganze sieht aber mächtig aus nun irgendwie ganz was anderes wie AVRStudio 4 und meine Meinung nach braucht man aber viel Zeit um Funktionen, Einstellungen usw. alles wieder im Grifft zu haben (wie im AVRStudio 4) oder nicht? Wie es aussieht wird langsam Schluss mit STK500 oder? wiederum kann man von AVRStudio 5 aus mit USBasp, USBisp usw. (wie sie alle Proger heißen) Flashen.
Hallo Martin, ich habe mich sehr schnell eingefunden, kann aber auch daran liegen, dass ich vorher schon mit VS C# programmiert habe. Sonst finde ich es sehr intuitiv.. VG Stefan
Hallo Stefan, ja, sieht so aus wenn man mit VS gearbeitet hat dann sollte gleich alles im Grifft sein, Oberfläche, Editor usw. kommt ja von VS. Gruß Martin
Martin e. C. schrieb: > Wie es aussieht wird langsam Schluss mit STK500 oder? Eventuell später ! in Online Hilfe steht: Atmel STK500 Not Supported in the beta release. Martin e. C. schrieb: > wiederum kann man > von AVRStudio 5 aus mit USBasp, USBisp usw. (wie sie alle Proger heißen) > Flashen. Nöö, das geht nicht AVRStudio "Supported" nur Atmel Produkte, wie sollte mit USBasp gehen?
Habe erst alle Beiträge gelesen: Chris schrieb: > 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? Tatsächlich wird in der Online Hilfe darüber gesprochen, hier ist er bei Atmel: http://www.atmel.com/dyn/products/tools_card.asp?tool_id=17213&category_id=163&family_id=607&subfamily_id=1603 und kostet $199: http://store.atmel.com/PartDetail.aspx?q=p:10500269 Ist das ein verbessertes Dragon in Gehäuse oder wie? kostet mehr wie der Dragon aber weniger wie der JTAGICE mkII !! IchNix schrieb: > 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 :-)) Ich denke man soll nicht immer alles so übel nehmen, ich arbeite seit Jahren mit SPS und habe bis her kein Software für Linux gesehen (zu mindestens beim große Hersteller), bzw. z.B. kein Step 7 oder WinCC für Linux. Für denen ist "Anwender Software" unter Linux nicht Interessant!
Also ich würde mich nicht auf AVR Studio 5 verlassen. Dadurch das es noch ein Beta ist gibt es noch das ein oder andere Problem. Bei mir hatte ich sogar unterschiede im verhalten, wenn ich das gleiche Programm in AVR Studio 5 oder 4 übersetzt habe(auch gleiche Einstellungen des GCCs. Und irgendwie dauert auch bei mir das Übersetzen auch ewig. Also bei unerverstädnlichen Problemen ruhig mal wieder das 4er ausprobieren. Gruß Hans
Martin e. C. schrieb: > Tatsächlich wird in der Online Hilfe darüber gesprochen, hier ist er bei > Atmel: > http://www.atmel.com/dyn/products/tools_card.asp?t... > > und kostet $199: > http://store.atmel.com/PartDetail.aspx?q=p:10500269 > > Ist das ein verbessertes Dragon in Gehäuse oder wie? kostet mehr wie der > Dragon aber weniger wie der JTAGICE mkII !! Ja, das war damals weder im Store noch auf der Webseite von Atmel zu entdecken. Mittlerweile gibt es auch ein paar Bilder vim Innenleben: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=813636 Ich sehe keinen Grund, warum sich ein Umstieg vom mkII auf die neue Version lohnen sollte. Offensichtlich scheint es keine neuen Features o.ä. zu bieten. Der niedrigere Preis könnte auch daher zustande kommen, dass die Debugging Tools für 8-Bitter anderer Hersteller in letzter zeit massiv im Preis gesunken sind.
Hans W. schrieb: > Dadurch das es noch ein Beta ist gibt es noch das ein oder andere > Problem. Da gebe ich dir Recht, vielleicht könnte die Final Version doch interessant sein vor allem dass man jetzt externe Tools uvm. von AVRStudio aus verwenden kann, ich habe es nur aus "Neugier" installiert. Bei mir gabt es auch unterschiede ich habe es unter XP Installiert, kein Problem wollte es unter Windows 7 installieren und hat leider nicht geklappt! Chris schrieb: > Der niedrigere Preis könnte auch daher zustande kommen, dass die > Debugging Tools für 8-Bitter anderer Hersteller in letzter zeit massiv > im Preis gesunken sind. Das kann schon sein.
Martin e. C. schrieb: > Bei mir gabt es auch unterschiede ich habe es unter XP Installiert, kein > Problem wollte es unter Windows 7 installieren und hat leider nicht > geklappt! Ich habe unter Windows 7 64bit sowohl AVR Studio 4 als auch 5 installiert und beides tut. Die 5er bietet mir ansatzweise sowas wie Codecompletion, allerdings scheint mir das nicht so wirklich zuverlässig zu funktionieren. Manchmal bekomme ich Funktionsnamen und sogar Ports vorgeschlagen, manchmal aber auch nicht. Und manchmal muss ich z.B. PORTB erst irgendwo verwendet haben, damit er mir den später auch wieder anbietet. Irgendwie wirkt es auf mich noch sehr Beta, auch wenn dieser Begriff in den Versionsbezeichnungen im Programm selber verschwunden zu sein scheint. Nur noch beim Download taucht er auf ... hmmmm 42m
Mittlerweile gibt es das AVR Studio 5 als Beta2 (u.a. mit STK500 Support) und gleichzeitig gibt es auf der Atmel Beta Seite eine AVR Studio 4.19 Beta. Sieht so aus, als ob Studio 4.xx eine Zeit lang parallel zu Studio 5.x existieren wird.
Hallo, habs mir nun auch mal installiert und was mit rum getestet. Läuft soweit echt gut für ne Beta. Auch der Simulator läuft gut. Im Vergleich zur 4er Version echt ne große Verbesserung in Sachen Benutzbarkeit. :) Aber weiß einer, ob es ne Möglichkeit gibt dass UART ausgaben im Simulator irgendwie angezeigt werden? Klar, ich kann mit Breakpoints gucken ob was im UDR ankommt, aber ne direkt anzeige im Command-Window oder so wäre schon angenehmer :). Gruß
P. M. schrieb: > 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? Auf 128MB? ... ich habe die letzte unter 98 laufende Version unter ME mit nem Pentium MMX und 32MB EDO am laufen ^^. Reicht völlig! Nur der Start dauert etwas länger. Mir ist die Datengröße und die Verbrauchte Leistung relativ wurst (Windows User der alle 6Monate sich n neuen PC kauft ^^) aber ich finde es schon etwas übertrieben wenn ich mir andere b.z.w. ältere Versionen anschaue.
Hallo zusammen, also ich kann diese Kritik nicht ganz nachvollziehen. Wenn man hier einmal querliest macht es eher den Anschein, dass jeder verlangt, dass ein gutes Tool, kostenlos, Plattform unabhängig und supported sein soll und dabei nicht mehr als ein Editor an Resourcen verbrauchen darf. Ich persönlich finde das Studio 4.xx nicht Bedienfreundlich und in nem vernünfitgen Editor zu arbeiten und dann das Studio zum Debuggen nehmen ist auch nicht die Lösung. Ich habe beides benutzt und ich finde das Studio 5 wie es zZ zum Download ist vernünftig, zugegebener Maßen hätte ich mir, allein aus der Gewöhnung her, Eclipse gewünscht, wie auch das AVR32 Studio realisiert war. Ich selber habe auch schon mit dem Konkurrenzprodukt vom LPCExpresso gearbeitet was auf Ecplise basiert. Dieses Eclipsederivat war aber ebenfalls groß und man konnte keine zusätzlichen Tools einbinden (svn, trac...) aber es war kostenlos! Leider leider funktionierten die Treiber für den auf dem Evalboard integrierten JTAG-Adapter nur unter Windows, also trotz Eclipse nicht Plattform unabhängig. Kritisch wird es beim support für die Plattformen. Wie viel Support soll denn gegeben werden für ein Kostenloses Tool? Wie schnell ist denn der support bei kostenlosen, selberzusammengeschusterten Entwicklungsumgebungen, mit hier einem Editor, da einem Programmierer und noch einem Debugger. Ich finde es gut, dass eine SW in diesem Maße vom Atmel bereitgestellt wird. Solange man damit Produkte entwickeln kann und der gleiche compiler benutzt wird, ist die größe auf nem aktuellen Rechner nahezu vernachlässigbar. Gruß
Wo liegt denn euer Problem? Wird endlich Zeit, dass Atmel einen "State of the Art" IDE präsentiert. Verstehe euch wirklich nicht. Ihr entwickelt hoffentlich noch an Commodore Rechnern :-) RAM und Festplatten kosten ja auch nichts mehr. Deshalb - statt einfach motzen, zuerst mit dem neuen Tool herumspielen und erkennen, dass es sehr angenehm ist. Na dann, wünsche ich viel Spass!
Hallo zusammen, nach etwas Pause bin ich wieder in die AVR-Welt eingestiegen. Mit neuer Rechnerausstattung (Win 7 Professional) und dementsprechend Neuinstallation mit AVRStudio 5.0. Das Problem ist nun wie folgt: Beim Assemblen wirft das Studio die folgende Fehlermeldung aus: "Error 1 The specified task executable "AvrAsm2.exe" could not be run. Der angeforderte Vorgang erfordert erhöhte Rechte C:\Program Files (x86)\Atmel\AVR Studio 5.0\Vs\AvrAssembler.targets 4 5 PROJEKTNAME" Das mit den erhöhten Rechten brachte mich dazu, das Studio als Administrator auszuführen. Hilft nicht... Hat jemand einen Tip? Danke. PS: Gleiches Problem beim AVRStudio in Version 4.irgendwas
lockere mal die Zugriffsrechte auf C:\Program Files (x86)\Atmel\ und Unterordner oder lass deine Projekte in den Eigenen Dateien erstellern dort sollte man volle Rechte haben.
Habe die Einstellungen verändert, relaxter gehts nicht mehr. Vollzugriff für alle Benutzer. Die Projekte liegen bei mir in "Dokumente". Habe geprüft, ob ich dort alle Rechte habe: ja. Geht immernoch nicht.
erweitere das mal auf den Ordner ProgramData ist versteckt direkt unter C: oder eben gleich auf die ganze Platte mich kotzt das auch immer an das man so bevormundet wird ok manche Leute muss man vor sich selbst schützen, die klicken auf alles was irgendwie blinkt.
Mag nicht. In "ProgramData" habe ich auch keine Spuren von Studio 5.0 gefunden. Das 4.irgendwas hatte da einen Ordner. Lustig ist, dass ich den avrasm2 in einer Eingabeaufforderung starten kann. Irgendwann crasht er dann, mit -v4 kann ich sehen, dass es im zweiten Pass geschieht. Die Version ist egal, es kommt nicht darauf an, ob es die aus dem vierer- oder fünfer-Studio ist. Daniel
In AvrStudio5 ist u.a. die AVR ToolChain (C-Compiler) vorhanden. Hat diese Toolchain auch das Delay.h Problem ? Oder ist es dort gefixed ?
Habe ein Support-Ticket bei Atmel erstellt. Mal sehn, was dabei rauskommt. Lasse es wissen, wenn ich ein Resultat habe.
Ich erlaube mir an dieser Stelle mal auf einen Thread zu verweisen, den ich im gcc Forum aufgemacht habe. Der 'zündet' nicht richtig, gibt kein feedback und ich habe das Gefühl den vielleicht im gcc Forum falsch untergebracht zu haben. Ich glaube die Bedienung der Umgebung bzw. des Editors beim 5er Studio brennt einigen unter den Nägeln. Also hoffe ich - sonst würde ich von Selbstzweifeln zerfressen werden, denn ICH vermisse einige produktivitätssteigernde features schmerzlich. Beitrag "3 Fragen zu Studio 5 (Bedienung verglichen mit avr32 Studio)" mfg Frank
Update: Bei AVRFreaks kam der Tipp, UAC zu deaktivieren. Das hat nicht geholfen, obwohl das Verhalten beim Start aus dem Studio sich änderte: Statt einer Fehlermeldung gibts dann auch da gleich den APPCRASH.
Es gibt anscheinend mal wieder eine neue Version (5.0.1163). Diese wird zumindest bei mir über den Menüpunkt "Check for Updates" der Beta2 nicht gefunden. Auf der Webseite von Atmel steht auch folgender Hinweis: NOTE: AVR Studio 5.0 cannot be upgraded from its beta versions. Please uninstall any beta versions of AVR Studio 5.0 from Add/Remove programs and reinstall. http://www.atmel.com/dyn/products/tools_card.asp?tool_id=17212 Ich blick da langsam nicht mehr durch.
Hier noch der direkte Link zum Download: http://www.atmel.com/dyn/resources/prod_documents/as5installer-5.0.1163-full.exe
Chris schrieb: > AVR Studio 5.0 cannot be upgraded from its beta versions. Please > uninstall any beta versions of AVR Studio 5.0 from Add/Remove programs > and reinstall. Riecht das nicht schwer nach offiziellem Release? Mal sehen, wie sich das Teil anstellt. Ich werd gleich mal installieren :) Danke für den Hinweis. 42m
Michael Krauth schrieb: > Riecht das nicht schwer nach offiziellem Release? Ja, liest sich zumindest in den Release Notes so. Wenn ich mir allerdings die Liste der Known issues anschaue, dann ist da immer noch eine ganze Menge dran zu verbessern :-)
Interessanterweise steht beim offiziellen Download-Link nichts mehr von "Beta". (Recht mutig die Atmel-Leute) In den Relaese Notes taucht der STK500 auf- scheint neuerdings dabei zu sein, jedoch werden nicht mal alle Mitglieder einer Family unterstützt. Z.B. der ATMEGA324 ja, der ATMEGA644 nicht, eigentlich schade. Könnte das irdendwie mit den RS232-Problemen die ebenfalls in den Release-Notes angeführt werden zusammenhängen? Als Abhilfe wird vorgeschlagen den "Umweg" über einen USB-RS232-Adapter zu nehmen. Außerdem steht in der STK500-Spalte "Control" was ist hier eingeschränkt? Ich werde also erst mal mit dem "alten" Studio 4.18 SP3 weitermachen, wenn da die SW nicht so tut wie sie soll, dürfte es zu 99% an mir liegen. Hat schon mal einer die 4.19 Version getestet? (Hatte neulich hier im Forum einen Link dazu gefunden)
dann möchte ich an dieser Stelle doch gleich einmal eine Frage zum Release in den Raum stellen: Mit der VS 2010 Shell editiert es sich um Längen besser als vorher, aber die Rechtschreibkorrektur lässt sich i-wie nicht ausschalten oder auf deutsch umstellen. Ich habe von Microsoft schon die deutsche Shell installiert (dadurch wird auch ein Großteil des AVR-Studios deutsch) und das .net Framwork-Language- Pack installiert. -> immernoch kein Deutsch-Wörterbuch Hat jemand eine Idee (bisher erfolglos gegoogelt)?
Hi all, auf einen alten Post in diesem Thread bezogen (Assembler crasht) habe ich von Atmel eine Antwort erhalten: Der Assembler crasht, wenn man einen Sprung angibt, der in den negativen Bereich führt. Zur Veranschaulichung: Program Counter (PC) = 0xAD, dort steht die Anweisung "RCALL PC-0x06E0". Damit geht der Call in negative Richtung, nämlich "unter Null". Das kann die aktuelle Version nicht handhaben. Der Assembler sollte eigentlich eine Fehlermeldung "out of reach" angeben; tut er aber nicht, sondern verabschiedet sich mit einem APPCRASH. Grüße Daniel
Angehängte Dateien:
-
Zwischenablage01.jpg
120 KB
Hallo, nun habe ich auch ein Problem mit dem Studio in 5. Generation. Hat jemand schonmal mit dem MKII probiert, das EEPROM zu beschreiben? Sollte ich dies versuchen, erscheint die Fehlermeldung im Anhang. Hat jemand nen Tipp, oder sollte ich mich gleich an Atmel wenden? EDIT: Betriebssystem: Vista 64bit. Firmware vom MKII ist aktualisiert.
Ihr beschwert euch über den hohen Ressourcenverbrauch. Ich bin mir sicher, wenn der Forumbesitzer alle Gejammerbeiträge löschen würde, könnte er somit 90 % seines Webspaces einsparen!
Valentin schrieb: > Ihr beschwert euch über den hohen Ressourcenverbrauch. Ich bin mir > sicher, wenn der Forumbesitzer alle Gejammerbeiträge löschen würde, > könnte er somit 90 % seines Webspaces einsparen! ...und weitere 5%, wenn er solche Beiträge, die wie der deinige nicht wirklich hilfreich sind, löscht!
Ingolf O. schrieb > ...und weitere 5%, wenn er solche Beiträge, die wie der deinige nicht > wirklich hilfreich sind, löscht! ...und weitere 3%, wenn er solche Beiträge, die wie der deinige nicht wirklich hilfreich sind, löscht! Aber jetzt im ernst, allein wegen der IntelliSense (autovervollständigung) lohnt sich schon der Umstieg auf AVRstudio5. Als Visual Basic Programmierer weis ich diese sehr zuschätzen. Es macht einfach viel mehr spaß Code zuschreiben. Valentin Diring
Unterstützt das AVR Studio 5 eigentlich noch die AVR109 und AVR910 Protokolle oder ist das auch geopfert worden?
Ich habe mit AS5 ein seltsames Problem. Wenn ich es versuche auszuführen bekomme ich vom "Visual Studio Isolated shell" den fehler "Cannot find one or more components. please reinstall the application". wenn ich dies jedoch mache, bekomme ich noch während der deinstallation/installtions/dem reparaturvorgang den gleichen Fehler. Ich hab auch shcon an Atmel geschrieben. ich bin ich langsam echt am verzweifeln
Christian L. schrieb: > Ich habe mit AS5 ein seltsames Problem. Wenn ich es versuche auszuführen > bekomme ich vom "Visual Studio Isolated shell" den fehler "Cannot find > one or more components. please reinstall the application". wenn ich dies > jedoch mache, bekomme ich noch während der > deinstallation/installtions/dem reparaturvorgang den gleichen Fehler. > Ich hab auch shcon an Atmel geschrieben. > ich bin ich langsam echt am verzweifeln http://msdn.microsoft.com/en-us/library/ms235265.aspx Du könntest mal den dort erwähnten "Dependency Walker" auf deine avrstudio5.exe loslassen.
habe ich schon gemacht. dabei wird die ieshims.dll nicht gefunden. welche aber vorhanden ist. wenn ich diese dennoch per regsvr32 noch einmal anmelden möchte, bekomme ich die Fehlermeldung, dass der Prozedureinsprungspunkt nicht gefunden wurde. auch eine dll, welche ich aus dem Internet nachgeladen habe, brachte keine Besserung.
Christian L. schrieb: > dabei wird die ieshims.dll nicht gefunden. Die fehlt bei mir ebenfalls (genauso wie wer.dll). Allerdings läuft mein Studio ohne Probleme. Wenn dir sonst nichts fehlt, fällt mir gerade auch nichts mehr ein.
Habe genau das gleiche Problem (habe WinXP). Anscheinend hängt der Stress mit DLLs zusammen, welche auch vom IE genutz werden. Nach einem vollen Tag erfolgloser Versuche habe ich wieder Studio4 aufgespielt und bin wieder zufrieden. Wieder ein Grund mehr, für zukünftige Applikationen PICs zu verwenden (leider laufen viele alte Projekte mit AVRs, da dies damals eine innovative und preislich interessante µC-Schiene war). Die PICs sind stabiler im Preis, in der Verfügbarkeit und Abkündigungswut und in der Supportsoftware. Den Krieg PIC gegen AVR gewinnt PIC!
Hallo, im alten AVR - Studio 4 wurden die Assembler Mnemonics mit Beschreibung der Befehle angezeigt. Geht das nicht mit AVR Studio 5 oder hab ich was verpasst? Kann man das nicht als Tooltips anbinden?
- mach mal die Hilfe auf - suche nach: Assembler - klicke in den Results auf: Assembler directives - klicke auf: Instruction mnemonics Nachtrag: oder suche nach: instructions
W. S. schrieb: > - mach mal die Hilfe auf Die Frage ging vermutlich danach, ob wie in Studio 4 die Erklärung zum Befehl unter dem Cursor direkt mit F1 geöffnet werden kann. Würde mich auch interessieren (habe Studio 5 noch nicht installiert) Grüße, Peter
Habe heute nach langer Zeit wieder etwas programmieren wollen und find unter as5 mein STK 500 nicht mehr unterstützt. Sind die Balla Balla bei Atmel ? Ab in die Tonne damit ! Ds
Hi >mein STK 500 nicht mehr unterstützt. Lt. http://www.atmel.com/dyn/resources/prod_documents/as5installer-5.0.1160-release_note.pdf schon. MfG Spess
Spess, es gibt überhaupt keine RS232 Unterstützung mehr für das STK500, zumindest finde ich das nirgendwo. Ein STK 500 sehe ich auch nirgends als Zielsystem. Mag sein , dass mich die neue Oberflächhe völlig in die Irre führt. Falls das so ist, bitte ich um Hilfe ;-) DS
Wenn ich Obiges lese, frage ich mich ob ich das Studio5 jemals auf meinen Rechner aufspiele. Das Studio4 in der letzten Version ist ja ganz brauchbar, für den Preis jedenfalls. Klar, Keils µ-Vision (ich kenne nur die UV2 für die 8051-Family) ist deutlich angenehmer im Handling, kostet aber einiges. Wenn nun der STK500, wegfällt, könnte bei weiteren Projekten ATMEL rausfliegen. TI hat da einige sehr interessante Bausteine, und da kommt ein gutes Argument frei Haus! Weiß einer der Forumsteilnehmer näheres oder hat schon Erfahrungen? Denn aus den bisherigen Beiträgen schließe ich, daß der STK500 doch recht verbreitet ist. Schon mal Danke in Voraus für Tips und Anregungen.
Hallo, ich habe keine Beta, aber es gibt tatsächlich ein Update. Lade es gerade runter. Ich berichte.
Auch nach Update auf aktuelle Version keine Chance. Das STK 500 wird schlicht ignoriert, eine Programmierschnittstelle wie früher RS232-ISP wird einfach nicht unterstützt. Das AVR-Studio 5 ist für mich gestorben. DS
STK 500 schrieb: > Auch nach Update auf aktuelle Version keine Chance. > Das STK 500 wird schlicht ignoriert, eine Programmierschnittstelle wie > früher RS232-ISP wird einfach nicht unterstützt. Welchen Controller möchtest Du denn programmieren? Wie weiter oben schon angemerkt wurde, kannst Du die unterstützten Controller den Release Notes entnehmen. http://www.atmel.com/dyn/resources/prod_documents/as5installer-5.0.1160-release_note.pdf
Sack Zement, wie sieht denn Dein AVR Studio das Stk 500 ?? Über die serielle Schnittstelle ? Und wo kannst Du denn das Stk 500 selektieren, bei mir geht das jedenfalls nicht, ist nicht n der Auswahl. Bitte mach doch mal nen screenshot ! DS
Schuss ins Blaue: Du suchst unter den Project Properties unter 'Debugging' - 'Selected Debugger' und Dr. G. Reed wählt 'Tools' - 'AVR Programming' ;) Viele Grüße, Sebastian
Rene K. schrieb: > Sehe ich auch so... Lieber für ein System ein gutes Tool bereitstellen > als wieder Zwickelkrimskrams für zig andere Systeme. Wenn man denn ein gutes Tool bereitgestellt hätte. Aber nein, anstatt sich für wesentlich genügsamere und auch portablere Lösungen zu entscheiden, released man ein Programm, das höhere Anforderungen an den Rechner stellt als so manches Computerspiel vor ein paar Jahren. Wofür braucht eine IDE 2GB RAM?
gaast schrieb: > Wenn man denn ein gutes Tool bereitgestellt hätte. Aber nein, anstatt > sich für wesentlich genügsamere und auch portablere Lösungen zu > entscheiden, released man ein Programm, das höhere Anforderungen an den > Rechner stellt als so manches Computerspiel vor ein paar Jahren. Wofür > braucht eine IDE 2GB RAM? Einfach nur weil sie es können :) Hat heutzutage eh jeder genügend RAM im Rechner, wen interessiert es also ob nun was mehr RAM benutzt wird. Und was vor ein paar Jahren war ist einfach kein Maßstab... Im Gegenteil, ich finds gut wenn die Ressourcen im Rechner wenigstens auch mal ausgelastet werden :D
Sieht sehr danach aus, alte und laufende Projekte mit Studio 4 betreuen, neues Projekt, neue (TI-)-Kontroller. Aus der Atmel-Liste geht hervor, daß nicht mal eine komplette Familie (nur Unterschiede in der Speichergöße) unterstützt werden. Der Unterschied zwischen "full" und "control" wird auch nicht erläutert- Da verzichtet der Anwender dankend. Natürlich kann ich mir 'nen anderen Atmel-ISP-Programmer leisten, wozu aber?
Sebastian ... schrieb: > Schuss ins Blaue: Du suchst unter den Project Properties unter > 'Debugging' - 'Selected Debugger' und Dr. G. Reed wählt 'Tools' - 'AVR > Programming' ;) Genau. Ist so ein kleines Symbol mit einem Chip drauf, über dem ein gelber Pfeil gemalt ist. Ich hab das STK an einem ganz normalen RS232->USB Adapter an meinen PC angeschlossen. AVR Studio Version 5.0.1163
komisch...mein AVR hat einen "Tools -> Add STK500..." Menupunkt. Und dort kann ich auch eine serielle Schnittstelle auswählen. Ich habe aber kein STK500 und kann es nicht ausprobieren. In Anbetracht der Tatsache das viele Notebooks schon gar keine serielle Schnittstelle mehr haben finde ich die Meckerei schon amüsant...vor allem da es ja nichtmal begründet zu sein scheint. Und wie gesagt...aktuelleste Version runterlagen. STK500 Support kam erst mit Beta2 Und ansonsten ist die IDE 100 mal komfortabler als AVR Studio 4. Das man sich als LinuxUser ärgert das nun zu 100% auf Windows gesetzt wird...ok, kann ich nachvollziehen. Aber der Rest ist einfach worüber hier manche jammern ist doch nur affig... Ohhhh neeeein, ich bekomm die IDE nicht mehr auf zwei 3,5" Disketten. Anno 1990 ging das aber noch.... -> Scheiss Atmel Ohhhh nein, die IDE hat 2GB Ram als Anforderung... -> Scheiss Atmel Ohhh nein, die IDE läuft nicht mehr auf meinem x386 Taschenrechner... -> Scheiss Atmel Aber ich vergass...der durschnitts Forumsteilnehmer entwickelt ja auf seinem P60(die waren damals ja so schön schnell), wohnt auf dem Dorf, ist abgeschnitten von Highspeed Internet und kommuniziert am liebsten per Brieftaube...
Ein weiterer STK500 User schrieb: > Aus der Atmel-Liste geht hervor, daß nicht mal eine komplette Familie > (nur Unterschiede in der Speichergöße) unterstützt werden. Der > Unterschied > zwischen "full" und "control" wird auch nicht erläutert- Das stimmt nicht, die ausführliche Erläuterung steht direkt über der Liste:
1 | We have three kinds of support. |
2 | "Control" support means that the device can only be programmed and controlled through the target context menu. |
3 | By "debug" we mean a starting a debugging session through the launch mechanism and that the target context menu can be used. |
4 | Similarily "run" means programming and starting the application through the launch mechanism (but no debugging). |
5 | "Full" means that all these kinds are supported. |
> Da verzichtet der Anwender dankend.
Weil er nicht richtig nachliest?
Na, meinetwegen.
Aber wirf das nicht Atmel vor.
Gruß,
Thorsten
Sebastian H. schrieb: > gaast schrieb: >> Wenn man denn ein gutes Tool bereitgestellt hätte. Aber nein, anstatt >> sich für wesentlich genügsamere und auch portablere Lösungen zu >> entscheiden, released man ein Programm, das höhere Anforderungen an den >> Rechner stellt als so manches Computerspiel vor ein paar Jahren. Wofür >> braucht eine IDE 2GB RAM? > > Einfach nur weil sie es können :) > Hat heutzutage eh jeder genügend RAM im Rechner, wen interessiert es > also ob nun was mehr RAM benutzt wird. Und was vor ein paar Jahren war > ist einfach kein Maßstab... > > Im Gegenteil, ich finds gut wenn die Ressourcen im Rechner wenigstens > auch mal ausgelastet werden :D Komische Argumentation. Mein alter Laptop hatte nur 2GB RAM, wäre also schon hart an der Grenze. Viele etwas ältere Rechner haben noch weniger. Nicht jeder leistet sich alle paar Jahre einen neuen Rechner, nur zum programmieren. Auch komisch, dass das vor ein paar Jahren kein Maßstab sein soll, was hat sich denn geändert, dass heute eine IDE gleich viel Arbeitsspeicher benötigt, wie Crysis mindestens erfordert, das damals aufwändigste Spiel. Schön, wenn die Ressourcen ausgelastet werden, aber bitte nur, wenn es auch was bringt. Tut es im vorliegenden Fall nicht, schließlich handelt es sich um eine IDE, bei der man nun wirklich nicht erkennen kann, aus welchem Grund so ineffizient programmiert wurde. Aber dir wäre es wohl auch egal, wenn dein Browser 2GB RAM benötigen würde, schließlich hat den ja jeder. Und wenn er nur unter einem Betriebssystem läuft, man aber leider drauf angewiesen ist und er unter anderen Betriebssystemen aufgrund völlig unsinniger Einschränkungen nicht lauffähig ist, ist es ja auch egal. Zumindest so lange, wie du das OS nicht nutzt, auf dem das Programm nicht funktioniert (und dank Visual Studio und .NET auch nie laufen wird).
A. B. schrieb: > Ohhhh neeeein, ich bekomm die IDE nicht mehr auf zwei 3,5" Disketten. > Anno 1990 ging das aber noch.... -> Scheiss Atmel > Ohhhh nein, die IDE hat 2GB Ram als Anforderung... -> Scheiss Atmel > Ohhh nein, die IDE läuft nicht mehr auf meinem x386 Taschenrechner... -> > Scheiss Atmel > > Aber ich vergass...der durschnitts Forumsteilnehmer entwickelt ja auf > seinem P60(die waren damals ja so schön schnell), wohnt auf dem Dorf, > ist abgeschnitten von Highspeed Internet und kommuniziert am liebsten > per Brieftaube... Süß. Tolle Begründung, warum ein Programm exorbitanten Speicherverbrauch hat, obwohl nicht ersichtlich ist, warum. Ich gehe davon aus, dass es dich auch nicht weiter stören würde, wenn dein Browser, dein Textverarbeitungsprogramm, dein Mailclient, etc. pp. ähnlich ineffizient wäre? Inwiefern nun nicht Atmel schuld sein soll, erschließt sich mir nicht ganz. Schließlich haben andere IDEs auch keinen Speicherverbrauch, den man eher bei einem 4 Jahre alten Spiel vermuten würde denn bei einer Entwicklungsumgebung. Dass du von dir darauf schließt, dass alle anderen ADSL2+ und einen modernen Rechner zuhause hat, ist eigentlich recht traurig. Ich wüsste auch nicht, warum der durchschnittliche Forenteilnehmer einen Rechner > 1GB RAM besitzen sollte, wenn er ihn schlicht nicht benötigt.
Ja sorry, also 2GB hat für mich jetzt nix mit modernem Rechner zu tun...zu Hause hab ich 4GB und bei den heutigen Speicherpreisen wird das auch keinen in den Ruin stürzen btw: AVR Studio 4: ca. 25MB Speicherverbrauch AVR-Studio 5: ca 80MB Und bei dem Mehrwert den ich bekomme ist mir das relativ Wumpe. Ich sage ja nicht, das man die Systemressourcen verschwenden soll, aber man sollte einen PC nun auch nicht mit einem uC verwechseln... Und >1GB unsinnig? Das verbraucht ja heutzutage bald jeder moderne WebBrowser mit paar geöffneten Tabs... aktuell Firefox: 480MB Speicherv. PSoC Designer IDE (welche deutlich beschissener ist als AVR Studio 5) 280MB Speicherv. Aber manage deine Projekte halt weiter mit dem vi...muss mich ja nicht stören :) ps: zu Hause hab ich 5Mbit DSL, und mir sind beim Download des Studios keine grauen Haare gewachsen(und damit befinde ich mich Geschwindigkeitsmässig wohl eher am unteren Ende der Fahnenstange...Brieftaubenuser und Hintermosmutzel-Dorfbewohner mal aussen vorgelassen)
gaast schrieb: > Komische Argumentation. Mein alter Laptop hatte nur 2GB RAM, wäre also > schon hart an der Grenze. Viele etwas ältere Rechner haben noch weniger. > Nicht jeder leistet sich alle paar Jahre einen neuen Rechner, nur zum > programmieren. Auch komisch, dass das vor ein paar Jahren kein Maßstab > sein soll, was hat sich denn geändert, dass heute eine IDE gleich viel > Arbeitsspeicher benötigt, wie Crysis mindestens erfordert, das damals > aufwändigste Spiel. Schön, wenn die Ressourcen ausgelastet werden, aber > bitte nur, wenn es auch was bringt. Tut es im vorliegenden Fall nicht, > schließlich handelt es sich um eine IDE, bei der man nun wirklich nicht > erkennen kann, aus welchem Grund so ineffizient programmiert wurde. MPLAB X (Netbeans) zieht hier mit einem geöffneten Miniprojekt (nur main.c mit while(true)) ~ 230 MB RAM, beim Debuggen im Simulator ~290 MB, beim Step-Over kann man die Zeilen mitzählen... VS2010 (nicht AVR Studio 5, sollte aber sehr ähnlich sein) beim Debuggen ~150 MB, die Zeilen kann man beim Step-Over nicht mitzählen... Ein alter C++Builder, der außer einer grottenlahmen Codevervollständigung und etwas Systaxhervorhebung, nichts kann, ~60 MB RAM > Aber dir wäre es wohl auch egal, wenn dein Browser 2GB RAM benötigen > würde, schließlich hat den ja jeder. Opera/Firefox belegen hier je nach dem wie lange die laufen 500 MB - 900 MB soviel dazu. > Und wenn er nur unter einem > Betriebssystem läuft, man aber leider drauf angewiesen ist und er unter > anderen Betriebssystemen aufgrund völlig unsinniger Einschränkungen > nicht lauffähig ist, ist es ja auch egal. Welche unsinnigen Einschränkungen? Die Pflege und Entwicklung einer Software für unterschiedliche Betriebssysteme kostet immer zusätzlich Zeit und Geld. Abgesehen davon das MS daran auch kein Interesse hat, lohnt sich das nur bei einem signifikanten Marktanteil.
Arc Net schrieb: > gaast schrieb: >> Komische Argumentation. Mein alter Laptop hatte nur 2GB RAM, wäre also >> schon hart an der Grenze. Viele etwas ältere Rechner haben noch weniger. >> Nicht jeder leistet sich alle paar Jahre einen neuen Rechner, nur zum >> programmieren. Auch komisch, dass das vor ein paar Jahren kein Maßstab >> sein soll, was hat sich denn geändert, dass heute eine IDE gleich viel >> Arbeitsspeicher benötigt, wie Crysis mindestens erfordert, das damals >> aufwändigste Spiel. Schön, wenn die Ressourcen ausgelastet werden, aber >> bitte nur, wenn es auch was bringt. Tut es im vorliegenden Fall nicht, >> schließlich handelt es sich um eine IDE, bei der man nun wirklich nicht >> erkennen kann, aus welchem Grund so ineffizient programmiert wurde. > > MPLAB X (Netbeans) zieht hier mit einem geöffneten Miniprojekt (nur > main.c mit while(true)) ~ 230 MB RAM, beim Debuggen im Simulator ~290 > MB, beim Step-Over kann man die Zeilen mitzählen... > VS2010 (nicht AVR Studio 5, sollte aber sehr ähnlich sein) beim Debuggen > ~150 MB, die Zeilen kann man beim Step-Over nicht mitzählen... > Ein alter C++Builder, der außer einer grottenlahmen > Codevervollständigung und etwas Systaxhervorhebung, nichts kann, ~60 MB > RAM Warum soll denn nun AVRS5 um so viel mehr erfordern, wo doch selbst das originale Visual Studio schlank ist? >> Aber dir wäre es wohl auch egal, wenn dein Browser 2GB RAM benötigen >> würde, schließlich hat den ja jeder. > > Opera/Firefox belegen hier je nach dem wie lange die laufen 500 MB - 900 > MB soviel dazu. Na da machst du definitiv was falsch. Wenn Firefox dank nerviger Memoryleaks mal wieder 350MB braucht, ist das schon viel. Ist übrigens allgemeiner Konsens. Dass dich ein derartiger Speicherverbrauch eines Browsers nicht stutzig werden lässt, schockiert irgendwie. > Welche unsinnigen Einschränkungen? Beschränkt auf Windows und .NET? > Die Pflege und Entwicklung einer > Software für unterschiedliche Betriebssysteme kostet immer zusätzlich > Zeit und Geld. Es würde bereits reichen, auf .NET und Co zu verzichten, um es unter Wine eventuell mal lauffähig zu bekommen. Oder man setzt gleich auf Eclipse auf. Niemand sprach von unterschiedlichen Versionen, die von Atmel gepflegt werden müssen. > Abgesehen davon das MS daran auch kein Interesse hat, > lohnt sich das nur bei einem signifikanten Marktanteil. Was hat nun Microsoft oder der Marktanteil (von welchem du auch immer redest) damit zu schaffen? Und welchen Unterschied macht es für Atmel, ob man nun auf Microsofts Produkte aufsetzt (die logischerweise nicht portabel gestaltet werden), oder ob man auf proprietäre Frameworks wie .NET, die jeden Versuch, es unter Linux laufen zu lassen, im Keim ersticken, verzichtet? Wenn man auf Eclipse aufsetzen würde, bräuchte man nicht mal Wine.
A. B. schrieb: > Ja sorry, also 2GB hat für mich jetzt nix mit modernem Rechner zu > tun...zu Hause hab ich 4GB und bei den heutigen Speicherpreisen wird das > auch keinen in den Ruin stürzen Ich heb einfach mal das Relevante hervor. Warum sollte jemand, der den Rechner nur für Mails, surfen und ein bisschen programmieren nutzt, einen neuen kaufen, und nicht einfach seinen alten weiternutzen, solange der seinen Dienst tut? Weil Atmel es nicht schafft, vernünftig zu entwickeln? > Und bei dem Mehrwert den ich bekomme ist mir das relativ Wumpe. Ich sage > ja nicht, das man die Systemressourcen verschwenden soll, aber man > sollte einen PC nun auch nicht mit einem uC verwechseln... Welches Feature rechtfertigt denn den exorbitanten Speicherverbrauch? Andere IDEs schaffen es doch auch ohne. > Und >1GB unsinnig? Das verbraucht ja heutzutage bald jeder moderne > WebBrowser mit paar geöffneten Tabs... > aktuell Firefox: 480MB Speicherv. Welche denn z.B.? Nicht mal Firefox schafft es bei >20 offenen Tabs und mehreren Addons nicht über 300MB, wenn nicht (wie so oft) wieder ein Bug in erscheinung tritt. > Aber manage deine Projekte halt weiter mit dem vi...muss mich ja nicht > stören :) Tja, leider bleibt mir nichts anders übrig, da AVRS5 unter Wine nicht läuft. > ps: zu Hause hab ich 5Mbit DSL, und mir sind beim Download des Studios > keine grauen Haare gewachsen(und damit befinde ich mich > Geschwindigkeitsmässig wohl eher am unteren Ende der > Fahnenstange...Brieftaubenuser und Hintermosmutzel-Dorfbewohner mal > aussen vorgelassen) 600.000 deutscha Haushalte haben keine Möglichkeit, mit mehr als 1MBit auf das Internet zuzugreifen.
gaast schrieb: > Warum soll denn nun AVRS5 um so viel mehr erfordern, wo doch selbst das > originale Visual Studio schlank ist? Die 2 GB sind die empfohlene Speicherausstattung (VS braucht auch tatsächlich noch ein OS und hin und wieder will man auch noch was anderes machen ohne das dauernd Daten auf die Festplatte ausgelagert werden oder man möchte alle Funktionen der IDE nutzen). > >>> Aber dir wäre es wohl auch egal, wenn dein Browser 2GB RAM benötigen >>> würde, schließlich hat den ja jeder. >> >> Opera/Firefox belegen hier je nach dem wie lange die laufen 500 MB - 900 >> MB soviel dazu. > Na da machst du definitiv was falsch. Bin nur zu faul immer alle möglichen Tabs/Fenster zu schließen. Das können durchaus 20 bis 30 oder mehr werden. > Wenn Firefox dank nerviger > Memoryleaks mal wieder 350MB braucht, ist das schon viel. Ist übrigens > allgemeiner Konsens. Nicht wirklich, teilweise > 1GB http://support.mozilla.com/en-US/questions/799397 ist einer von vielen ähnlichen Kommentaren zum FF4 > Dass dich ein derartiger Speicherverbrauch eines > Browsers nicht stutzig werden lässt, schockiert irgendwie. Weil das bei den anderen Browsern nicht viel anders ist. http://www.favbrowser.com/internet-explorer-9-ie9-vs-firefox-4-vs-google-chrome-10-vs-opera-11-vs-safari-5/ > Es würde bereits reichen, auf .NET und Co zu verzichten, um es unter > Wine eventuell mal lauffähig zu bekommen. Oder man setzt gleich auf > Eclipse auf. Eclipse ist weder genügsamer, noch schneller als Netbeans oder gar VS. > Niemand sprach von unterschiedlichen Versionen, die von > Atmel gepflegt werden müssen. Atmel müsste auch dann unterschiedliche Versionen pflegen, wenn auch "nur" Testumgebungen, Treiber, Installer, müsste Support für die div. Konfigurationen (Eclipse, Linux-Distributionen etc.) leisten u.s.w.
Hallo, so ignorant ist ATMEL dann doch nicht. Es funktioniert ! Unter Tools gibts nach dem Update auf die jetzt aktuelle Version einen extra Menüpunkt "Add STK500". Danach erscheint das STK500 unter AVR Programming und ich kann einen MC auswählen und es läuft ! Auch über die serielle Schnittstelle !!! Version ist : Atmel AVR Studio 5 (Version: 5.0.1163) © 2011 Atmel Corp. All rights reserved. DS
Arc Net schrieb: > Nicht wirklich, teilweise > 1GB > http://support.mozilla.com/en-US/questions/799397 ist einer von vielen > ähnlichen Kommentaren zum FF4 Sag ich doch, Memory Leak. Allein die Tatsache des mit der Zeit wachsenden Speicherhungers lässt darauf schließen. Arc Net schrieb: > Eclipse ist weder genügsamer, noch schneller als Netbeans oder gar VS. Aber genügsamer als AVRS5. Aber danke dass du mir sagst, dass die zwei GB nicht von AVRS5 genutzt werrden, da wäre ich doch tatsächlich nie draufgekommen, ebensowenig wie darauf, dass man doch wirklich ein OS braucht (das natürlich allein schon 1,5GB RAM belegt). Wer Ironie findet darf sie behalten. Im übrigen habe ich es auch nie mit Visual Studio verglichen und schon gar nicht mit Netbeans, welches ich nie erwähnte. Arc Net schrieb: > Atmel müsste auch dann unterschiedliche Versionen pflegen, wenn auch > "nur" Testumgebungen, Treiber, Installer, müsste Support für die div. > Konfigurationen (Eclipse, Linux-Distributionen etc.) leisten u.s.w. Blödfug. Solche Dinge werden oft von der Community bereitgestellt, es würde fürs erste völlig reichen, auf proprietäre Frameworks zu verzichten, so dass das ganze eventuell mal unter Wine laufen würde. Es würde sich wohl genug User finden, die sich hier engagieren würde, wenn es nicht schon am AVR Studio selbst scheitern würde.
> Nicht mal Firefox schafft es bei >20 offenen Tabs und mehreren Addons > nicht über 300MB, wenn nicht (wie so oft) wieder ein Bug in erscheinung > tritt. komisch...bei mir scheinen die FF Bugs Alltag zu sein. Bei mir schluckt FF5 momentan im Sekundentakt mehr Speicher...aktuell bin ich bei ~800MB. FF hat in der Hinsicht Macken ohne Ende, obwohl die ich-surf-mit-extrem-vielen-offenen-tabs Fraktion(zu der ich auch gehöre) davon stärker betroffen zu sein scheint. Aber reg dich ruhig weiter über die 2GB vom AVR Studio auf(die es im Endeffekt ja gar nicht benötigt...) Und im gleichen Atemzug Eclipse als Alternative vorschlagen. Das Eclipse resourcensparend ist, hab ich bisher nicht mitbekommen. Und ein aktuelles Linux mit Desktopumgebung macht mit < 1GB Ram auch total viel Spass...ne ist klar. Mein Name ist Hase und zu meinen Hobbys gehört Ostereier verstecken Hättest du einfach nur gesagt Atmel ist doof weil AVR momentan nicht unter Wine läuft...ok, ärgerlich. Aber der Rest deiner Aufhänger ist in meinen Augen einfach Grütze. (Ja, in MEINEN...das tangiert dich natürlich nicht) Aber eigentlich ist di eDIskussion auch müssig, da Atmel sich nunmal für diesen Weg entschieden hat
Also ich muss sagen, dass ich mit AVR Studio 5 im Moment überhaupt nicht so richtig klarkomme. Die Bedienung scheint umständlicher geworden zu sein, die Entwicklungsumgebung ist total aufgebläht und auf meinem Netbook mit 1GB ram läuft das ganze nur seeehr stockend. Hallo? Das ist eine Entwicklungsumgebung. Normalerweise sollte es möglich sein, dass dies eines der schnellsten Programme auf dem ganzen Rechner ist. Was macht diese Software mit den ganzen Resourcen? Ich meine.. das Teil zeigt doch quasi nur Text an. Ich finde das echt ätzend und bin schwer enttäuscht von Atmel, dass die nicht weiter ihr AVR Studio 4 verbessert haben.
Kann mir jemand sagen wie ich mit AVR5 an die Calibration Bytes der verschiedenen RC frequenzen komm?
Moin, kann es sein, daß das AS5 nach der letzten Microsoft Update-Runde keine Programmer mehr (er)kennt? Das AS4 sieht meinen AVRisp mkII, AS5 nicht. Hat jemand die gleiche Erfahrung gemacht? Gruß Carsten
Carsten Wille schrieb: > Moin, > > kann es sein, daß das AS5 nach der letzten Microsoft Update-Runde keine > Programmer mehr (er)kennt? Das AS4 sieht meinen AVRisp mkII, AS5 nicht. > Hat jemand die gleiche Erfahrung gemacht? > > Gruß > Carsten Hat sich erledigt! Habe versuchsweise den AVRStudio5-part-pack-installer-AVR_XMEGA_AU-0.1.73.exe für die USB-ATXmega nachinstalliert. Danach gings dann wieder. Carsten
A. B. schrieb: > komisch...bei mir scheinen die FF Bugs Alltag zu sein. Bei mir schluckt > FF5 momentan im Sekundentakt mehr Speicher...aktuell bin ich bei ~800MB. Und ob du es glaubst oder nicht, gerade ständig steigender Speicherverbrauch weißt wieder mal auf ein Memory Leak hin.
Hallo, ich wollte gerade einen Attiny25 mit AVR Studio 5 und STK500 flashen, aber leider kann ich diesen µC nicht auswählen. Es stehen nur der Attiny13 und Attiny13a zur Vefügung. Muss das so sein? Ich hoffe nicht, denn dann muss ich jetzt das alte drauf machen. Naja, bis auf den besseren Editor ist Version 5 (bis jetzt) ja eh ein Schuss in den Ofen gewesen. Gruß Paul
vip schrieb: > Und ob du es glaubst oder nicht, gerade ständig steigender > Speicherverbrauch weißt wieder mal auf ein Memory Leak hin. ach ne?! ernsthaft? Das war auf den Beitarg von einem Vorposter bezogen, das sein Firefox nicht soviel Speicher verbraucht wenn nicht gerade ein Bug auftritt. Bei mir scheint dieser Bug ganz normal zu sein, weil ich eben meistens so einen hohen Speicherverbrauch im FF habe
Mal ernsthaft: Studio5 ist ein ziemlicher Krampf. Die Code-Ergänzung ist eine ziemliche Lachnummer, das ist z.B. ein Feature das in Eclipse schon seit vielen Jahren einfach nur funktioniert. Atmel posaunt das als große Neuerung raus... o0 Die Startzeit auf meinem Notebook (QuadCore i7, 16GB RAM, 500GB HD, Win7 Prof.) ist ausreichend lang um sich mit ner Senseo nen Kaffee zu kochen. Die Projektverwaltung ist ebenfalls etwas, hmmm, altbacken? Man hat eine Solution, die wiederum hat mehrere Projekte - fertig. (Oder hab ich da was übersehen?!?) Da bleib ich lieber bei meiner Eclipse, die Oberfläche ist mir mittlerweile bekannt und vertraut und dank Java und GCC Toolchain auch auf den allermeisten Betriebssystemen lauffähig. (Ich persönlich verwende MacOSX private und Linux im Büro, Eclipse incl. AVR-Toolchain läuft auf beiden...) Grüße, Christian
Na dann verwende doch MacOS10 und all den Kram dazu. Was sollte dich daran hindern ? Ich jedoch denke dass es nur eine Frage de rZeit ist, bis die Tür für diese Chains von ATMEL geschlossen wird. Einfach keinen Support mehr für Fremdsysteme anbieten - das wird reichen. Es müssen nur genug KUNDEN umsteigen. Wir sehen ja, wie weit man mit einem JTAG-MK-1 Adapter clone kommt. Der wurde vor Jahren aufgegeben und bis Datum funktioniert er. So lange es noch MPU's gibt die sich damit programmieren lassen - wird es das Ding noch geben. Nun, genau so verhält es sich mit den Entwicklungswerkzeugen. Keine Unterstützung für die Tools unter Linux/UNIX oder so, wird da nicht soviel gehen. Der JTAG MK3 macht auch kein Hexenwerk und wird sich nicht viel anders als eine MK2 verhalten. Also warum sollte der nicht am Mac laufen ? Eclipse und Toolchain gibt es doch - warum also die Kritik? Wer das AVR-STUDIO 5 nicht mag, solls einfach lassen. Erst recht wenn die eigene Umgebung um Längen besser sein soll. Jupp
Alexxx schrieb: > Hallo, > > 14.11.11: Jetzt gibt es die Version 5.01163; > Bin gerade am testen. Es gibt nur diese Version, und die ist schon lange (seit Mai 2011) auf dem Markt...
Hallo zusammen, musste leider auf avr studio 5 umsteigen, da avr studio scheinbar keinen timer2 für den atmega32 supported und ich leider randvoll bin (also nicht ich, sondern die Timer, d.h. ich kann nicht wechseln) Über die Qualität lasse ich mich hier jetzt mal nicht aus: Projektstruktur, die (Nicht)Möglichkeit Files einfach ins Projekt zu ziehen, usw... ABER: Riesenproblem: Ich möchte mein IAR compiliertes Projekt debuggen und jedesmal wenn ich mir eine Variable anzeigen lassen will, stürzt es komplett ab. Mir ist schon klar, dass meine Anforderungen etwas <Zynik>speziell<!Zynik> sind, aber hatte jemand schon ähnliche Probleme und somit vielleicht auch eine Lösung dafür?
Sorry: Fehlinformation! AVR Studio stürzt nicht ab, sonder der "Local Debug Agent has disconnected. Debugging will now be terminated." Das Output Window zeigt: 20:30:42.448: [ERROR] Could not create project associated with the object file that was opened for debugging. An error occured when constructing project information from the data specified for project creation. # Signature overridden: 1e 95 0fUnsupported typeclass 0 20:33:15.553: [WARNING] The avrdbg process exited with code 3221225725 20:33:15.770: [WARNING] TCF command: Expressions:create receiving failed, channel is closed 20:33:27.114: [ERROR] Processes:terminate:Timed Out Code:0 ,Service: ,Message from peer: 20:33:27.115: [ERROR] Failed to terminate the session. 20:33:27.117: [ERROR] Tool:disconnect:Timed Out Code:0 ,Service: ,Message from peer: 20:33:27.118: [ERROR] Tool:tearDownTool:Timed Out Code:0 ,Service: ,Message from peer: 20:33:27.117: [ERROR] Error occured when trying to disconnect from tool, see output/log for details. # Started communication server. # Signature overridden: 1e 95 0fUnsupported typeclass 0 20:34:54.321: [WARNING] TCF command: Expressions:create receiving failed, channel is closed 20:34:54.330: [WARNING] The avrdbg process exited with code 3221225725 20:35:18.997: [ERROR] Processes:terminate:Timed Out Code:0 ,Service: ,Message from peer: 20:35:18.997: [ERROR] Failed to terminate the session. 20:35:18.998: [ERROR] Tool:disconnect:Timed Out Code:0 ,Service: ,Message from peer: 20:35:18.998: [ERROR] Tool:tearDownTool:Timed Out Code:0 ,Service: ,Message from peer: 20:35:18.998: [ERROR] Error occured when trying to disconnect from tool, see output/log for details.
Hi >musste leider auf avr studio 5 umsteigen, da avr studio scheinbar keinen >timer2 für den atmega32 supported... Und du meinst nicht, wenn es so wäre, das nicht schon jemand vor dir bemerkt hätte? MfG Spess
Christian T. schrieb: > Die Startzeit auf meinem Notebook (QuadCore i7, 16GB RAM, 500GB HD, Win7 > Prof.) ist ausreichend lang um sich mit ner Senseo nen Kaffee zu kochen. Beim ersten Start ja, beim 2. geht es bei mir in 15s, obwohl meine Cpu nochmal deutlich schwächer ist.
spess53 schrieb: > Hi > >>musste leider auf avr studio 5 umsteigen, da avr studio scheinbar keinen >>timer2 für den atmega32 supported... > > Und du meinst nicht, wenn es so wäre, das nicht schon jemand vor dir > bemerkt hätte? > > MfG Spess Verstehe nicht, warum hier in diesem Forum permanent so ein schnippischer Ton herrscht. Entbehrlich! AvrStudio4 liefert: AVR Simulator: IO Module: TIMER2 (AvrMasterTimer.MasterTimer) not supported Dummerweise habe ich die Meldung darüber übersehen: AVR Simulator: ATmega328 is not supported. Check Part XML file and report this error to avr@atmel.com Der ATmega328P wird supported! Warum nur die P-Variante wissen vermutlich nur die Franzosen... Das AvrStudio5 Problem besteht allerdings weiterhin (auch wenn es jetzt nicht mehr so dringend ist, danke Spess)
Hi Du hattest 'timer2 für den atmega32 ' geschrieben. Da wäre nämlich schon vor Jahren ein Aufschrei durch die Massen gegangen. MfG Spess
Bei mir startet das Studio 5 in 6 sekunden. Win 7, Phenom II X2 3,1 GHz, 4GB DDR2, allerdings von SSD. Dass es beim Start von HDD zum kaffe holen reicht kann ich aber kaum glauben. Wenn das keine überspitzte formulierung ist passt irgendwas anderes nicht. @Wolfgang Bin mir nicht gantz sicher, ob ich deine Probleme richtig verstehe, aber ich versuchs mal. Dateien importieren kann man recht einfach, wenn man im "Solution Explorer" fenster mit rechts auf den Namen des Projekts klickt (Projekt, nicht die solution). Dann unter "Add" "Existing Item" wählen. In dem erscheinenden Dialog kannst du auch mehrere Dateien gleichzeitig auswählen. Sebastian
Angehängte Dateien:
-
AVR5-Einstellungen.png
67 KB
Hallo allerseits, ich bin ein Einsteiger und tue dies mit version 5 von AVR´s Studio. Jetzt hab ich fast mein komplettes Werk programmiert und bin vor kurzem auf eine Tastkombination gekommen, die die Darstellung ändert. Und zwar sieht das ganze wie auf meinem Bild aus, also es werden Pfeile dargestellt (Tabs) und Punkte (Leerzeichen). Ich finde es total nervig und will es deswegen wieder abschalten. Ich hab mich jetzt schon seit mehr als einer Stunde druch alle Einstellungen gewühlt aber habs einfach nicht hinbekommen. Wäre genial, wenn jemand weiß wo man das wieder auf "normal" umstellt!
Hi Beim 4er Studio schaltet man das mit Edit-> Show Whitespace an und ab. MfG Spess
Danke vielmals!! als ich wusste wonach ich suchen musste hab ich es innerhalb weniger sekunden gefunden: AVR5: Edit - Advanced - "View White Space"
Nun ja, es bleibt weiterhin spannend. Auch die Beta 5.1.148 hat noch mehr Bugs als ein Hund Flöhe. Jetzt kann man noch nicht einmal mehr beim Artifact Name einen Multi-Dot-Dateinamen verwenden. Traurig. Ein Multi-Dot-Name, z.B. Projekt_V1.01 wird mal als Projekt_V1.elf und später als Projekt_V1.01.hex übergeben. Fällt so etwas eigentlich bei automatisierten Produktionstests nicht mehr auf?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.