AtmelStudio 7 ist so nervig... dauert ewig beim Starten, die Oberfläche ist unübersichtlich, das Syntaxhighlighting grauenhaft... da die vorherigen Versionen auch alle ihre Macken hatten, will ich nicht unbedingt auf AVR Studio 4 zurück. Kann jemand eine schnelle und schlanke IDE empfehlen, mit Code für AVRs in ASM und C geschrieben werden kann, inklusive Einbindung von Compiler und Programmer? Kann CodeBlocks das, oder ist das auch nur aufgebläht? Btw: Nein, Eclipse ist nicht das, was ich unter schnell und schlank verstehe... ;-)
Wenn du schnell und schlank willst, wozu dann eine IDE? Das bißchen Code für einen Controller geht doch mit Editor, make und Kommandozeile wunderbar. Zumal wenn man einen Editor nimmt, den man sich schön zurechtbiegt bei Bedarf (natürlich den EMACS :-).
Klaus W. schrieb: > Wenn du schnell und schlank willst, wozu dann eine IDE? Für große Projekte eignen sich natürlich integrierte Entwicklungsumgebungen besser, als simple Text-Editoren. Wenn das nicht der Fall ist dann nimmt einfach z.B. WinAVR oder nur ein Texteditor wie Programmers Notepad (wie bei WinAVR), Netbeans ist auch ok.
Ich nutze AVR Studio 4.18 mit dem letzten offiziellen WIN AVR von 2010. Das läuft schnell und stabil. Für neuere Sachen incl. ATXmega nutze ich Atmelstudio 6.2 Ja, das ist eine mittlere Katastrophe, lahmarschig wie Sau! Aber was solls, man startet es nicht 10x am Tag, die wesentlichen Abläufe sind erträglich. Hier kann man auch das neue ATMEL-ICE nutzen, sehr nett zum Debuggen!
Nimm doch einfach den Editor deines geringsten Mißtrauens. Makefiles erstellt dir MFile, und mehr braucht man doch gar nicht. Wenn du den Simulator benötigst, geht es nicht ohne Atmel Studio. Oliver
:
Bearbeitet durch User
Ich empfehle Kate. Es ist zwar ein Editor, aber mit dem build und gdb plugin steht es einer IDE eigentlich in nichts nach. Einzig das makefile muss man selbst schreiben, und das werte ich eher als Vorteil. Es startet echt schnell (1 bis 2 Sekunden unter Linux, unter windows habe ich's nicht ausprobiert, welches OS hast du eigentlich?)
Peter H. schrieb: > Hallo > > Schau Dir mal PSPad an. > > Gruß Peter Wie erfüllt der die Anforderungen des TO? Mal ehrlich, jetzt kommen gleich wieder *zig Leute mit "Schau dir mal Notepad++ an." "Schau dir mal Vim an." "Schau dir mal Geany an." "Schau dir mal jEdit an." "..." für jeden Eintrag in [1]. Eine Begründung wäre da schon angemessen. Zum Thema Code:Blocks habe ich (circa 2 Jahre her) als sehr schlank in Erinnerung. Eclipse finde ich persönlich jetzt auch nicht so unerträglich. Gruß Dennis [1] https://de.wikipedia.org/wiki/Liste_von_Texteditoren
Falk B. schrieb: > Ich nutze AVR Studio 4.18 mit dem letzten offiziellen WIN AVR von 2010. > Das läuft schnell und stabil. Naja, wenn du einen neueren Compiler reinhängen willst, ist es schnell Schluss mit lustig-stabil. Deren an allen Standards vorbei gehackter DWARF-Parser kackt dann sofort ab, und du musst den Compiler darauf drängen, DWARF-Infos zu erzeugen, die keine seiner neueren Erweiterungen enthalten. Der alte Compiler wiederum hat so viele (teils recht üble) Bugs, dass man ihn schon deshalb in Frage stellen sollte, auch optimierungsmäßig sind die neueren teils um Welten besser, seit Johann da Hand angelegt hatte – von sowas wie __flash ganz zu schweigen. Dennis S. schrieb: > Eine Begründung wäre da schon angemessen. Viele heutige Texteditoren bieten einfach das nötige Framework dafür von vornherein mit an. Der Vorteil gegenüber spezialisierten IDEs ist, dass sie völlig unabhängig vom Zielsystem arbeiten, der Nachteil ist, dass man sich die middleware für jedes Zielsystem selbst zusammenstellen muss. Ich benutze jedenfalls auch seit Jahren Emacs für sowas, und dessen aktuelle GDB-Integration unterscheidet sich nicht von anderen IDEs. Aber ich würde niemandem einen Emacs aufdrängen wollen. ;-)
Jörg W. schrieb: > Viele heutige Texteditoren bieten einfach das nötige Framework dafür > von vornherein mit an. Der Vorteil gegenüber spezialisierten IDEs > ist, dass sie völlig unabhängig vom Zielsystem arbeiten, der Nachteil > ist, dass man sich die middleware für jedes Zielsystem selbst > zusammenstellen muss. Ich weiß das... die Frage ist: was macht PSPad besser als die 30 anderen Editoren die für die Aufgabe geeignet sind? Ich wollte lediglich darauf hinweisen, dass dieses "Worddropping" völlig sinnlos ist und nur die ganzen "Fanboys" anzieht. Gruß Dennis P.S.: vim ist perfekt für alles. :-D
:
Bearbeitet durch User
Dennis S. schrieb: > vim ist perfekt für alles Genau wie Emacs. Aber keiner ist besser als der andere. :-))
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >> Ich nutze AVR Studio 4.18 mit dem letzten offiziellen WIN AVR von 2010. >> Das läuft schnell und stabil. >Naja, wenn du einen neueren Compiler reinhängen willst, ist es >schnell Schluss mit lustig-stabil. Will ich das? Nein! > Deren an allen Standards vorbei >gehackter DWARF-Parser kackt dann sofort ab, und du musst den >Compiler darauf drängen, DWARF-Infos zu erzeugen, die keine seiner >neueren Erweiterungen enthalten. Der alte Compiler wiederum hat so >viele (teils recht üble) Bugs, dass man ihn schon deshalb in Frage >stellen sollte, Welche denn? Bisher war ich mit dem Ding sehr zufrieden. > auch optimierungsmäßig sind die neueren teils um >Welten besser, Welten? Oder eher gefühlt Welten? Die .lss Listings sehen ganz gut aus, wenn ich sie dann ab und an mal anschaue. > seit Johann da Hand angelegt hatte – von sowas wie >__flash ganz zu schweigen. Nett, aber nur verzichtbarer Luxus. Ich nutze das nicht als Produktivsystem um meine Brötchen zu verdienen, der allermeiste Kram ist Hobby. Und wenn es WIRKLICH man der neue Compiler sein soll, dann halt die lahme Ente Atmelstudio 8-0
Falk B. schrieb: >>Der alte Compiler wiederum hat so >>viele (teils recht üble) Bugs, dass man ihn schon deshalb in Frage >>stellen sollte, > > Welche denn? Bisher war ich mit dem Ding sehr zufrieden. Beispielsweise diesen hier: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 Der ist zwar mit GCC 4.4 häufiger zutage getreten als noch im 4.3, aber soweit ich Johann verstanden habe, war er schon immer im Compilercode drin.
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 >Der ist zwar mit GCC 4.4 häufiger zutage getreten als noch im 4.3, Somit bin ich auf der "sicheren" Seite ;-) >aber soweit ich Johann verstanden habe, war er schon immer im >Compilercode drin. Hmm, zeig mir den Compiler der bugfrei ist ;-) Im Prinzip hast du Recht, die Gefahr ist aber eher gering und ich bleib beim 2010er avr gcc.
Ich werfe mal QtCreator in den Raum. Es ist schlank, schnell, bietet wunderbares CodeCompletion, verträgt sich mit make cmake qmake, hat gdb Integration (hab ich mit AVR allerings noch nicht ausprobiert), hat ein dark Theme und läuft auf Windows, Linux, Mac. Kommt dem VS Feeling am nächsten.
Also Argumente... Ich mag Kate. Er ist schnell und schlank, hat eine Konsole eingebaut, Syntax-Highlight und ist quasi standardmäßig installiert in einer KDE-Umgebung. Fertig. Im Prinzip lebt Kate von der wirklich guten Kedit-Komponente. Der Rest ergibt sich drumrum...
Angehängte Dateien:
-
QtCreatorARM.png
240 KB
Anbei noch ein Screenshot von QtCreator und einem ARM Cortex Projekt (make).
Dennis S. schrieb: > Zum Thema Code:Blocks habe ich (circa 2 Jahre her) als sehr schlank in > Erinnerung. Eclipse finde ich persönlich jetzt auch nicht so > unerträglich. Code::Blocks hab ich immer für C/C++ verwendet. Das ist durchwegs brauchbar! Inweiweit das jetzt mit den AVRs direkt zusammen arbeitet, kann ich allerdings nicht sagen ... Ich hab es jetzt nur aufgrund der light-weight emfpohlen^^
Mampf F. schrieb: > Inweiweit das jetzt mit den AVRs direkt zusammen arbeitet, kann ich > allerdings nicht sagen Also irgendwie muß es gehen, ich bin aber auch erstmal an der Einbindung der Compiler gescheitert. Muß ich mir nochmal in Ruhe anschauen. Wird eigentlich zum Programmieren mit dem ISP-MKII aus Code::Blocks heraus der Jungo-Treiber genutzt? Meine Versuche mit LunaAVR endeten immer dahingehend, daß sich die Treiber dann gegenseitig behackt haben und der Jungo-Treiber im AVR Studio nicht mehr funktionierte.
Klaus W. schrieb: > Wenn du schnell und schlank willst, wozu dann eine IDE? > Das bißchen Code für einen Controller geht doch mit Editor, make und > Kommandozeile wunderbar. Ich bin zwar nicht der TE. Aber was mir an einem Editor fehlt, ist der Debugger. Mit der Möglichkeit, Peripherie-Register (TWI, ADC, GPIO, ...) anzuzeigen und zu manipulieren. Und Fuses. Mit den einzelnen Bits und Bit-Feldern schön lesbar aufgeschlüsselt. Gibt es da auch was schlankes (Standalone Debugger GUI?), mit vergleichbarem Comfort wie AVRStudio 4?
Hallo Timm Thale, man kann über die LunaAVR Ide auch direkt in Assembler programmieren und auch die Projekt eigenen Bibliotheken/ Module nutzen. Ein .import <name> reicht dann aus.
Jörg W. schrieb: > Sebastian schrieb: >> Und Fuses. > > Im Debugger? > > Nö. Entschuldigung. Bei dem Teil war "In der IDE" gemeint. Bin ich mit meinem Beitrag eigentlich Off-Topic, oder interessiert das sonst noch jemand? Zumindest "Programmer" war ja in der ursprünglichen Frage erwähnt: > inklusive Einbindung von Compiler und Programmer Und ich finds halt schon sehr bequem, wenn ich zum Test der Platine an den GPIO pins rumspielen kann, ohne extra was dafür programmieren zu müssen.
sebastian schrieb: > Und ich finds halt schon sehr bequem, wenn ich zum Test der Platine an > den GPIO pins rumspielen kann, ohne extra was dafür programmieren zu > müssen. Ja, im Prinzip können online-Debugger das, habe ich auch zuweilen schon direkt auf der GDB-Ebene benutzt, aber oft braucht man das dann doch nicht.
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.