www.mikrocontroller.net

Forum: Compiler & IDEs GDB(Insight) oder AVR-Studio als Debugger?


Autor: Wolfgang Seemann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe bisher nur sehr kleine MC-Projekte in C geschrieben, werde
mich aber nun im Rahmen meines Studiums auf ein Grösseres stürzen
müssen, weshalb ich nun eine IDE mit Souce-Level Debugger brauchte. Von
der Combi AVR-Studio 3 und GCC habe ich nun schon viel gelesen, aber
auch von positiven Erfahrungen mit dem GNU Debugger GDB.
Was würdet ihr mir empfehlen? Vor allem habe ich wiedersprüchliches zum
thema in-circuit-debugging Fähigkeiten von GCC und AVR-Studio in
verschiedenen Foren gelesen.
Also was würdet Ihr mir empfehlen?

Vielen Dank schonmal!
Wolfgang

Autor: R2D2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde den GDB nehmen, einfach aus den Grund, dass er platform
unabhängig ist und du z.B. beim Umstieg auf MSPs oder andere µCs dich
nicht in die Bedienung eines neuen Debuggers einarbeiten muss. Auch ist
die Komandozeile des GDB extrem leistungsfähig und du kannst vieles
schneller/einfacher machen. Allerdings brauchst du erst mal ein paar
Tage Übung bis du die ganzen Features beherscht.

R2D2

Autor: Wolfgang Seemann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm....
Insight kann aber nicht In-System Debuggen oder?

Was haltet Ihr von folgender combo:

WinAVR (kommende Version mit hoffendlich ELF) als Compiler, ansonsten
   eine gepatchte von AVRFreaks
Ponyprog zum Brennen (passenden Brenner habe ich schon)
Programmers Notepad als IDE
WinCVS für Sourcenmanagement
AVR-Studio 4.09 zum Debuggen/Simulieren

Es geht um ein Projekt an der Uni, und daher sollte alles frei und
relativ einfach zu bedienen/installieren sein dass sich die Studenten
den Kram dann auch zuhause installieren können.
Es gibt ja mittlerweile die GCC Tools für AVR Studio 4. Die haben ja
eigendlich einen kompletten Compiler dabei. Kann man nicht auch einfach
den direkt nutzen (statt WinAVR)? Also mit der AVR Studio GUI C Sources
schreiben, compilieren und auch Debuggen? Habe dazu nichts gefunden.

Viele Grüsse
Wolfgang

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Allerdings brauchst du erst mal ein paar Tage Übung bis du die
> ganzen Features beherscht.

Eine gute Untertreibung. :-)  ,,Die ganzen'' Features des GDB
beherrsche ich wohl nach fast 15 Jahren noch nicht ;-), aber das muß
man wohl auch nicht.  Für die tägliche Arbeit benötigt man eher so an
die 10 % aller Kommandos, vielleicht sogar noch weniger, alles andere
kann man nachlesen, wenn man es mal wirklich braucht.

> Insight kann aber nicht In-System Debuggen oder?

Insight kann nur das, was der GDB kann.

Der GDB kann via AVaRICE und JTAG-ICE auch in-system debugging.

> WinAVR (kommende Version mit hoffendlich ELF)

Auch die jetzige Version benutzt schon ELF. ;-)

Was Du sicherlich meinst ist DWARF2 debugging information.  Ja, die
kommende Version soll das haben, so viel weiß ich von Eric bereits
über seine Absichten.

Zur Referenz über die diversen Objekt- und Debugformate hier der
Zeiger auf

http://www.avrfreaks.net/phpBB2/viewtopic.php?t=20...

Bißchen Eigenwerbung :), aber das aufzuschreiben kostet so viel Zeit,
daß ich das nicht dreimal machen möchte.

> Ponyprog zum Brennen

Warum eigentlich, warum nicht gleich avrdude, und den Download aus dem
Makefile anwerfen?

> Es gibt ja mittlerweile die GCC Tools für AVR Studio 4.

Das ist 1. Beta-Software (besonders dabei der AVR Studio ELF/DWARF
Parser) und zweitens was den GCC anbelangt nur eine vorübergehende
Maßnahme.  Die Atmel-Jungs haben klar und deutlich geschrieben, daß
sie dieses Paket wieder einstellen werden, wenn es eine andere
allgemein verfügbare DWARF2-fähige Version des AVR-GCC geben wird
(z. B. in Form einer neueren Version von WinAVR), der AVR Studio
Parser wird irgendwann (wenn er nicht mehr Beta ist) dann offiziell
integriert.

> Also mit der AVR Studio GUI C Sources schreiben, compilieren und
> auch Debuggen?

Möglicherweise kann man das, aber da mußt Du Atmel fragen.  Bislang
haben sie keine Spezifikation bereitgestellt, wie ein 3rd-part
Compiler aus AVR Studio heraus aufzurufen wäre.  Auch dann, wenn
sie's
tun, muß diese Einbindung erstmal jemand mit hinreichend Motivation
schreiben.  Da es sich dem Vernehmen nach um eine DLL handeln wird,
die als Plugin im AVR Studio läuft, wird das auch nicht in 5 Minuten
erledigt sein -- und je mehr sich die anderen Komponenten von WinAVR
dem Anspruch der IDE-Habenwollenden nähern bzw. IDEs wie AVRside
diesen Ansprüchen gerecht werden, um so weniger Motivation wird es für
die Einbindungs ins AVR Studio geben.

Autor: Wolfgang Seemann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WOW!
Erstmal danke für die schnelle uns ausführliche Antwort! :o)

>Der GDB kann via AVaRICE und JTAG-ICE auch in-system debugging.

Ich fürchte das würde zu kompliziert. Ich bin selber dazu geneigt mich
tiefer in die Materie zu versetzen, aber wenn ich einen Studenten
betreue, der einen Controller programmieren soll, möchte ich doch am
liebsten 90% der Zeit damit verbringen, ihm beim eigendlichen
Programmieren zu helfen, und nicht bei der Einrichtung der benötigten
Software. Drum finde ich so ein Packet wie WinAVR sehr interessant,
aber die Zahl der zusätzlich benötigten Programme muss sich in Grenzen
halten.

>Was Du sicherlich meinst ist DWARF2 debugging information.  Ja, die
>kommende Version soll das haben, so viel weiß ich von Eric bereits
>über seine Absichten.

Hehe, genau das meinte ich...habe mich ungenügend ausgedrückt :o)

>Bißchen Eigenwerbung :), aber das aufzuschreiben kostet so viel Zeit,
>daß ich das nicht dreimal machen möchte.

Hehe, Deinen Post dort hatte ich vorgestern gelesen. Wirklich SEHR
ausführlich! Ein toller Beitrag! :o)

>> Ponyprog zum Brennen
>Warum eigentlich, warum nicht gleich avrdude, und den Download aus
>dem Makefile anwerfen?

Ich habe mir sogar schon einen passenden Brenner gebaut. Aber ich habe
es beim verrecken nicht geschafft die Fusebits zu schreiben. Ich weiss
bis heute nicht was ich falsch gemacht habe, aber als ich bei einem
Freund sah wie unkompliziert es mit Ponypro geht, bin ich dazu
umgestiegen. Da nicht nach jedel kompilieren auch der Controllr
gebrannt werden soll (Simulation in AVR-Studio), war für mich AVRDude
erstmal zweite Wahl. Irgendwann krame ich den Brenner nochmal raus und
versuche mein Glück :o)

Dass die GCC Tools von Atmel nicht auf Dauer supportet werden sollen,
habe ich wohl übersehen. Danke für die Info. Aber zumindest kann man
mit ihnen schön simulieren. Ich brauchte halt einen Simulator der SEHR
einfach zu bedienen ist, und den Satus der einzelnen Register schnell
und einfach anzeigt. Und das tut so weit ich es bisher gesehen habe der
Debugger/Simulator von AVR-Studio am Besten.

Ich hoffe einfach mal ganz doll dass schon sehr bald eine neue passende
Version von WinAVR rauskommt. Dann kann ich genau auf diese Verison ein
Tutorial schreiben, was die Studenten dann benutzen können. Dann kann
ich mir auch die GCC Tools sparen.
Dann mach ich mich mal an die Konfiguration vom Programmers Notepad :o)

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Drum finde ich so ein Packet wie WinAVR sehr interessant, aber die
> Zahl der zusätzlich benötigten Programme muss sich in Grenzen
> halten.

So what?  AVaRICE ist doch da auch mit dabei...

>> Warum eigentlich, warum nicht gleich avrdude...

> Ich habe mir sogar schon einen passenden Brenner gebaut.

Wofür das?  avrdude kann doch beinahe alles benutzen, was sich an die
parallele Schnittstelle klemmen läßt.

> ... Fusebits ... wie unkompliziert es mit Ponypro geht ...

Hmm, ich lese nur immer die Horrormeldungen über zerschossene
Fusebits, so daß der Chip hinterher nicht mehr reagiert.  Fast alle,
denen das passiert, haben Ponyprog im Einsatz.

Klar, das ist kein eigentliches Ponyprog-Problem, sondern eher eins,
daß man sich darüber im Klaren sein muß, daß in einem ROM eben ein
0-bit ein gesetztes Bit ist (genauso reagieren auch die Fuses), aber
ich habe den Eindruck (obwohl ich Ponyprog nie gesehen habe), daß
dieses Program mit seinem Klicker-Interface den Leuten vorgaukelt, den
Blick ins Datenblatt abnehmen zu können.  Fusebits einmal negiert
geschrieben, und schon ist guter Rat teuer: viele der Freunde haben ja
nichtmal auf die Schnelle einen 1 MHz Generator, mit dem man einen
externen Takt einspeisen kann.

Bei avrdude muß man sich dagegen ganz zwangsläufig mit dem Datenblatt
auseinandersetzen, bevor man eine Fuse zernagelt.  Ansonsten finde ich
das im Terminalmodus durchaus bequem machbar.  (Fusebits würde ich mir
eher nicht ins Makefile schreiben, da man sie ja sowieso nur ganz
selten einziges Mal setzen muß.)

> Da nicht nach jedel kompilieren auch der Controllr gebrannt werden
> soll (Simulation in AVR-Studio), war für mich AVRDude erstmal zweite
> Wahl.

Diese beiden Aussagen haben für mich keinen erkennbaren Zusammenhang.
Was hat die Simulation mit dem Download zu tun?

Als Simulation gefällt mir übrigens VMLAB besser als AVR Studio, dafür
kostet es aber Geld (das es meiner Meinung nach aber Wert ist).  OK,
AVR Studio habe ich nie wirklich getestet (habe kein Windows, und
unter Wine läuft es im Gegensatz zu VMLAB nicht), aber bereits die
Oberfläche im VisualFooBar-Look schreckt mich ausreichend ab. ;-)
Ich werde immer das Gefühl nicht los, daß man unter 30 Zoll
Bildschirmdiagonale mit dieser Art Oberfläche nicht sinnvoll arbeiten
kann.  (Allerdings überzeugt mich der Debugger von VMLAB mit seinem
Funktionsumfang genauso wenig wie das AVR Studio tut.  Ich finde das
alles fürchterlich umständlich zu bedienen und kaum benutzbar.  Da bin
ich wohl von GDB + Emacs einfach zu verwöhnt.)

Autor: Wolfgang Seemann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hehe :o)
Wenn ich die Wahl hätte meine Win2k Kiste hier auf der Arbeit
plattzumachen und alles unter Linux zu machen, wäre ich happy. Aber das
geht im beruflichen Alltag nunmal nicht :-/
Und wenn, wie gesagt, das Ganze auch einem Normalo-User, der keinerlei
Linux und Komandozeilererfahrung hat, zumutbar sein soll, engt sich die
Auswahl schon ein. Und dann auch noch möglichst alles kostenlos. Dann
wird´s noch enger.

Zum AVRdude: Das mit den negierten Fusebits war schon klar, aber der
Chip hat sich einfach nicht bewegt. Habe ihn an verschiedene
Taktequellen angeschlossen, die Bits IMHO richtig gesetzt, aber nix
ging. Der Brenner schien soweit auch OK zu sein.
Aber das klicki-bunti vom Ponyprog hat sich hier an der Uni in anderen
Instituten schon bewährt, drum werde ich mal dabei bleiben.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn ich die Wahl hätte meine Win2k Kiste hier auf der Arbeit
> plattzumachen und alles unter Linux zu machen, wäre ich happy. Aber
> das geht im beruflichen Alltag nunmal nicht :-/

Bei mir zum Glück schon. ;-)  (Kein Linux, sondern FreeBSD, aber das
ist in dieser Hinsicht wohl eher nebensächlich.)

> Und wenn, wie gesagt, das Ganze auch einem Normalo-User, der
> keinerlei Linux und Komandozeilererfahrung hat, zumutbar sein soll,
> engt sich die Auswahl schon ein.

Was heißt Normalo-User?  Diejenigen sollen ja zumindest Software
entwickeln, d. h. es muß nun wahrlich nicht alles Sekretösen-tauglich
sein.  Von einem Programmierer erwarte ich schon, daß er sich in die
Benutzung eines Werkzeuges einarbeiten kann.  Schließlich ging es auch
um eine Uni...  Es ist ja nicht so, daß diejenigen, die diese Software
geschrieben haben und weiterpflegen diesen Job bereits mit der vierten
Klasse beherrscht hätten oder sowas.  Allerdings haben sie irgendwann
mal den Mut gehabt, neue Wege zu beschreiten und sich mit Dingen
vertraut zu machen, die sie vorher noch nicht getan haben -- irgendwie
prägt diese Erfahrung dann auch die Erwartungshaltung an die
potentiellen Nutzer.

Wenn einer den Computer nur mit der Maus bedienen kann und keine
einzige Taste richtig findet, wie soll derjenige denn jemals eine
vernünftige Software zusammenschreiben können (ganz zu schweigen vom
Debuggen derselben)?  (Die Betonung liegt auf ,vernünftig'. ;-)

Vielleicht bin ich ja zu voreingenommen...

Autor: Wolfgang Seemann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hehe...ich weiss nicht ob du Informatik Studenten kennst :o)
Ich hatte ja eigendlich gedacht, dass die im Prinzip mehr Ahnung vom
Programmieren haben als ein durchschnitts E-Techniker (bin selber
einer), aber meine Erfahrung erzählt eine andere Geschichte. Einen C
Source schreiben und ein paar Register verwenden können da viele, aber
 die jetzige Generation von denen hatte auf Ihrem ersten Computer schon
ein klicki-bunti Windows, und weiss nicht mal mehr die grundlegensten
DOS Befehle. Wenn die einen Bildschirm mit weisser Schrift auf
schwarzem Hintergrund sehen isses schnell vorbei. Leider.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dazu fällt mir nur ein: der Mensch wächst mit seinen Anforderungen.
Wer nicht gefordert wird, wird also auch nichts leisten können.

Ja, ich kenne durchaus Informatikstudenten, wir haben regelmäßig
Praktikanten und Diplomanden in der Firma.  Gottseidank keine wie
die von Dir beschriebenen. :-)

(Ich bin auch kein Informatiker, sondern habe Elektroniktechnologie
studiert...)

Autor: Andreas Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Informatik ist hier in Erlangen zum Glueck sehr Unix-lastig (Linux
und Solaris). In der Uebung/Vorlesung fuer E-Techniker ging's auch
gleich mit der Shell und dem XEmacs los, das wurde aber klaglos
akzeptiert.

Autor: Wolfgang Neudert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine kleine Anmerkung noch zu den verschiedene Debuggern/Simultoren: Es
kommt (wie immer) darauf an, was man machen will. Wenn man zum Beispiel
mehr an der Hardware interessiert ist, Bits in Registern sehen will und
an Ausführungszyklen interessiert ist, hat AVRStudio IMHO doch noch
einige Vorteile. Eine Integration von GCC ins Studio - wie tiefgehend
auch immer - ist in Vorbereitung, genauso wie auch die Integration von
IAR-C.

Gruß,

Wolfgang

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast erstens den `display coprocess' von simulavr vergessen -- der
kann auch Registerinhalte live anzeigen.  Leider bremst er die
Simulation aber zusätzlich aus, und da man als C-Programmierer seine
Register ohnehin nicht selbst alloziert, nutze ich diesen daher fast
nur, wenn ich Assemblerprogramme simulieren muß.  Ansonsten genügt mir
"show registers" im GDB auch für den Fall der Fälle.

Außerdem sei natürlich darauf verwiesen, daß VMLAB das durchaus
mindestens genauso gut löst.

Autor: Wolfgang Neudert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, ich wollte auch nichts schlechtmachen. Ich meinte mit "Registern"
ja auch nicht unbedingt r0-r31, sondern die der Peripherie.
Und - wieso darf man als C-Programmierer keine Register selbst
allozieren ? Es ist manchmal mehr als sinnvoll, bei einer Variablen
festzulegen, ob die in einem Register wohnt oder im SRAM. Sowas kann
entscheiden, ob der Code in einen 4k - oder 8k- AVR passt, und hat ja
dann durchaus erhebliche kommerzielle Auswirkungen.

Freundliche Grüße aus dem Süden !
Wolfgang

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.