mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR Dragon DLL gepatcht! >32K Code


Autor: Sergey (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Daniel B. (inox5) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das is geil für größere projekte...

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klingt toll - hat das schon wer wirklich getestet? (z.B. die Jungs mit 
dem Mega 64/128)

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: C. H. (_ch_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: C. H. (_ch_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: nicht ganz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Einhart (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marius Wensing (mw1987)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ähm, falscher Thread?!

MfG
Marius

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

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

Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>> 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 ?

Autor: Oliver Keller (ozel-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

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.