Hi, Wolte mir grad AVR Studio runterladen und hab festgestellt dass Mikrochip die Atmel Website vom Netz genommen hatt. Jegliche Linkeintrag in Google führt zu denen ihrer Hauptwebsite wo Atmelzeug quasi totgeschrieben wird... Wo bekomme ich jetzt noch AVR Studio V4.19 her?
Franzl F. schrieb: > Jegliche Linkeintrag > in Google führt zu denen ihrer Hauptwebsite wo Atmelzeug quasi > totgeschrieben wird... Das war mir gestern auch aufgefallen, als ich per Google nach einem Datenblatt für einen AVR gesucht habe und dann die ersten paar Suchergebnissse, die auf atmel.com zeigen, nicht funktionierten. Alle Links auf atmel.com scheinen kaputt zu sein. Das heißt auch, dass jetzt hier im Forum und im Wiki sämtliche Links auf atmel.com nicht mehr funktionieren…
In der Tat, AVR Studio V4.19 ist seit 7 Jahren obsolet ;). Was spricht gegen das Atmel Studio 7? Der Direct Link funktioniert hingegen noch und es ist die aktuelle Version. PS: Soweit ich weiß, wird irgendwann demnächst die Atmel µC in MPLAB IDE X integriert - wann das steht wohl in den Sternen.
@Nils N. (nils_h494) >In der Tat, AVR Studio V4.19 ist seit 7 Jahren obsolet ;). Was spricht >gegen das Atmel Studio 7? Die Tatsache, daß diese Software dermaßen aufgeblasen ist, daß sie auch "normalen" PC in Zeitlupe läuft! Nur auf einer wirklich schnellen, aktuellen Kiste mit viel RAM und SSD ist die Geschwindigkeit akzeptabel. AVR-Studio dagegen läuft selbst auf leicht betagten Rechnern flüssig.
Ist zwar jetzt alles etwas schwieriger zu finden, aber noch zu bekommen: http://www.microchip.com/avr-support/avr-and-sam-downloads-archive
Falk B. schrieb: >> Was spricht gegen das Atmel Studio 7? > > Die Tatsache, daß diese Software dermaßen aufgeblasen ist, daß sie auch > "normalen" PC in Zeitlupe läuft! Nur auf einer wirklich schnellen, > aktuellen Kiste mit viel RAM und SSD ist die Geschwindigkeit akzeptabel. > > AVR-Studio dagegen läuft selbst auf leicht betagten Rechnern flüssig. Die rasante Geschwindigkeit von AS7 liegt wohl an .NET & Co. Man kann nur hoffen, dass das sich unter der Regie von Microchip bessert.
Ohje, bitte nicht auf Netbeans umstellen, das sagt mir garnicht zu, bin an die Visual Studio Shell gewöhnt.
Korinth schrieb: > Man kann nur hoffen, dass das sich unter der Regie von Microchip > bessert. Da würde ich nicht die Luft anhalten. Die haben sich an Atmel dermaßen verschluckt, dass sie zusehen müssen, wie man zumindest das, was sich verkaufen lässt, in Gewinn ummünzt. Ein paar neue AVRs (AVR8X-Architektur) passen da ins Konzept, aber das Neuschreiben einer (letztlich funktionierenden) Software, um sie durch eine andere zu ersetzen mit neuen Bugs, die dann bloß anderen Leuten nicht gefällt – das bringt doch keinen Gewinn.
Jörg W. schrieb: [...] > Die haben sich an Atmel dermaßen verschluckt, [...] Hast Du da etwas detailliertere Informationen, bitte? Das interessiert mich. Wie schätzt Du die Zukunft der ursprünglichen AVR-Serie ein (die noch herausgebracht wurde, als Atmel eigenständig war)?
Theor schrieb: > Wie schätzt Du die Zukunft der ursprünglichen AVR-Serie ein (die noch > herausgebracht wurde, als Atmel eigenständig war)? Ist doch kein Problem: Microchip hat direkt nach der Übernahme zugesagt, dass sie alle Atmel-ICs produzieren werden, solange es (zahlende) Nachfrage danach gibt. Da das auch in der Vergangenheit bei ihren eigenen ICs gängige Policy war, gibt's eigentlich keinen Zweifel, dass sie sich daran halten werden. Was es sicher nicht geben wird, sind neuere ICs für die älteren Serien. So, wie es jetzt aussieht, ist alles Neue aus der AVR8X-Architektur, eine Art Xmega-Architektur, die man speziell auf nicht so große Speicherausbauten optimiert hat (maximal 48 KiB Flash). Ist auch verständlich, denn im Bereich nach oben hin ist sowieso ARM allemal die bessere Lösung für den Kunden, und den hat Microchip ja dank des Atmel-Kaufs gleich mal mit geerbt. Von Cortex-M0+ bis Cortex-M7 ist ja da alles Mögliche dabei.
@Jörg Wunsch (dl8dtl) (Moderator) >Die haben sich an Atmel dermaßen verschluckt, Wenn Manager den Hals nicht voll kriegen . . . >>wie man zumindest das, was sich verkaufen lässt, in Gewinn ummünzt. >Ein paar neue AVRs (AVR8X-Architektur) passen da ins Konzept, aber >das Neuschreiben einer (letztlich funktionierenden) Software, um sie >durch eine andere zu ersetzen mit neuen Bugs, die dann bloß anderen >Leuten nicht gefällt – das bringt doch keinen Gewinn. Trotzdem werden derartig zweifelhafte Dinge gemacht, warum auch immer.
Nils N. schrieb: > In der Tat, AVR Studio V4.19 ist seit 7 Jahren obsolet ;). Was spricht > gegen das Atmel Studio 7? de.wiktionary.org zu "obsolet": ------------------------------ Bedeutungen: [1] außer Gebrauch geraten [2] überflüssig geworden (irrtümliche Bedeutung) ------------------------------ In der Tat: Weder ist AVR Studio V4.19 außer Gebrauch geraten noch überflüssig geworden, denn es ist eine einfache, schnelle und stabile IDE die es ermöglicht viele Programmieraufgaben für AVR Controller schnell, unkompliziert und ohne grossen Overhead zu erledigen.
Sebastian Puffpaff schrieb: > Weder ist AVR Studio V4.19 außer Gebrauch geraten noch > überflüssig geworden Doch, es ist dahingehend überflüssig geworden, weil es seit Jahren nicht mehr gepflegt wird und damit keinerlei Aktualisierungen mehr bekommen hat. Ein großer Teil der aktuellen Produktpalette wird folglich davon nicht unterstützt, der eingebaute, selbst gestrickte Debugger erbricht sich, wenn ein neuerer GCC ihm zwar standardkonformes DWARF vorsetzt, von welchem er jedoch selbst keine Ahnung hat, und der Debugger funktionierte sowieso nur mit explizit auf ihn zugeschnittener Debughardware, die vergleichsweise teuer war und nun auch seit geraumer Zeit nicht mehr produziert wird. ps: Ich habe weder AVR Studio benutzt noch benutze ich Atmel Studio. Nicht, dass du mich hier als Protagonisten des letzteren vermutest. ;-)
:
Bearbeitet durch Moderator
Sebastian Puffpaff schrieb: > Weder ist AVR Studio V4.19 außer Gebrauch geraten läuft aber schlechter als 4.18 zu dem ich reuemütig zurück ging Jörg W. schrieb: > der eingebaute, selbst gestrickte > Debugger erbricht sich wars das? ich weiss nicht debugger fand ich schon immer schwierig gerade in Echtzeit, was nutzt ein Breakpoint da, wenn alles schon vorbei ist. Man hat ja selten das Problem im Code nur das Problem im Zeitverhalten und Zusammenspiel oder das der Stack überläuft.
@Joachim B. (jar) >> Weder ist AVR Studio V4.19 außer Gebrauch geraten >läuft aber schlechter als 4.18 zu dem ich reuemütig zurück ging Metoo! Ist die letze, gute Version, die ohne Klimmzüge noch mit dem avr gcc zusammenarbeitet. Wenn man mit den unterstützten ICs auskommt, ist es die deutlich bessere Wahl. Neuere ICs brauchen dann halt Atmelstudio 7 8-0
Sebastian Puffpaff schrieb: > Weder ist AVR Studio V4.19 außer Gebrauch geraten Joachim B. schrieb: > läuft aber schlechter als 4.18 zu dem ich reuemütig zurück ging Mit meiner Einschätzung ist die ganze "ältere" Studio Familie natürlich eingeschlossen. Ich verwende ebenfalls 4.18
Jörg W. schrieb: > Theor schrieb: >> Wie schätzt Du die Zukunft der ursprünglichen AVR-Serie ein (die noch >> herausgebracht wurde, als Atmel eigenständig war)? > > Ist doch kein Problem: [...] Dankeschön für Deine Einschätzung. Das war sehr freundlich von Dir. Ich muss sagen, dass ich mehr als bloße Neugier empfinde; es geht für mich auch um Planung. > ... nach der Übernahme zugesagt, > dass sie alle Atmel-ICs produzieren werden, solange es (zahlende) > Nachfrage danach gibt. Was mich vor das Problem stellt zumindest Anhaltspunkte dafür zu finden, ob und wie viel Nachfrage es gibt (und wo sich Microchip da eine Grenze gesetzt hat). Es liegt in der Natur der Sache, dass da kaum jemand konkrete Information haben wird. Aber wenn jemand wenigstens konkrete Hinweise auf indirekte Indikatoren geben kann, interessiere ich mich dafür. Falls jemand zu dem ersten Teil meiner Frage Informationen oder Links hat, wäre ich dafür dankbar. Ich schrieb: Jörg W. schrieb: [...] >> Die haben sich an Atmel dermaßen verschluckt, [...] > Hast Du da etwas detailliertere Informationen, bitte? Das interessiert mich. Insbesondere würden mich auch Links zu der vom TO gemachten Aussage interessieren > [...] wo Atmelzeug quasi totgeschrieben wird ... Bei meiner eigenen Suche, konnte ich leider nichts finden, dass ich ausdrücklich oder auch nur zwischen den Zeilen gelesen, als "totschreiben" interpretieren konnte.
Theor schrieb: > dass ich ausdrücklich oder auch nur zwischen den Zeilen gelesen, als > "totschreiben" interpretieren konnte. Sehe ich auch so. Wenn sie etwas verkaufen können, dann verkaufen sie's. Ungeschickte Webserver-Umbauten hat Atmel auch ganz allein in der Vergangenheit schon geschafft, da verwundert es nicht, dass bei der Integration der beiden Webauftritte irgendwo was ins Holpern kommt. Joachim B. schrieb: > ich weiss nicht debugger fand ich schon immer schwierig gerade in > Echtzeit, was nutzt ein Breakpoint da, wenn alles schon vorbei ist. Muss man halt an den Stellen setzen, wo es passt. Zwischendrin, wo Echtzeit wichtig ist, kann man zur Not ja ein paar (volatile) Hilfsvariablen einfügen und sich dort einige interessierende Werte reinschreiben. Man kann gewiss im Embedded-Bereich nicht immer alles schön online debuggen, trotzdem sind diese diversen Debugwerkzeuge eine wirkliche Hilfe, Probleme schneller einkreisen zu können, als man das mit "printf-Debugging" tun konnte.
#metoo ...dann bin ich nicht der einzige der von AS7 schockiert ist. Die alte 4.1x läuft auf dem alten xp NB noch wie d'zau! Klaus.
Jörg W. schrieb: > Microchip hat direkt nach der Übernahme zugesagt, dass sie alle Atmel-ICs > produzieren werden, solange es (zahlende) Nachfrage danach gibt Was verstehen die unter Nachfrage, welche Stückzahlen? Silabs z.B. hat erklärt dass Sie auch Ihren ersten 8051 aus dem Jahr 2000 nicht abkündigen werden.
Theor schrieb: > Jörg W. schrieb: > [...] >>> Die haben sich an Atmel dermaßen verschluckt, [...] > >> Hast Du da etwas detailliertere Informationen, bitte? Das interessiert >> mich. > > Insbesondere würden mich auch Links zu der vom TO gemachten Aussage > interessieren http://www.elektroniknet.de/markt-technik/halbleiter/was-fuer-ein-jahr-148954.html Zitat:
1 | Und so geht es weiter. Auch Norbert Siedhoff, Managing Director bei Microchip Technology, verweist auf die Unternehmenszahlen, die ganz klar zeigen: »2017 war ein Superjahr. Bis jetzt sieht es so aus, als ob wir eine Wachstumsrate –ohne Atmel – gegenüber dem Vorjahr von über 15 Prozent erreichen werden, wobei ich betonen möchte, dass das Jahr noch nicht zu Ende ist: Unser Fiskaljahr geht von April bis April, also zwei Drittel sind rum. Mit den 15 Prozent lägen wir schon über unseren eigenen Erwartungen von 12 Prozent.« |
Lothar schrieb: > Silabs z.B. hat erklärt dass Sie auch Ihren ersten 8051 aus dem Jahr > 2000 nicht abkündigen werden. Erklären kann man natürlich viel … Selbst Maxim hat halt irgendwann den MAX038 aufgeben müssen, und der ist mit gutem Preis verkauft worden. Irgendwo muss es für den Hersteller natürlich immer eine sinnvolle Balance geben zwischen dem noch mit einem bestimmten Bauteil erzielbaren Umsatz und den Aufwänden, die man stemmen muss, um eine hornalte Fertigungslinie am Leben zu erhalten. Zumindest um alle die AVRs mit einem "A"-Suffix würde ich mir keine Sorgen machen: diese haben einen Fab-Transfer in eine der ostasiatischen Groß-Fabs durchgemacht (TSMC, meine ich mich zu erinnern). Da sollten sie erstmal einigermaßen zukunftssicher sein. Einen AT90S1200 wiederum hat man selbst von Atmel halt schon ein paar Jahre lang nicht mehr kaufen können.
Jörg W. schrieb: > Zumindest um alle die AVRs mit einem "A"-Suffix würde ich mir keine > Sorgen machen: Auch ATmega328*A? Die B-Varianten sind ja schon *etwas* anders.
Johann L. schrieb: > Jörg W. schrieb: >> Zumindest um alle die AVRs mit einem "A"-Suffix würde ich mir keine >> Sorgen machen: > > Auch ATmega328*A? Sehe ich nirgends. ATmega48A und ATmega88A gibt es, ATmega168 und ATmega328 gibt's nicht als A. Ich meine jetzt nicht das "A" in der Gehäusebezeichnung (hinter dem Bindestrich), sondern das, was direkt nach der Zahl bzw. dem Picopower-"P" steht. > Die B-Varianten sind ja schon *etwas* anders. Ja, bei ATmega168 und ATmega328 scheinen die PBs die einzigen zu sein, die aktuell im Programm sind.
Falk B. schrieb: > > Die Tatsache, daß diese Software dermaßen aufgeblasen ist, daß sie auch > "normalen" PC in Zeitlupe läuft! Nur auf einer wirklich schnellen, > aktuellen Kiste mit viel RAM und SSD ist die Geschwindigkeit akzeptabel. > AVR-Studio dagegen läuft selbst auf leicht betagten Rechnern flüssig. Ich hab AS7 im Büro auf einem 6 Jahre alten i3 mit 2Gb ram und normler HDD laufen. Geht wunderbar. Programmiert ihr alle mit 486er Rechnern oder was?
Was man an der Stelle nicht vergessen darf bzw. viele nicht wissen: Atmel Studio 7 ist beim Start nicht das schnellste Pferd, was aber am Indexer liegt. Den kann man auch irgendwo abschalten, aber dann hat man keine Autovervollstaendigung, etc. mehr.
:
Bearbeitet durch User
Quelle? schrieb: > Theor schrieb: >> Jörg W. schrieb: >> [...] >>>> Die haben sich an Atmel dermaßen verschluckt, [...] >> >>> Hast Du da etwas detailliertere Informationen, bitte? Das interessiert >>> mich. >> >> Insbesondere würden mich auch Links zu der vom TO gemachten Aussage >> interessieren > OK. Ich bedanke mich für den Link und das Zitat. > http://www.elektroniknet.de/markt-technik/halbleiter/was-fuer-ein-jahr-148954.html > > Zitat: > >
1 | > |
2 | > [...] Bis jetzt sieht es so aus, als ob wir |
3 | > eine Wachstumsrate –ohne Atmel – gegenüber dem Vorjahr von über 15 |
4 | > Prozent erreichen werden, |
5 | > [...] |
6 | > |
Wobei die ausdrückliche Herausnahme von Atmel aus der Aussage über die Umsatzerwartung, nach meiner Erfahrung, in der Regel bedeutet, dass gerade *dieser* Geschäftsbereich Verluste oder jedenfalls deutlich geringere Gewinne (die den Gesamtgewinn merklich schmälern) einfährt. Oder hat da jemand andere Erfahrungen? Danke auch für die zusätzliche Info von Jörg, über den Transfer der Fertigung der A-Varianten nach Ostasien. Allerdings muss ich zugegeben, dass ich da doch auch auf eine Erklärung angewiesen bin, warum dieser Transfer einer Erhöhung der Sicherheit bedeutet, dass diese Typen noch längere Zeit verkauft werden. Wäre vielleicht jemand so nett, mir dazu eine Erklärung zu geben?
Fabian F. schrieb: > Falk B. schrieb: > >> >> Die Tatsache, daß diese Software dermaßen aufgeblasen ist, daß sie auch >> "normalen" PC in Zeitlupe läuft! Nur auf einer wirklich schnellen, >> aktuellen Kiste mit viel RAM und SSD ist die Geschwindigkeit akzeptabel. > >> AVR-Studio dagegen läuft selbst auf leicht betagten Rechnern flüssig. > Ich hab AS7 im Büro auf einem 6 Jahre alten i3 mit 2Gb ram und normler > HDD laufen. Geht wunderbar. Programmiert ihr alle mit 486er Rechnern > oder was? Kann die Beobachtung von Falk nur stützen: bei mir ist insbesondere das Starten(20 bis 30 s) das Debuggen (nicht einmal annähernd Echtzeit) und das Aufwachen nach dem sleep modus sehr langsam. Selbst das Laden eines Projekts geht langsam (5 - 10 s). i3-3220, 3,3 GHz, 4 GBytes RAM, 64 Bit Geschwindigkeitsprobleme habe ich nur mit AS7
Theor schrieb: > Allerdings muss ich zugegeben, dass ich da doch auch auf eine Erklärung > angewiesen bin, warum dieser Transfer einer Erhöhung der Sicherheit > bedeutet, dass diese Typen noch längere Zeit verkauft werden. Weil ein Fertiger wie TSMC eine Weile Perspektive hat, was man von manchen der veralteten Atmel-Fabs nicht sagen konnte. ;-) Die hatten sie aber bereits vor dem Aufkauf durch Microchip fast alle abgestoßen. Die "A"-Versionen sind "die shrinks": durch den Transfer in eine modernere Fab kann man mit kleineren Strukturen arbeiten als in der vorherigen Fab. Um das gleiche elektrische Verhalten wie zuvor zu bekommen, wird zwar das aktive Silizium weiterhin im Layout genauso behandelt wie in der alten Technologie, entsprechend der kleineren Strukturen benötigt man aber viel weniger Fläche für die Verdrahtung. Damit reduziert sich die gesamte Chipfläche.
@ Fabian F. (fabian_f55) >> Die Tatsache, daß diese Software dermaßen aufgeblasen ist, daß sie auch >> "normalen" PC in Zeitlupe läuft! Nur auf einer wirklich schnellen, >> aktuellen Kiste mit viel RAM und SSD ist die Geschwindigkeit akzeptabel. >> AVR-Studio dagegen läuft selbst auf leicht betagten Rechnern flüssig. >Ich hab AS7 im Büro auf einem 6 Jahre alten i3 mit 2Gb ram und normler >HDD laufen. Geht wunderbar. Wirklich? Wie lange dauert der Programmstart? Wie lange das Öffnen eines Projekts? Wie lange das öffnen der Projekteigenschaften? Das dauert bei MIR EWIG! Ohne Witz. Programmstart: 1m 45s ein KLEINES Projekt mit 3 Quelldateien öffnen: 1min Projekteigenschaften öffnen und Tab Toolchain öffnen: 1min Die Quelltextzeingabe ist auch eher zäh, man merk daß sich da jemand quält. Aber Hauptsache Online Rechtschreibkorrektur!!! Mann O Mann! > Programmiert ihr alle mit 486er Rechnern oder was? Nö, ein nicht ganz taufrischer Laptop mit Dual Core 1,5GHz, 2GB RAM, normale 160GB Festplatte.
@Karl (Gast) >Kann die Beobachtung von Falk nur stützen: bei mir ist insbesondere das >Starten(20 bis 30 s) das Debuggen (nicht einmal annähernd Echtzeit) und >das Aufwachen nach dem sleep modus sehr langsam. Selbst das Laden eines >Projekts geht langsam (5 - 10 s). Du Glücklicher!!! >i3-3220, 3,3 GHz, 4 GBytes RAM, 64 Bit >Geschwindigkeitsprobleme habe ich nur mit AS7 Dito!
Franzl F. schrieb: > Jegliche Linkeintrag > in Google führt zu denen ihrer Hauptwebsite wo Atmelzeug quasi > totgeschrieben wird... Von der Hauptseite microchip.com sind es 4 Klicks bis zum Atmel Studio 7 (ca. in der Mitte der Seite auf Design Support -> Development Tools -> Software Tools for AVR -> Atmel Studio IDE). Auf die Produktseiten mit parametrisierbarer Suche sind es ganze 5 Klicks. Zur MPLAB-X IDE sind es übrigens auch 4 Klicks, zur parametrisierbaren Suche nach PICs sind auch 5 Klicks. Also totgeschrieben ist das Atmelzeug sicher nicht... auf der Startseite wird aktuell sogar ein AVR Board beworben... Karl schrieb: > Kann die Beobachtung von Falk nur stützen: bei mir ist insbesondere das > Starten(20 bis 30 s) das Debuggen (nicht einmal annähernd Echtzeit) und > das Aufwachen nach dem sleep modus sehr langsam. Selbst das Laden eines > Projekts geht langsam (5 - 10 s). > > i3-3220, 3,3 GHz, 4 GBytes RAM, 64 Bit > > Geschwindigkeitsprobleme habe ich nur mit AS7 Ich entwickle in der Firma mit einem i5 und 8GB (Notebook) und dort ist die Performance ohne Probleme. Auch beim Debugger... Startzeit ist mir persönlich egal... ich verstehe nicht, warum das für manche so ein Problem darstellt? Kann es vielleicht am i3 liegen?
Jörg W. schrieb: > Sehe ich nirgends. ATmega48A und ATmega88A gibt es, ATmega168 und > ATmega328 gibt's nicht als A. Kleine Korrektur: 328 nicht, 168 schon. https://www.microchip.com/wwwproducts/en/ATmega168A
Projekt öffnen: 3s AS7 starten: 10s. Ich habe aber auch einen aktuellen Arbeitslaptop. Ich würde dennoch nicht zu einer 7 Jahre alten AVR Studio Version greifen. Und so häufig wechsel ich Projekte auch nicht. Einmal aufmachen und dann arbeitet man doch einige Zeit daran oder nicht?
Jörg W. schrieb: >> [...] > Weil ein Fertiger wie TSMC eine Weile Perspektive hat, ... Nochmal Dank für die Antwort. Jörg. Also ein wirtschaftliches Argument; es werden weniger Resourcen gebraucht. OK. Ich möchte mich in einer wichtigen Hinsicht korrigieren. Ich habe oben suggeriert, dass ich "Erfahrung" mit solchen Äusserungen über Gewinnaussichten habe. Das ist nicht der Fall. Ich bin eher Logiker, Techniker und Mathematiker als Kaufmann. Jedoch scheint mir, eine Nachfrage an sich gerechtfertigt. Ich überlege, warum jemand einen Unternehmensbereich aus einer Äusserung über die Gewinnererwartungen heraus nimmt und komme auf folgende Möglichkeiten: 1. Der herausgenommene Bereich macht Verluste oder allenfalls Gewinne die den zum Vergleich mit dem Vorjahr ermittelten Prozentsatz verringern - OK. Das bei Übernahmen, der übernommene Bereich ein wenig einknickt, scheint mir schon vorgekommen zu sein. 2. Der Bereich macht ungefähr soviel Gewinn wie die anderen Bereiche - dann scheint es mir nicht plausibel, diesen Bereich herauszunehmen. Die Übernahme wäre ja ein Erfolg. Es besteht allerdings die Möglichkeit, dass ein Grund wie bei dem folgenden Punkt 3 vorliegt. 3. Der Bereich macht mehr Gewinn, als die anderen Bereiche - dann würde man evtl. überlegen, dass man die eigenen, bis zur Übernahme entwickelten Produkte diskreditieren würde, gestände man das ein. Wäre das aber effektiv wichtiger als einen steigenden Gesamtgewinn auszuweisen? Sieht jemand Anhaltspunkte für eine oder mehrere dieser Möglichkeiten oder auch weitere Möglichkeiten?
Nils N. schrieb: > In der Tat, AVR Studio V4.19 ist seit 7 Jahren obsolet ;). Was spricht > gegen das Atmel Studio 7? Der Direct Link funktioniert hingegen noch und > es ist die aktuelle Version. > > PS: Soweit ich weiß, wird irgendwann demnächst die Atmel µC in MPLAB IDE > X integriert - wann das steht wohl in den Sternen. Das wäre aber ein gewaltiger Rückschritt der Gcc im C18 Compiler ist kastriert und kann kein C++.
Falk B. schrieb: > @ Fabian F. (fabian_f55) > Wirklich? Wie lange dauert der Programmstart? Wie lange das Öffnen eines > Projekts? Wie lange das öffnen der Projekteigenschaften? Das dauert bei > MIR EWIG! Ohne Witz. > > Programmstart: 1m 45s > ein KLEINES Projekt mit 3 Quelldateien öffnen: 1min > Projekteigenschaften öffnen und Tab Toolchain öffnen: 1min Dann stimmt was mit deinem Rechner nicht. Programmstart:35s Großes Projekt öffnen (>20000 Zeilen): 22s Debbugging starten: 8s(kleines Projekt) 22s (Großes Projekt). Verglichen mit den 5 Kaffees bis Matlab/Simulink gestartet ist, ist das Blitzschnell. > Nö, ein nicht ganz taufrischer Laptop mit Dual Core 1,5GHz, 2GB RAM, > normale 160GB Festplatte. Das ist allerding auch Antik. In meinem ist ein i3 21xx quad core. Auch alt, aber immerhin aus diesem Jahrtausend.
Vor kurzem hatte Microchip in Elektronik Zeitschriften wie ‚Elektronik Praxis‘ in der Heftmitte 20 Seiten Werbung auf Hochglanzseiten - aber ausschließlich für die Pic Produkte und Tools. AVR oder Atmel wurde da mit da mit keinem Wort erwähnt. Ich finde das zeigt schon wieviel Wert man da auf die Stiefgeschwister legt.
@ Fabian F. (fabian_f55) > Dann stimmt was mit deinem Rechner nicht. Möglich. Oder aber mit Atmelstudio, das eine seiner Teilkomponenten vermurkst installiert hat, weil vielleicht eine Vorgängerversion schon drauf war. Keine Ahung. >> Nö, ein nicht ganz taufrischer Laptop mit Dual Core 1,5GHz, 2GB RAM, >> normale 160GB Festplatte. >Das ist allerding auch Antik. In meinem ist ein i3 21xx quad core. Auch >alt, aber immerhin aus diesem Jahrtausend. Nun sag mir mal, was so ein bisschen GUI und Hintergrundgeraffel mit 4 CPUs macht? Andere Programme sind auch schnell!
Falk B. schrieb: > Nö, ein nicht ganz taufrischer Laptop mit Dual Core 1,5GHz, 2GB_RAM , > normale 160GB Festplatte. Ich würde, wenn es möglich ist, beim RAM etwas machen, 2GB ist, für moderne Software, schon sehr knapp, heute liest man oft 8GB empfohlen, 4GB mindestens. Was Atmel Studio 7 verlangt weiß ich jetzt nicht auswendig. Falls am RAM nichts zu machen ist, solltest Du über eine SSD als Ersatz für die Festplatte nachdenken, das spürst Du garantiert ordentlich, nicht nur beim Atmel Studio. Mit freundlichen Grüßen - Martin
@Johannes S. (jojos) >Ich finde das zeigt schon wieviel Wert man da auf die Stiefgeschwister >legt. Hmm. Aber wäre es so clever, für Atmel so viele Millionen (3500 Millionen!) hinzublättern, um dann mittelfristig die Produkte in der Versenkung verschwinden zu lassen? Nur damit man den bösen Konkurrenten ausgeschaltet hat? Ob DAS die Microchip Strategie ist?
Ich weiß es nicht, das fiel mir nur beim durchblättern auf. Es gibt sicher noch genug Bestandskunden um die Kosten zu decken, aber mit so einer Anzeige sagt man doch: “für neues nehmt lieber Pic“
Johannes S. schrieb: > Ich weiß es nicht, das fiel mir nur beim durchblättern auf. Es gibt > sicher noch genug Bestandskunden um die Kosten zu decken, aber mit so > einer Anzeige sagt man doch: “für neues nehmt lieber > Pic“ Macht Mittelfristig wenig Sinn 8/32 Bitter auf zwei Schienen laufen zu lassen. Ich denke die AVRs werden auslaufen. Wg. dem Bedarf noch über Jahre vefügbar, aber ohne neue Entwicklungen. Atmel war ja wohl in erster linie wg. ARM interessant. An der SAM-Front kommt ja auch beständig neues.
Theor schrieb: > Ich überlege, warum jemand einen Unternehmensbereich aus einer Äusserung > über die Gewinnererwartungen heraus nimmt und komme auf folgende > Möglichkeiten: Naja, ist halt die Frage, wie du das überhaupt rechnen willst. Setzt du den kompletten Kaufpreis als Minus an und die tatsächlich im Jahr erzielten Einnahmen aus diesem Bereich als Plus, dann hast du logischerweise erstmal massive Verluste zu beklagen. Solch ein Kauf kann sich ja unmöglich innerhalb eines Jahres amortisieren (wenn Atmel solche großartigen Gewinne gemacht hätte, hätten sie sich bestimmt nicht kaufen lassen müssen ;-). Insofern ist es natürlich, wenn man mit einem vorangegangenen Jahr vergleichen will, durchaus sinnvoll, nur Äpfel mit Äpfeln zu vergleichen. Ob nun die aus dem Atmel-Anteil erzielten Gewinne den vorher gehegten Erwartungen entsprechen oder nicht, bleibt eine völlig andere Geschichte. Die, die die genauen Zahlen darüber kennen, werden sie sehr wahrscheinlich nicht in die Öffentlichkeit posaunen (wollen). :)
Fabian F. schrieb: > aber ohne neue Entwicklungen. Die aktuelle Politik spricht eine andere Sprache: es werden neue AVR8X-Chips rausgebracht in einer Frequenz, die es bei Atmel in den Jahren zuvor so im AVR-Bereich nicht mehr gab. Ich habe munkeln gehört (ist aber wirklich nur Gerüchteküche, nichts Belegbares), dass man in Trondheim wieder aufgestockt hat – nachdem zuvor allmählich immer mehr von dort nach Chennai verlagert worden ist. Wenn man AVRs hätte allmählich „austrocknen“ wollen, hätte man sich meiner Meinung nach dahingehend anders benommen …
@ Johannes S. (jojos) >sicher noch genug Bestandskunden um die Kosten zu decken, aber mit so >einer Anzeige sagt man doch: “für neues nehmt lieber >Pic“ Naja, ich gehe davon aus, daß es vor der Übernahme und erst recht jetzt nach der Übernahme heftige Diskussionen um die Strategie gibt. Und auch knallharte Graben- und Überlebenskämpfe.
Ach, naja ich weiß ja nicht wie verwöhnt ihr seid. Im Gegensatz zu SW4STM, oder allgemein alles Eclipse basierendes, läuft AS7 bei mir absolut tadellos. Abgesehen vom Programmstart von AS7, welcher sich (nicht gemessen) ein paar Sekunden gönnt, geht das eigentlich Reibungslos. Viel schneller empfinde ich AVR Studio 4 nun auch nicht. Somal ich die Vorzüge von AS7 garnicht mehr missen mag. EDIT: Zugegeben - in Verbindung mit Visual Studio auf dem gleichen Rechner, gab es sehr derbe Probleme anfänglich. (Nicht affindbare Toolchains etc...) Hat MS aber nun mittlerweile in den Griff bekommen.
:
Bearbeitet durch User
Falk B. schrieb: > Das dauert bei MIR EWIG! Ohne Witz. > > Programmstart: 1m 45s Vielleicht solltest du ja auf Linux umsteigen und das Ganze in einer VM laufen lassen, Falk. :.) Hab's mal spaßeshalber probiert: Start von AS7 in der VM dauert hier um die 20 Sekunden. Dabei habe ich die VM eben frisch „aufgetaut“, d. h. sie musste sich ggf. massiv Hauptspeicher dafür via Swap freiräumen (normalerweise läuft eine andere VM, aber da habe ich kein AS7 drin). Spielt aber interessanterweise kaum eine Rolle: Programm schließen und neu starten dauert ebenfalls wieder 20 s. Öffnen eines (allerdings kleinen, ich benutze das Studio ja nicht für die Arbeit) Projekts dauert knapp 10 Sekunden. Ich finde das alles nicht berauschend schnell, aber ich bin ohnehin kein großer Freund dieser IDE-Monster. Emacs ist einfach schneller :), insbesondere gewohnter. Den benutze ich seit mehr als 25 Jahren, und die Tastenbelegung hat sich seitdem kaum geändert – meine Projekte dagegen schon. Die VM hat übrigens 4 GiB RAM und eine CPU. (Der Host ist ein Core-i5 mit 4 CPU-Kernen.)
@Jörg Wunsch (dl8dtl) (Moderator) >Vielleicht solltest du ja auf Linux umsteigen und das Ganze in einer >VM laufen lassen, Falk. :.) JEHOVA, JEHOVA!!! >Öffnen eines (allerdings kleinen, ich benutze das Studio ja nicht >für die Arbeit) Projekts dauert knapp 10 Sekunden. Ist immer noch fragwürdig. Was Zu Henker macht diese Software in 10s mit einer GHz CPU? >Ich finde das alles nicht berauschend schnell, aber ich bin ohnehin >kein großer Freund dieser IDE-Monster. Emacs ist einfach schneller :), Faustkeil! >Die VM hat übrigens 4 GiB RAM und eine CPU. (Der Host ist ein Core-i5 >mit 4 CPU-Kernen.) Daß meine Hardware ein wenig betagt ist, ist mir klar. Aber der Wurm steckt garantiert in irgendwelchen nebulösen Inkompatiblitäten irgendwelcher Softwaremodule. Egal, ich nutze Atmelstudio 6.2 so gut wie gar nicht, hab das nur mal vor Jahren für ein ATXmega-Projekt gebraucht. Irgendwann gibt es einen neuen Rechner und gut.
Falk B. schrieb: > Was Zu Henker macht diese Software in 10s mit einer GHz CPU? Rumrödeln, hin und her gucken. :-) Netzwerk ist in der VM hier übrigens abgeklemmt, ist also nicht so, dass sie jetzt erst das halbe Internet durchsuchen würde.
Falk B. schrieb: >>Öffnen eines (allerdings kleinen, ich benutze das Studio ja nicht >>für die Arbeit) Projekts dauert knapp 10 Sekunden. > > Ist immer noch fragwürdig. Was Zu Henker macht diese Software in 10s mit > einer GHz CPU? Bei 2 GHz sind das immerhin 20 Milliarden Taktzyklen. Ein C64 war meistens gar nicht so lange am Stück eingeschaltet, dass er dabei so viele Taktzyklen zusammen bekäme.
Rolf, schöner Vergleich! Ich habe beide Versionen auf dem gleichen Asus i7 mit 8GB laufen...eine ratzfatz, die andere schnarchlangsam. Vermtl aber Konflikte mit anderen Paketen etc, hatte ich schon vermutet. Aber Scheiße bleibt halt Scheiße. Klaus.
Klaus R. schrieb: > Rolf, schöner Vergleich! Ich habe beide Versionen auf dem gleichen Asus > i7 mit 8GB laufen...eine ratzfatz, die andere schnarchlangsam. Vermtl > aber Konflikte mit anderen Paketen etc, hatte ich schon vermutet. Aber > Scheiße bleibt halt Scheiße. > > Klaus. Das ist .NET gesagt.
Rolf M. schrieb: > [...] 20 Milliarden Taktzyklen. Ein C64 war meistens gar nicht so > lange am Stück eingeschaltet, dass er dabei so viele Taktzyklen > zusammen bekäme. Bei 1MHz sind das 20000 Sekunden also gut 5 1/2 Stunden. Auch nicht sooo exorbitat.
Jörg W. schrieb: > Theor schrieb: >> Ich überlege, [...] und komme auf folgende >> Möglichkeiten: > > Naja, ist halt die Frage, wie du das überhaupt rechnen willst. > [...] Ja. Richtig. Du nennst da einen Punkt, an den ich gar nicht gedacht habe, Jörg. > Ob nun die aus dem Atmel-Anteil erzielten Gewinne den vorher gehegten > Erwartungen entsprechen oder nicht, bleibt eine völlig andere > Geschichte. Die, die die genauen Zahlen darüber kennen, werden sie > sehr wahrscheinlich nicht in die Öffentlichkeit posaunen (wollen). :) Ja. Es bleibt unklar, wie bei dieser Äusserung gerechnet wurde, wenn auch eine gewisse Wahrscheinlichkeit dafür spricht, dass sowohl der Erwerb als auch die laufenden Geschäfte im AVR-Bereich aus dieser Äusserung über die Gewinnaussichten herausgenommen wurde. Also hat der Link von "Quelle?" (Beitrag "Re: AVR-Studio Obsolet?") - meiner Ansicht nach - gar keine (oder allenfalls eine geringe) Aussagekraft in Bezug auf das Thema Zukunft von AVR. Ein geringer Gehalt steckt insofern darin, als das mit dem Wohlergehen von Microchip (ausser AVRs) die Wahrscheinlichkeit höher ist, dass AVRs weiter lieferbar sind, als wenn es Microchip nicht gut geht.
Dann gebe ich meinen Senf auch noch dazu (gemessen mit einer schönen, alten Omega Taschenuhr im Stahlgehäuse :-) ): Studio-Version Start Studio Start Projekt AS 4.19 0:05 0:02 AS 6.2 1:31 0:27 (in VM 4 GB, 2 Kerne) AS 7.0 0:16 0:08 auf einem älteren (6 - 8 Jahre ?) Tower mit I7, 2,67 GHz udn 16 GB RAM. Ich mag die höheren Versionen wegen des Komforts (z. B. der Formatierung) und der Debug-Möglichkeiten (natürlich nicht in Echtzeit). Ob das nun 10 Sekunden länger dauert oder nicht ist mir egal. Mit AS 7 habe ich leider Probleme mit extern eingebundenen Librarys - ich hoffe, da gibt sich noch (nur für Projekte mit "Upgrade").
Falk B. schrieb: > Programmstart: 1m 45s ... > ein nicht ganz taufrischer Laptop mit Dual Core 1,5GHz, 2GB RAM, > normale 160GB Festplatte. Dieter F. schrieb: > 0:16 ... > auf einem älteren (6 - 8 Jahre ?) Tower mit I7, 2,67 GHz udn 16 GB RAM. Das passt alles widerspruchslos zusammen. Von nix kommt halt nix. Oliver
Oliver S. schrieb: > Das passt alles widerspruchslos zusammen. Von nix kommt halt nix. Ja, mit einem Holzvergaser-Auto brauche ich einige Zeit, um von a nach b zu kommen :-). In Relation zu einem Pferde-Fuhrwerk bin ich natürlich sagenhaft schnell ... Ich kann mit einem Handbohrer genau so gute Löcher bohren, wie mit einer Hand-Bohrmaschine ... Hinkt alles, ich weiss - so wie ich lieber auf eine mechanische Uhr schaue und andere auf ihr Smartphone :-). So what ...
@Oliver S. (oliverso)
>Das passt alles widerspruchslos zusammen. Von nix kommt halt nix.
Quatschkopf! Andere Programme brauchen nicht mal ansatzweise die gleiche
Zeit und leisten das Gleiche oder mehr! Es ist nicht die vermeintliche
Leistungsschwäche der Hardware sondern die Schlampigkeit der Software!
Und daß besonders Microsoftprodukte die reinste Bloatware sind, ist ein
offenes Geheimnis!
:
Bearbeitet durch User
Ändert alles nichts daran, daß dein Steinzeit-Rechner zu schwacbbrüstig für dieses wunderbare Stück Software ist. Oliver
Falk B. schrieb: > Andere Programme brauchen nicht mal ansatzweise die gleiche > Zeit und leisten das Gleiche oder mehr! Da wir uns hier über das AVR-Studio unterhalten kannst Du sicher die Vorteile von 4.19 oder 4.18 gegenüber z. B. 7.0 (außer der Geschwindigkeit) aufzählen. Das interessiert mich doch sehr.
@Dieter F. (jim_quakenbush) >Da wir uns hier über das AVR-Studio unterhalten kannst Du sicher die >Vorteile von 4.19 oder 4.18 gegenüber z. B. 7.0 (außer der >Geschwindigkeit) aufzählen. Das interessiert mich doch sehr. Beide Softwarepakete funktionieren, wenn gleich das alte deutlich flüssiger. Funktional habe ich auch mit 4.18 keine Defizite im Rahmen meiner Nutzung. Der Simulator funktioniert mit dem, jaja, alten avr gcc von 2010. Ich mach damit nicht jeden Tag professionelle Softwareentwicklung sondern nur alle paar Monate mal bissel Hobby und im gleichen Zeitraster ab und an ein paar kleine Testschaltungen in der Firma. Ich will die Funktionalität und Verbesserungen des neuen Atmelstudios nicht schlechtreden, aber wenn die Kiste damit wie zähflüsser Honig läuft, fällt es schwer, die guten Seiten zu sehen und angenehem zu nutzen.
Falk B. schrieb: > Ich will die Funktionalität und Verbesserungen des neuen Atmelstudios > nicht schlechtreden, aber wenn die Kiste damit wie zähflüsser Honig > läuft, fällt es schwer, die guten Seiten zu sehen und angenehem zu > nutzen. Verständlich - mal schauen, wie es nach einem Hardware-Upgrade aussieht :-)
Dieter F. schrieb: > Oliver S. schrieb: >> Das passt alles widerspruchslos zusammen. Von nix kommt halt nix. > > Ja, mit einem Holzvergaser-Auto brauche ich einige Zeit, um von a nach b > zu kommen :-). In Relation zu einem Pferde-Fuhrwerk bin ich natürlich > sagenhaft schnell ... > > Ich kann mit einem Handbohrer genau so gute Löcher bohren, wie mit einer > Hand-Bohrmaschine ... > > Hinkt alles, ich weiss - so wie ich lieber auf eine mechanische Uhr > schaue und andere auf ihr Smartphone :-). So what ... Es hinkt nicht nur, sondern ist irgendwie ganz verkehrt herum. Hier geht es doch gerade darum, dass die neue Software ohne wirklichen Grund viel langsamer ist als die alte - also so, als ob dein Pferde-Fuhrwerk jedes aktuelle Auto locker überholt.
Rolf M. schrieb: > ohne wirklichen Grund viel Hast Du mal die Fähigkeiten / Möglichkeiten verglichen? Aber - jeder nach seiner Fasson :-)
@ Dieter F. (jim_quakenbush) >> ohne wirklichen Grund viel >Hast Du mal die Fähigkeiten / Möglichkeiten verglichen? Ja? Welche "Möglichkeiten" bietet denn das Programm beim Start und Projekt laden, ebenso bei den Optionen? >Aber - jeder nach seiner Fasson :-) Nö, denn das wäre hier mal wieder ein klarer Fall von mangelnder Kritikkompetenz. Mängel muss man Mängel nennen!
Johann L. schrieb: > Rolf M. schrieb: >> [...] 20 Milliarden Taktzyklen. Ein C64 war meistens gar nicht so >> lange am Stück eingeschaltet, dass er dabei so viele Taktzyklen >> zusammen bekäme. > > Bei 1MHz sind das 20000 Sekunden also gut 5 1/2 Stunden. Auch nicht > sooo exorbitat. Nicht exorbitant, aber ich durfte früher den Computer keine 5 Stunden pro Tag benutzen.
Falk B. schrieb: > Mängel muss man Mängel nennen! Natürlich sind das Atmel Studio, das dahinter steckende Visual Studio, das darunterliegende Windows, und auch die allermeisten andere MS-Produkte unperfekt und unnötig aufgeblasen. Manche nutzen es trotzdem einfach so, andere plärren. Microsoft denkt sich, wie bei allen Produkten: So what. Oliver
:
Bearbeitet durch User
Falk B. schrieb: > Welche "Möglichkeiten" bietet denn das Programm beim Start und Projekt > laden Vermutlich laden sie beim Start sämtliche herumlungernde XML-Dateien, die die Bauteile beschreiben. Da wird dann jedesmal ein XML-Parser dafür angeworfen. Auf diese Weise werden intern die Listen mit den verfügbaren Elementen aufgebaut, die dir dann für ein Projekt angezeigt werden. Erstens hatte das 4er AVR Studio eine anfangs sehr, sehr eigenwillige Variante von XML und dementsprechend sehr sicher einen „irgendwie selbst gefeilten“ Parser dafür, während man nun einen generischen XML-Parser benutzt. Die Dinger sind naturgemäß nicht so ganz leichtgewichtig. Zweitens sind mit all den ARMs nun ein Vielfaches an Devices dabei, die auf diese Weise analysiert werden müssen. Ich glaube mich zu erinnern, dass das 4er Studio zusätzlich noch da irgendeinen Cache dafür hatte. Der macht das einerseits natürlich schneller, andererseits musste man den nach irgendwelchen Änderungen an den XML-Dateien manuell zum Neubauen anwerfen. Ich wette, wenn du einen Großteil des Device Supports einfach mal per Dateimanager entfernst, dann startet auch der VisualAffenzirkus eine ganze Ecke schneller. Wie war das beim Studio 4 mit irgendwelchen automatischen Erweiterungen während der Eingabe? Manche Leute schwören auf sowas, und gerade für einen Anfänger ist es oft hilfreich. (Bei AVR brauche ich das nicht, bei Qt nehme ich aber eigens dafür schon mal den Qt Designer statt meines Emacs. ;-)
@ Jörg Wunsch (dl8dtl) (Moderator) >> Welche "Möglichkeiten" bietet denn das Programm beim Start und Projekt >> laden >Vermutlich laden sie beim Start sämtliche herumlungernde XML-Dateien, >die die Bauteile beschreiben. Da wird dann jedesmal ein XML-Parser >dafür angeworfen. Auf diese Weise werden intern die Listen mit den >verfügbaren Elementen aufgebaut, die dir dann für ein Projekt >angezeigt werden. Kann sein, das kann man aber auch intelligenter handhaben, sodaß dieser Scan nur nötig ist, wenn neue Bauteile gefunden worden. >leichtgewichtig. Zweitens sind mit all den ARMs nun ein Vielfaches >an Devices dabei, die auf diese Weise analysiert werden müssen. Siehe oben! >Ich wette, wenn du einen Großteil des Device Supports einfach mal >per Dateimanager entfernst, dann startet auch der VisualAffenzirkus >eine ganze Ecke schneller. Werd ich mal probieren. >Wie war das beim Studio 4 mit irgendwelchen automatischen Erweiterungen >während der Eingabe? Manche Leute schwören auf sowas, und gerade für >einen Anfänger ist es oft hilfreich. Unbestritten. Das kann man aber besser machen, siehe andere Produkte. Das Code Composer Studio von TI basiert AFAIK auch auf Eclipse und ist DEUTLICH agiler! Auf der gleichen, alten Kiste!
:
Bearbeitet durch User
Falk B. schrieb: > Das Code Composer Studio von TI basiert AFAIK auch auf Eclipse und ist > DEUTLICH agiler! Gerade zu Eclipse lese ich jedoch auch häufig völlig gegenteilige Meinungen hier. Warum damals Atmel unbedingt den Visual-Krams nutzen musste, naja, da war wohl viel Politik dabei. Insbesondere Nicht-Windows-Nutzer von AVR hatten bis zuletzt ja auf Eclipse gehofft, das ja durchaus mal zur Auswahl stand (die eher linuxlastige AVR32-Truppe hatte es dafür schon eine Weile in Verwendung), und es gab auf avrfreaks einen ziemlichen Sturm der Entrüstung, als dann die Entscheidung zugunsten von VS veröffentlicht worden ist. Andere als Windows-Nutzer haben aber das Management zumindest bei Atmel in Trondheim wohl nie interessiert.
Angehängte Dateien:
-
Komfort1.png
5,3 KB -
Komfort_2.png
11 KB -
Debug_Einstieg.png
20 KB -
Debugging.png
5,9 KB
Falk B. schrieb: > Ja? Welche "Möglichkeiten" bietet denn das Programm beim Start und > Projekt laden, ebenso bei den Optionen? Beim Start kannst Du Dir die Nase schneuzen, wenn Du schnell bist (oder eine alte Gurke als Rechner hast). Bei den Optionen: Komfort - beim Editieren, beim Rechtsklick auf z.B. Sprung auf die Implementierung eines Includes einer Funktion ... Erweiterte Debug-Möglichkeiten usw. Aber es zwingt Dich ja niemand (und Du kennst die Möglichkeiten sicher auch). Falk B. schrieb: > Nö, denn das wäre hier mal wieder ein klarer Fall von mangelnder > Kritikkompetenz. Da stimmern wir überein.
Jörg W. schrieb: > Erstens hatte das 4er AVR Studio eine anfangs sehr, sehr eigenwillige > Variante von XML und dementsprechend sehr sicher einen „irgendwie > selbst gefeilten“ Parser dafür, während man nun einen generischen > XML-Parser benutzt. Die Dinger sind naturgemäß nicht so ganz > leichtgewichtig. Zweitens sind mit all den ARMs nun ein Vielfaches > an Devices dabei, die auf diese Weise analysiert werden müssen. Warum muss er denn beim Laden eines einzelnen Projekts sämtliche Device-Beschreibungen parsen? > Ich glaube mich zu erinnern, dass das 4er Studio zusätzlich noch > da irgendeinen Cache dafür hatte. Der macht das einerseits natürlich > schneller, andererseits musste man den nach irgendwelchen Änderungen > an den XML-Dateien manuell zum Neubauen anwerfen. Wobei es ja auch kein unlösbares Problem wäre, das zu automatisieren. make kriegt das ja auch ganz simpel hin durch Vergleich des letzten Speicherdatums der Eingangs- und der Ausgangsdatei. > Wie war das beim Studio 4 mit irgendwelchen automatischen Erweiterungen > während der Eingabe? Manche Leute schwören auf sowas, und gerade für > einen Anfänger ist es oft hilfreich. (Bei AVR brauche ich das nicht, > bei Qt nehme ich aber eigens dafür schon mal den Qt Designer statt > meines Emacs. ;-) Weichei. :-) Ich nehm für beides vim.
Hallo, habe mal bei mir von Hand gestoppt, weil ich mit AS7 nicht klagen kann. Vom Icon Doppelclick bis AS7 gestartet ist ca. 11s danach zügig auf das letzte Projekt geklickt, bei ca. 17s war es fertig geladen. i7-2500 16GB SSD Win10
:
Bearbeitet durch User
Rolf M. schrieb: > Warum muss er denn beim Laden eines einzelnen Projekts /sämtliche/ > Device-Beschreibungen parsen? Vermutlich sogar noch mehr: sämtliche "Tools", also Devboards etc. Sorry, das bezog sich aber nicht auf ein Projekt, sondern auf den Programmstart (habe ich mit falschem Bezug gepostet). Nachdem man das gestartet hat, bekommt man ja alles zur Auswahl angeboten, mit dem man nun ein Projekt aufsetzen könnte. Ich will das ja keineswegs verteidigen, das ist einfach nur meine Vermutung, dass der Salat deswegen so lange braucht. Für den Projektstart habe ich allerdings auch keine rechte Idee. Aufbau eines Syntaxbaums gehört sicher mit dazu (fürs Highlighting und für die erwähnte Code Completion). OK, das würde natürlich ein wenig erklären, warum es bei mir selbst bei vergleichsweise kleinen Projekten eweig dauert: ich habe das Dingens ja jeweils nur benutzt, um irgendwie mal Antworten auf die Frage zu bekommen: „Wie würde ASF das jetzt anfangen?“ Wer in ASF schon mal reingesehen hat, weiß, welcher unsägliche Wust von Code das ist … daran kann man bestimmt eine Weile herum parsen. > Weichei. :-) > Ich nehm für beides vim. Wenn ich in Qt häufiger arbeiten würde, dann würde ich es sicher auch im Emacs editieren.
@Jörg Wunsch (dl8dtl) (Moderator) >Andere als Windows-Nutzer haben aber das Management zumindest bei >Atmel in Trondheim wohl nie interessiert. Da fehlte wohl der skandinavische Patriotismus und der heiße Draht zum Linus T. ;-)
Veit D. schrieb: > Vom Icon Doppelclick bis AS7 gestartet ist ca. 11s danach zügig auf das > letzte Projekt geklickt, bei ca. 17s war es fertig geladen. 12s / 18s AMD FX6300-3500 8 GB RAM SSD Win 10
Beitrag #5286321 wurde von einem Moderator gelöscht.
c-hater schrieb im Beitrag #5286321: > Die wenigen neueren Teile werden vom Studio 4.1x natürlich tatsächlich > nicht direkt unterstützt, Ok, halten wir fest: Der aktuelle Teil der Produktpalette wird zum Großteil nicht unterstützt.
:
Wiederhergestellt durch Moderator
Wenns interessiert: Ich verfolge Eure Diskussion mit Interesse und habe selber ähnliche Erfahrungen gemacht. Die IDEs die für mich am schnellsten und reagierend (responsive) waren, sind: Keil uV2 V7 (Sehr Schnell und intuitiv) Keil uV4 V9(Silabs Version) sehr schnell IAR (Firma) (sehr schnell und intuitiv) ICCV7/8 (Sehr schnell) Rowley Crossworks - Ziemlich schnell Zilog ZDS II - Sehr schnell und intuitiv Codevision AVR V2 - früher sehr schnell, V3 - so, so ( Wenn sourcen auf USB memory stick sind, gibts Verzögerungen die auf der Festplatte nicht vorkommen) Arduino IDE - Etwas langsam beim Start, sonst ziemlich schnell Atollic TS und Coocox sind bei mir auch einigermaßen schnell. Atmel Studio V7 und MPLABX sind in meiner Umwelt mit Abstand die langsamsten. Auch mit i7 und X64/32Gb Ich hätte da eine Frage: Ab und zu kommt es vor, daß ich nur einen Bootloader via SPI auf einen AVR flashen möchte. Dazu nehme ich immer AVR-Studio 4.19. Geht ruck-zuck. Wenn ich dasselbe mit AS 7 machen möchte, komme ich einfach nicht zurecht. Da ich immer so frustriert mit AS bin, daß ich mir noch nie die Zeit genommen hatte damit wirklich klar zu kommen, möchte ich gerne wissen ob es damit auch so leicht möglich ist und ich nur zu uninformiert mangels Praxis bin. Beim AVR-Studio geht es ja ohne Projekterstellung. Bei AS komme ich ums Verecken nicht damit klar. Es macht einfach keinen Spass mit AS zu arbeiten weil es in fast allem so furchtbar langsam reagiert. Und es will immer komplette Projekte erstellen. Kann man das AS abgewöhnen und nur das machen was man von ihm will? Arbeiten mit AS fühlt sich an wie Tauziehen bzw. Ringen.
:
Bearbeitet durch User
Hallo, ich verstehe "euer" Problem echt nicht. Es mag sein das AS7 etwas länger benötigt zum starten. Na und? Wem stört das? Hauptsache ist doch das sie danach flüssig läuft. Und das tut sie. Habe gerade die Arduino IDE und AS7 direkt hintereinander gestartet, waren beide zeitgleich fertig geladen. Wegen deinem direkten flashen. AS7 starten > Extras > Device Programmierung. Ob es dafür Sinn macht AS7 zu starten steht auf einem anderen Blatt. Die gesamte Diskussion könnt ihr einfach sein lassen. Wer AS7 mag soll es nehmen. Wer ältere Versionen mag soll diese nehmen. Niemand zwingt irgendeinen eine bestimmten Version einzusetzen. Dabei sollten wir es belassen. Wer irgendwelche Files benötigt für fehlende µC, dem helf ich gern aus.
Veit D. schrieb: > Wegen deinem direkten flashen. AS7 starten > Extras > Device > Programmierung. > Ob es dafür Sinn macht AS7 zu starten steht auf einem anderen Blatt. Danke für Deinen Hinweis. Also geht's immer noch ziemlich direkt - Das wollte ich brennend wissen. Für neuere uC kommt man vielleicht möglicherweise nicht darum herum. Gruß, Gerhard
Gerhard O. schrieb: > Veit D. schrieb: >> Ob es dafür Sinn macht AS7 zu starten steht auf einem anderen Blatt. > > Danke für Deinen Hinweis. Also geht's immer noch ziemlich direkt Wenn es wirklich nur darum geht, einen Bootloader (oder ein anderes, beliebiges Binary) zu flashen, dann geht das doch schneller und einfacher per Commandline, z.B. mit avrdude? Ohne ewig zu warten und Rumzumausen. avrdude beschreibt Devices in einer .conf-Datei, und wenn ein Device dort fehlt, kann man hinzufügen. .conf ist eine reine Textdatei, und die nötigen Parameter wie Device-ID sind dem Datenblatt entnehmbar.
Gerhard O. schrieb: > Für neuere uC kommt man vielleicht möglicherweise nicht darum herum. Doch. Erstens gibt es natürlich (Vorsicht, Eigenwerbung! :) immer noch AVRDUDE, zweitens liefert auch Atmel, ähem, Microsoft seit geraumer Zeit ein Kommandozeilentool mit (atprogramm.exe, wenn ich mich recht entsinne). Du musst dann zwar den Studio-Kram immer noch installieren, aber nicht das fette Studio selbst benutzen.
Johann L. schrieb: > c-hater schrieb im Beitrag #5286321: >> Die wenigen neueren Teile werden vom Studio 4.1x natürlich tatsächlich >> nicht direkt unterstützt, > > Ok, halten wir fest: Der aktuelle Teil der Produktpalette wird zum > Großteil nicht unterstützt. Nein, das ist falsch. Es gibt keinen "aktuellen Teil" einer Produktpalette. Es gibt nur eine aktuelle Produktpalette. Und davon unterstützt halt das Studio 4.1x schon von Hause aus den größten Teil in jeder Hinsicht. Etliche weitere Teile lassen sich sehr leicht insofern nachrüsten, als dass für sie programmieren und sie auch via Programmer beschreiben kann. Sprich: für diese Teile fehlt nur Simulation und OC-Debugging. Und der (sehr überschaubar kleine) Rest läßt sich zumindest insofern nachrüsten, als dass man für sie programmieren kann. Hier fehlt also zusätzlich zu Simulation/OC-Debugging noch die Möglichkeit, sie direkt aus der IDE zu beschreiben, was sich allerdings mittels Einbindung externer Tools in die IDE dann doch wieder umgehen läßt. Der eigentliche Knackpunkt sind also nur die fehlenden Möglichkeiten für Simulation/OC-Debugging. In den meisten Fällen ist das aber keine nennenswerte Einschränkung, weil die Teile der Peripheriehardware, die bei den neuesten Teilen wirklich neu sind, im Simulator auch des Studio7 nicht oder nicht vernünftig unterstützt werden. Sprich: man kann die Simulation auch einfach mit einem anderen Target durchspielen, soweit sie eben nicht die wirklich neue Peripherie betrifft. Nunja, und das OC-Debugging braucht man sowieso nur in sehr seltenen Ausnahmefällen wirklich. Und wenn, dann nur um einen Ansatzpunkt zu gewinnen, um die Sache in der Simulation auf ihre eigentliche Ursache zurück verfolgen zu können. Da geht das nämlich (im Gegensatz zum OC-Debugging) wegen der beliebigen Reproduzierbarkeit der Ausgangssituation. Das mit der Gewinnung des Ansatzpunktes kann man allerdings auch leicht mittels klassischem "LED-Debugging" realisieren, so dass OC-Debugging allenfalls als ein "nice to have"-Feature erscheint, nicht aber als dringende Notwendigkeit.
Johann L. schrieb: > avrdude beschreibt Devices in einer .conf-Datei, und wenn ein Device > dort fehlt, kann man es hinzufügen. ...oder eine eigene .conf angeben.
c-hater schrieb: > Und der (sehr überschaubar kleine) Rest Gerade nachgesehen: alle ATxmega*U sind nicht dabei, Xmega B und C fehlen ebenfalls. Die neuesten AVR8X-Devices sind ohnehin nicht da. Bei den Programmierwerkzeugen ist beim JTAGICEmkII Schluss, also neben dem JTAGICE3 und (sehr viel preiswerteren, auch als das JTAGICEmkII) Atmel-ICE hast du insbesondere die eingebauten Programmierer/Debugger der diversen XplainedPro- und XplaineMini-Boards nicht dabei. Gerade die XplaineMini sind recht preiswert. > läßt sich zumindest insofern > nachrüsten, als dass man für sie programmieren kann. Dann stellt sich allerdings die Frage nach dem Sinn der IDE als Ganzes, denn dann bist du bei weiter nichts mehr als einem Editor, bei dem man sich vielleicht noch die Funktionstasten belegen kann (fürs compilieren und Flashen). Da brauchst du auch kein *Studio mehr. Bezüglich neuerer Compiler hatte ich mich ja oben schon ausgelassen: der eingebaute DWARF-Parser ist so „handgestrickt“, dass er sich am DWARF-Output neuerer GCC-Versionen erbricht, da dieser zwar den Regeln von DWARF entspricht (und damit von jedem, der sich an die DWARF-Spec hält, auch geparst werden kann), aber da der DWARF-Parser im Studio 4 eben sehr „ad hoc“ nach dem gerade damals produzierten Format gezimmert worden ist, hat er dann mit einem neueren Compiler ein Problem.
:
Bearbeitet durch Moderator
c-hater schrieb: > Johann L. schrieb: > Der eigentliche Knackpunkt sind also nur die fehlenden Möglichkeiten für > Simulation/OC-Debugging. In den meisten Fällen ist das aber keine > nennenswerte Einschränkung, weil die Teile der Peripheriehardware, die > bei den neuesten Teilen wirklich neu sind, im Simulator auch des Studio7 > nicht oder nicht vernünftig unterstützt werden. Sprich: man kann die > Simulation auch einfach mit einem anderen Target durchspielen, soweit > sie eben nicht die wirklich neue Peripherie betrifft. Wenn das komplexeste Projekt das man angeht ein Taschenrechner ist, ja. Wenn man mit CAN, Ethernet, Wlan, SENT, Flexray, DMA, ADC oder generell irgendwelchen Peripheriegeräten arbeitet wirds schnell dünn mit nem Simulierten Atmega8. Abgesehen davon fehlt die komplette ARM Plalette und auch teile der 32Bit-Geräte. > > Nunja, und das OC-Debugging braucht man sowieso nur in sehr seltenen > Ausnahmefällen wirklich. Na dann mache wohl ich und jeder Andere in der Firma irgendwas falsch.. > Und wenn, dann nur um einen Ansatzpunkt zu > gewinnen, um die Sache in der Simulation auf ihre eigentliche Ursache > zurück verfolgen zu können. Da geht das nämlich (im Gegensatz zum > OC-Debugging) wegen der beliebigen Reproduzierbarkeit der > Ausgangssituation. Na das will ich sehen wie man einen CAN-Bus-heavy und Bitfehler im Simulator nachstellt. > Das mit der Gewinnung des Ansatzpunktes kann man > allerdings auch leicht mittels klassischem "LED-Debugging" realisieren, > so dass OC-Debugging allenfalls als ein "nice to have"-Feature > erscheint, nicht aber als dringende Notwendigkeit. Klar. "Wenn irgendwo in den 15.000 Zeilen Code was nicht stimmt, leucht das da rot..."
Jörg W. schrieb: > > Gerade nachgesehen: alle ATxmega*U sind nicht dabei, Xmega B und C > fehlen ebenfalls. Sind alle in Atmel Studio 7 enthalten. > Die neuesten AVR8X-Devices sind ohnehin nicht da. Meinst du damit die ATtinys? Sind auch in AS7 enthalten. Jetzt mal ernsthaft. Ich kann mich nicht darüber aufregen wenn in einer alten Version diverse Typen fehlen, wenn es schon längst neue Programmversionen gibt. Allerdings könnte es Updates geben. Schon einmal nachgeschaut?
Veit D. schrieb: > Sind alle in Atmel Studio 7 enthalten. Es ging um AVR Studio 4.x. Dass MicroAtmel sie in der aktuellen Version pflegt, hat ganz sicher keiner hier in Frage gestellt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.