Hallo, scheinbar hat sich Atmel doch noch entschlossen, für die 4er Version eine C-Unterstützung herauszubringen. http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=9772 Hat schon jemand Erfahrungen damit? Kann man jetzt WinAVR beiseite legen und nur noch AVR Studio benutzen?
Umm, Deine Erklärung paßt nicht so recht zur Software. ;-) Das ist keine Möglichkeit, einen C-Compiler aus der Oberfläche von AVR Studio (im Sinne einer ,,IDE'') einzubinden. Stattdessen ist das der lange versprochene ELF Parser für AVR Studio (genauer: eine Beta-Version davon), zusammen mit den nötigen GCC-Tools, die dieses Format erzeugen können. GCC arbeitet zwar seit vielen Jahren mit ELF als Objektformat, aber AVR-GCC arbeitet bisher mit dem sogenannten stabs Format für die Debug-Informationen (das in Abschnitten in der ELF-Datei untergebracht wird). Atmel liefert daher einen GCC mit, der so konfiguriert ist, daß er das ELF-Format mit den von Atmel gewünschten DWARF2 Debug-Informationen unterstützt. Das ist keineswegs als ,,Konkurrenz'' zum WinAVR-Paket gedacht, sondern nur als Übergangslösung, bis WinAVR selbst in der Lage sein wird, ELF + DWARF2 zu produzieren. (Sehr wahrscheinlich wird bereits die nächste Version von WinAVR das können.) Der ELF-Parser für AVR Studio wiederum wird irgendwann in der regulären Distribution von AVR Studio enthalten sein. In diesem Moment ist dann diese ,,GCC Tools'' Sammlung überflüssig.
Ich habe mir die GCC Tools noch nicht angesehen, nur einen Hinweis darüber gelesen. Schade. Ich dachte schon, in der 4er würde nun endlich die Unterstützung eines C-Compilers (wie in der 3er) eingebaut werden. Dann könnte man WinAVR schön aus der IDE vom AVR Studio starten/bedienen/... Nicht, dass ich WinAVR nicht haben will (übrigens Super-Arbeit), aber ich mag den PN überhaupt nicht. Und ausserdem bietet das AVR Studio für mich die eindeutig besseren Möglichkeiten des Debuggens (Sicher, das geht mit gdb auch.). Naja, wie gesagt, schade...
Du bist ja nicht an den PN gebunden, hast ja die Qual der Wal :-) emacs, eclipse, vim, UltraEdit, scite, etc, pp...
Winusers sind wohl die Auswahl ihrer Editoren einfach nicht gewöhnt. ;-)
Der Editor als solches ist kein Problem. Da gibt es ja (auch für Windoof) eine ganze Menge. War ja auch nur ein Bespiel. Viel wichtiger finde ich eben einen leicht zu bedienenden Debugger. Und sagt jetzt nicht, dass das der gdb ist. Wenn ich mehr Aufwand in das Erlernen des Werkzeuges investieren muss als in die eigentliche Umsetzung der Aufgabe, dann ist das meines Erachtens nicht mehr Stand der Technik. Und letzlich finde ich es eben einfach auch bequem, wenn alles irgendwie in einem Werkzeug (unter einer Oberfläche) vereint ist. Ich bin eben ein bisschen von den RAD-Tools unter Windoof verwöhnt... ;o)
Hallo Joline, ich kenne den GDB nur zu gut. Für den gibt es genug GUI's, die selbst unter Windows laufen - notfalls den Cygwin oder Mingw zum kompilieren nehmen. An den gdb kommt aber IMHO niemand, der wirklich ordentlich und plattformübergreifend debuggen will vorbei. bisher habe ich noch keine Plattform gefunden, auf der der nicht lief! Gruß Marcus
Mit ,,leicht zu bedienen'' und ,,Stand der Technik'' ist das alles so eine relative Sache... Wenn man den GDB einmal gelernt hat, lernt man ihn eben wirklich nur ein einziges Mal -- egal, ob ich damit den Kernel meines FreeBSD debuggen möchte, meinen AVR oder eine Applikation auf einer Sun. Das einmal erworbene Wissen kann man dann immer wieder verwenden. Ich finde jedenfalls Debugger, bei denen man alles erklickern muß, eher schwerfällig zu bedienen, ganz zu schweigen von der Ausgabe eines beliebigen C-Ausdrucks (inklusiver aller derzeit aktiver Variablen meiner Applikation), verglich mit dem umständlichen Hinzufügen zu einem `watch window' oder sowas. Wie geschrieben: ist eben alles sehr relativ... Ich konnte mich bislang jedenfalls nicht von einem anderen Frontend zu GDB als dem Emacs überzeugen lassen, und selbst VMLAB (desse IO Simulation ich wirklich in den höchsten Tönen preisen kann) finde ich auf der Debuggerseite halt eher mager: keine beliebigen C-Ausdrücke, Variablen nur im aktuellen Stackframe, naja, von Dingen wie dem rekursiven Aufdröseln einer verketteten Liste schweigen wir besser gleich ganz.
Jaja, ich glaube euch ja gerne, dass der gdb wirklich gut ist. Ich kenne eben nur die diversen Tools (MS Visual Studio, Delphi) und da kann man "alles erklickern". Sind mit der Zeit wirklich immer besser geworden. Gibt es denn ein empfehlenswertes Frontend für den gdb, dass auch unter Windoof läuft. Ich möchte z.B. den Quelltext anzeigen und dann auf eine bestimmte Zeile einen Breakpoint setzen. Dann möchte ich, wenn der Prozess an dieser Stelle angekommen ist, verschiedene Variablen anschauen (evtl. auch deren Inhalt ändern). Das ganze natürlich eben immer mit Blick auf den Quelltext, der in dem Frontend weiter angezeigt wird und nicht mit type (oder cat ;o) ) in der commandline. Gruß Joline
> Ich möchte z.B. den Quelltext anzeigen und dann auf eine bestimmte > Zeile einen Breakpoint setzen. Dann möchte ich, wenn der Prozess an > dieser Stelle angekommen ist, verschiedene Variablen anschauen > (evtl. auch deren Inhalt ändern). Das ganze natürlich eben immer > mit Blick auf den Quelltext, der in dem Frontend weiter angezeigt > wird und nicht mit type (oder cat ;o) ) in der commandline. Genau das tut der Emacs für mich. Ob der Emacs auch für Dich empfehlenswert ist, weiß ich nicht; das hängt davon ab, ob Du gewillt bist, Dir auch mal was jenseits des Gartenzauns anzugucken und Dich einzuarbeiten. In andere neuen Dinge (ein CAD-Programm z. B.) muß man sich ja auch einarbeiten, bevor man damit wirklich loslegen kann. Für mich ist der Emacs damit sowas wie eine IDE, die sich noch dazu seit über 10 Jahren zwar verbessert, aber nicht grundlegend geändert hat, außer daß ich sie jetzt grafisch unter X11 betreibe, während ich sie damals fast nur im Textmodus benutzen konnte -- mit gleichem Funktionsumfang übrigens (wobei ich zugegebenermaßen das meiste nicht über die Menüs sondern über die Tastenkürzel mache, weil es schneller geht und ich sie aus der nicht-Grafik-Zeit sowieso intus habe). Aber es gibt, wie schon geschrieben worden ist, wahrscheinlich ein halbes Dutzend Frontends für den GDB, die sich alle anders anfühlen, da jeder ihrer Entwickler andere Prämissen gesetzt hat.
Bitte 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.