http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=67689 http://www.ouravr.com/bbs/bbs_content.jsp?bbs_sn=1385291&bbs_page_no=1&bbs_id=9999
klingt toll - hat das schon wer wirklich getestet? (z.B. die Jungs mit dem Mega 64/128)
noch mal nach oben bring..... Kann das mal jemand mit einem größeren MEGA und Code > 32k testen?? Ist bestimmt für viele Bastler interessant.
Daniel B. wrote: > das is geil für größere projekte... Und wozu braucht man dafür einen Dragon? Größere Projekte sind meistens zu komplex, um da durchzusteppen. Da ist es effektiver, schon beim Programm schreiben besser zu überlegen und zu planen anstelle von Trial&Error. Das Durchsteppen braucht man eigentlich nur als Anfänger, um den AVR kennen zu lernen. Aber auch nur für die Sachen, die der Simulator nicht kann. Peter
Peter Dannegger wrote: > Das Durchsteppen braucht man eigentlich nur als Anfänger, um den AVR > kennen zu lernen. Aber auch nur für die Sachen, die der Simulator nicht > kann. Warum haben dann erst immer alle "größeren" Controller JTAG? Gruß Christian
ich glaube eigentlich auch nicht, das ich Code >32k damit debuggen werde aber hier gab es doch mal einen Thread wo zu diesem Zweck sogar neues RAM auf den Dragon gelötet wurde - ist es in Wirklichkeit so einfach??
Warum sollte man Code >32K nicht mehr durchsteppen wollen? Schließlich muss man meist ja nicht durch den ganzen code steppen sondern nur durch den Teil, welcher Fehler verursacht.
Lupin wrote: > Warum sollte man Code >32K nicht mehr durchsteppen wollen? Schließlich > muss man meist ja nicht durch den ganzen code steppen sondern nur durch > den Teil, welcher Fehler verursacht. Diese Frage stelle ich mir auch - aber wahrscheinlich nehmen die Fehler relativ zur Codegröße so stark ab, dass Steppen einfach nicht mehr lohnt ;-) Gruß Christian
Naja. die Anfaenger wollen sparen und verwenden die kleineren Tiny & Mega. Dabei machen sie bis zu 10 Fehler pro ASM Zeile. Waehrend die Profis die grossen Mega benutzen und dabei vielleicht noch 1 Fehler auf 1000 Zeilen machen. Nein ?
Lupin wrote:
> Warum sollte man Code >32K nicht mehr durchsteppen wollen?
Man will auch durch Code <= 32 KiB nicht schrittweise durchgehen. ;-)
Das dauert nämlich einfach mal ewig, und das Timing (auf das es bei
einer Controller-Applikation häufig ankommt) ist im Gesäß.
Aber man (Ausnahme: Peter, der ist da masochistisch) will natürlich
auch Controller > 32 KiB trotzdem debuggen können. Ich habe
beispielsweise prinzipiell einen Breakpoint auf der Funktion
bios_abort(), die im Fehlerfall von einem ASSERT-Makro gerufen wird.
Wenn die Applikation einen internen Fehler feststellt, dann zieht
sie die Notbremse, und man kann mit dem Debugger noch den Fehler
versuchen zu analysieren.
Peter hat einfach nur nie sowas benutzt, daher weiß er nicht, was
er sich alles vergibt damit. Ja, sicher, auch ich habe früher
komplexe Software auf einem Z8 ohne in-circuit-Debugger geschrieben,
aber ich möchte sowas trotzdem nicht mehr missen. Es ist einfach
viel schneller und flexibler, als sich erst irgendwelche Debughilfen
zu zimmern.
Den extra RAM braucht es übrigens nicht, der vorhandene genügt
problemlos.
Jörg Wunsch wrote: > Ich habe > beispielsweise prinzipiell einen Breakpoint auf der Funktion > bios_abort(), die im Fehlerfall von einem ASSERT-Makro gerufen wird. > Wenn die Applikation einen internen Fehler feststellt, dann zieht > sie die Notbremse, und man kann mit dem Debugger noch den Fehler > versuchen zu analysieren. Wenn die Applikation ganz normal los läuft und man nachträglich den JTAG-Debugger anschließen kann, wenn der Breakpoint erreicht wurde und dann erst debuggen, wär das wirklich fein. Ich hatte nicht vermutet, daß das mit dem AVR geht. > Peter hat einfach nur nie sowas benutzt Sagen wir mal so, das, was ich bisher an Debuggern probiert hatte, war einfach total krank: Um debuggen zu können, mußte man ständig die Debugsitzung offen halten und das Programm kann nicht mit dem Power-On starten, d.h. alle anderen Interfaces halten den zu debuggenden MC schon längst für tot, ehe der endlich mal losläuft. Auch wurde jedesmal erst die Applikation neu geflasht, egal ob ich was geändert hab oder nicht. An einen realen Programmablauf während des Debuggens war also nicht zu denken. Peter
Peter Dannegger wrote: > Wenn die Applikation ganz normal los läuft und man nachträglich den > JTAG-Debugger anschließen kann, wenn der Breakpoint erreicht wurde und > dann erst debuggen, wär das wirklich fein. Nun, ich habe während der (u. U. einige Tage oder Wochen) laufenden Testphase das JTAG ICE immer gleich dran. Aber es geht rein vom ICE her auch nachträglich, AVaRICE kann das auch (Option -C), jedoch hat AVR Studio derzeit ein Problem, das zu unterstützen. > Um debuggen zu können, mußte man ständig die Debugsitzung offen halten > und das Programm kann nicht mit dem Power-On starten, d.h. alle anderen > Interfaces halten den zu debuggenden MC schon längst für tot, ehe der > endlich mal losläuft. Das mit dem Power-On ist ein wenig ein Henne-und-Ei-Problem. Der Debugger kann ja schlecht arbeiten, solange der Controller noch nicht arbeitet... > Auch wurde jedesmal erst die Applikation neu geflasht, egal ob ich was > geändert hab oder nicht. Das ist auch eins der Misfeatures, die mich an AVR Studio extrem stören und die es mich selbst dann nicht benutzen lassen wollen, wenn ich ein Windows hätte. Ich bin ein Freund expliziter Aktionen, und ich möchte einfach selbst entscheiden, wann ich den Controller flashe und wann ich ihn ,,nur'' debuggen will. Mit AVRDUDE und AVaRICE kein Thema, allerdings ist die Bedienung des GDB wohl nicht jedermanns Sache.
Natürlich braucht man einen Debugger denn 99,99% der Programmierer machen Fehler. Das Dragon Board ist mit seine Programmier-, Test- und Debugmöglichkeiten super geeignet (und preisgünstig). Perfekte Softwareentwickler wie Peter habe ich in meinem langen Leben leider noch nicht kennengelernt ;-) Wenn jemand ein Zielsystem > 32K hätte und das 'mal testen könnte würde mich das auch interessieren. Gruß Einhart
Wenn die Einschränkung wirklich an der DLL liegt, müsste doch mit AVARICE auch Code > 32K zu debuggen sein, oder sehe ich da was falsch?
Fred wrote: > Wenn die Einschränkung wirklich an der DLL liegt, müsste doch mit > AVARICE auch Code > 32K zu debuggen sein, oder sehe ich da was falsch? Naja, die DLL verhindert wohl, dass man den Dragon auswählen kann im AVR Studio, mehr dürfte das nicht sein. Parallel hat er ja noch die XML-Files gehackt, sodass sie dem Dragon weniger Speicher vorgaukeln -- sonst quittiert er bei Auftauchen eines Debugger-typischen Befehls auf einem Controller mit > 32 KiB ROM den Dienst. Bei AVaRICE müsstest du die device descriptors in src/devdescr.cc hacken dafür. Falls du einen neueren AVR hast, den es auch mit einem Familienmitglied < 32 KiB gibt, kannst du einfach einen solchen mit -P aussuchen, also bspw. einen ATmega324P statt eines ATmega644P. Man könnte natürlich noch einen ATmega320 dazu erfinden, um die ATmega640/1280/1281/2560/2561 auf diese Weise zu debuggen... >:-) Ich hatte mich schon immer gefragt, was der Dragon eigentlich macht, wenn man ihm weniger ROM-Größe erzählt, als das Device dann hat, der Code aber trotzdem einfach mal so jenseits der angegebenen Größe tuckert... offenbar kümmert es ihn gar nicht. ;-)
Also ich stand zu Beginn genau vor der selben Fragestellung: Welchen Progger? Angefangen hatte ich auch mit einem LTP- Widerstandsprogger, jedoch relativ schnell die Lust daran verloren, da immer mal wieder etwas nicht richtig geklappt hat, keine Ahnung wieso. Dann hab ich mir den USBprog gekauft und muss sagen, dass ich sehr zufrieden bin mit dem Teil! Hat bis jetzt bei mir wunderbar alles programmiert, und auch schon andere Aufgaben, wie RS232 --> USB Adapter ordentlich ausgeführt. Gruß, Steffen
Ui, verdammt....War der falsche Threat. Meinen vorherigen Post nicht beachten ;-).
Angehängte Dateien:
-
dragon.png
36 KB
>> Auch wurde jedesmal erst die Applikation neu geflasht, egal ob ich was >> geändert hab oder nicht. >Das ist auch eins der Misfeatures, die mich an AVR Studio extrem stören Schon gesehen ?
Ich weiß, der Thread ist älter, aber vielleicht schaut jörg ja nochmal rein: wie wärs denn mit einem command line switch für avarice, der die ROM größe vom erkannten (oder manuell ausgewählten) device automatisch überschreibt? Oder ein "--dragon-hack", das die ROM größe bei Bedarf automatisch reduziert :-)
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.