www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR-Studio 5


Autor: Robert N. (metrux)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Moin,

Hab grad gesehen, dass es das AVR-Studio seit eben als Beta gibt.

http://www.atmel.com/microsite/avr_studio_5/defaul...

Mal sehen wie's ist.

Gruß

Rob

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich guck´s mir mal auf der 'embedded world' an, bevor ich hier ein 
halbes GiB durch die Leitung sauge...

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schlimmer als fettige Fritten: 522 MByte aufgeblähte Software aus dem 
Hause Atmel.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

Autor: Antwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deswegem vielleicht Beta-version. Vielleicht springen sie noch um bei 
genügend negativen Rückmeldungen. Hoffnung habe ich aber nicht wirklich.

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: IchNix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Einhart Pape (einhart)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STK500 wird nicht mehr unterstützt :-( - na klasse!

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rene K. (draconix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Uwe ... (uwegw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ohne Worte...

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>ohne Worte...

Ohne Verstand.

MfG Spess

Autor: P. M. (o-o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Loonix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P. M. schrieb:
> Hat denn das AVR Studio 5 irgendwelche Features, die dermassen Resourcen
> brauchen?

Its not a bug, its a feature ;)

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: EEFUSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: I. L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Grübler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???)

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: micro1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene K. (draconix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: nicht "Gast" (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..."

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> darf ich fragen woher ihr die videos habt?

Hier: 
http://www.atmel.com/microsite/avr_studio_5/defaul...

Autor: P. M. (o-o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: ... - - - ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... - - - ... 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.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... - - - ... schrieb:
> Der Fortschritt sieht anders aus.

Kommandozeile, oder was?

mfg.

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: P. M. (o-o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... :-)

Autor: Jonas M. (tschortsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss man sich für den DL anmelden? Oder gibts irgendwo noch nen 
inoffiziellen DL?

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: P. M. (o-o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Markus J. (markusj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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/

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Herr beschütze mich vor Software die von Rainer Z. stammt.

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Jaeger schrieb:
> Der Herr beschütze mich vor Software die von Rainer Z. stammt.

Kannst Du auch gar nicht bezahlen. ;-)

Autor: Helfer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atmel wendet nur Architectural Best Practices an.
http://geekandpoke.typepad.com/geekandpoke/2011/03...

Autor: nicht "Gast" (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Genervt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genervt schrieb:
> Herrje ist dieses Forum schlimm!

Danke. Den Eindruck habe ich auch gewonnen.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rainer Z. schrieb:
> Vorteil

"Solution Explorer" nennst du Vorteil?

Autor: Rainer Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: FortschrittMitHirn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-))

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. R. (redegle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: stk500 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Report #13722: STK500 is not supported in beta release.
STK500 support is scheduled for final release of AVR Studio 5.0

Autor: Carsten Sch. (dg3ycs)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: download ohne reg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: kritiker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Decker (t0mmy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fairerweise muss man sagen, dass GCCs ureigene IDE, der Emacs, einstmals 
ob seines erheblichen RAM-Verbrauchs als "Eight Megabytes And Constantly 
Swapping" verspottet wurde ;-).

Autor: kritiker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

gibt es denn irgendwelche Infos, dass das STK500 vielleicht in späteren 
Versionen wieder unterstützt wird?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin e. C. (eduardo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oh Mann!!! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Oh Mann!!! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grammatik & Rechtschreibung = 6-!

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh Mann!!! schrieb:
> "Algemeiner Vertrauensfehler"

Sieht nicht nur komisch aus, klingt auch komisch.

Autor: meckermensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-!
???

Autor: Oh Mann!!! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Funktioniert Beides nicht... Ich nutze WinXP SP3.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: IchNix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Sebastian M. (sebastian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat schon jemand nen c++ projekt damit kompilieren können??
wenn ja, wie???

Autor: Trololo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pete K. (pete77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
An alle Verschwörungstheoretiker, die jetzt glauben auf ihren geliebten 
Atmega8 verzichten zu müssen: siehe Anhang.

mfg.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: IchNix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: IchNix (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian M. (sebastian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

hat denn nun schon jemand das studio 5 dazu gebracht, c++ zu übersetzen?

Autor: IchNix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Eckmann schrieb:
> Und was steht da?

Und was schrieb ich?

>  Kombination Studio 5 + AVR Dragon

Worauf dann prompt eine Verschwörungstheorie unterstellt wurde.

Autor: André Wippich (sefiroth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: UC3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Carsten Wille (eagle38106)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/a...

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Valentin Buck (nitnelav) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: AVerr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mikki Merten (mmerten)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: AVerr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benutzt doch ein Downloadmanager. Ich zieh mit über 200kb/s.

Autor: Knut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Bert 0. (maschinist)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...


Gruß...Maschinist

Autor: Günter R. (muntablues)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: IchNix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter Rudigier schrieb:
> Proggen funzt

Komisch, ich kann Leute die proggen und funzt sagen nicht ernst nehmen.

Autor: Günter R. (muntablues)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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"...

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

Bewertung
0 lesenswert
nicht lesenswert
Günter Rudigier schrieb:
> Was hab ich geschrieben was du nicht glaubst

Dass das "Proggen funzt". ;-)

Autor: Günter R. (muntablues)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Knut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Müssen noch irgendwelche Pfade eingestellt werden?

Autor: Koal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

???

Autor: Günter R. (muntablues)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: soundso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wehrmutstropfen:

AVR Studio 5 Beta installiert sich nicht auf Win7 64Bit ...

...

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: AVerr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: FReiling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andy S (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 :)

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Hauptsache es funktioniert mit .asm-Dateien.

MfG Spess

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!

Autor: Andy S (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
/Mein-Loop###################################################
  while(1)
  {
    sensoren_RE = PIND;
    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

Autor: Joachim K. (minifloat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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

Bewertung
0 lesenswert
nicht lesenswert
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&f...

Autor: IchNix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerhard Hinze (oderlachs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: jfhjd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ärgert euch nicht über Sachen die in der Beta Version nicht 
funktionieren

Autor: Thomas S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: edgar S. (hbl333)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: IchSchon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IchNix, d.h. "Ich nix verstehen, bin blond", oder so...

Autor: IchAuch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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>

Autor: Serieller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&f...

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Mango gibts doch!

Atmega32 fehlt im Simulator warum auch immer.
Sowas find eifach schwach von Atmel.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibts nen Grund ausgerechnet den Mega32 wegzulassen?
Der ist kostengünstig und hat auch schon ein JTAG-Interface.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist bereits genannt worden: AvrStudio5 (beta) enthält nur den
Simulator2. Und der unterstützt den m32 auch in AvrStudio4 nicht.

Autor: Sami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wan kommt denn voraussichtlich die volle verbesserte version die das 
stk500 unterstützt??

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris L. (kingkernel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat es bisher einer geschafft im AVR Studio 5 die HV-Programmierung des 
Dragon zu finden?

Autor: Mr. Greenhorn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
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/...

> 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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
In addition, there was a paged direct addressing mode for
accessing variables placed in the data memory. 
[...]
To expand the reach of the displacement mode, we needed to change
other parts of the instruction set to get enough coding space. 
At the same time, we were informed that the paged direct accessing 
mode was difficult to use from the compilers point of view. 
By removing the paged direct addressing mode, space was made 
available for expanding the displacement to 64 locations, which is
large enough to meet most demands for indirect addressing. 
The paged direct addressing mode was changed to a two word unpaged 
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++.

Autor: Luky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: jonas biensack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Loonix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: docean (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

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

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris L. (kingkernel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Andreas Paulin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Chris L. (kingkernel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Eckmann schrieb:
> Antwort kam von heute auf morgen.

Jetzt bin ich neugierig: Wie viel die denn aus?

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt sinnvoll und positiv, nicht nur das übliche "wird an 
entsprechende Stellen weitergeleitet".

Autor: vorbeigeschlendert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: vorbeigeschlendert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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^^

Beitrag #2096233 wurde von einem Moderator gelöscht.
Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alexxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Rau (stefanrau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: WSHertwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Rau (stefanrau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Rau (stefanrau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, vielen Dank. Ich habs :)

Autor: Artur R. (artur2000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Valentin Buck (nitnelav) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chriss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris L. (kingkernel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
#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?

Autor: Artur R. (artur2000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... .

Autor: Stefan Rau (stefanrau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bei mir ist das Debuggen auch recht lahm.

Ich habe den AVR Dragon, was hast Du?

Autor: Artur R. (artur2000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Rau (stefanrau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, wenn ich von einer Zeile zur nächsten springe, Wartezeit teilweise 
1s.

Autor: Artur R. (artur2000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hokuspokus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Artur R. (artur2000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... .

Autor: Hokuspokus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Artur R. schrieb:
> Probier es doch einfach aus... .

Ja, besten Dank, werd ich machen.
Schade um Codevision und hpinfotech...

Autor: Stefan Rau (stefanrau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Chris L. (kingkernel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schick ne Mail an Atmel, sonst wird sich da nicht tun

Autor: Artur R. (artur2000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin e. C. (eduardo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Rau (stefanrau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin e. C. (eduardo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Martin e. C. (eduardo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?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 !!


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!

Autor: Hans W. (hans_w30)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&f...

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.

Autor: Martin e. C. (eduardo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Krauth (michael_k42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Visitor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Michael Dierken (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: AVR32-Neuling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: MIke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!