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
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
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
> 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=20887&highlight=dwarf+coff 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.
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)
> 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.)
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.
> 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...
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.
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...)
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.
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
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.
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
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.