AVR Dragon DLL gepatcht! >32K Code

das is geil für größere projekte...

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

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

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.

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

Ähm, falscher Thread?!

MfG
Marius

Ui, verdammt....War der falsche Threat. Meinen vorherigen Post nicht 
beachten ;-).

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 :-)