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