Halli Hallo,
ich sitze momentan an einem (mittlerweile) etwas umfangreicherem Projekt
und bin nun auf ein paar Fragen gestoßen, wo mir der AVR Studio interne
Simulator NICHT mehr helfen kann.
Nach ein paar Recherchen ist mir aufgefallen, dass der Simulator wohl
mit 16bit Timern nicht zu recht kommt.
Also möchte ich jetzt in einen Hardware Debugger investieren. Da der ICE
MKII preistechnisch für studentische Verhältnisse ein "bisschen" übers
Ziel hinaus schiesst habe ich mich mehr oder weniger für den DRAGON
entschieden.
Bevor ich mir jenen zulege sind mir noch ein paar Fragen aufgekommen die
mich ein wenig stutzig gemacht haben.
In der Doku des STK
520(http://www.atmel.com/dyn/resources/prod_documents/doc7510.pdf) steht
lediglich der Anschluss des ICE MKII. In der Doku des DRAGON
(http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_connecting_to_target_through_the_debugwire_interface.htm)
steht nur was vom STK 500.
Bitte haltet mich nicht für blöd oder so, aber ich bin neu und möchte
einfach sicher gehen nicht die "Katze im Sack" zu kaufen ;-).
Ich vermute mal, dass man einfach das 6-polige Flachbandkabel, welches
jetzt im ISP Port des STK 500 steckt nachher in den DebugWire Port des
DRAGON steckt und fertig.
Als letzte Frage hätte ich dann noch die ISP <-> Debug Routine.
Also ich programmiere (ISP) -> habe ein Problem -> DWEN setzen ->
Debuggen -> Problem finden -> DWEN ausschalten -> wieder programmieren
(ISP)
Und alles das ohne das ISP/DebugWire Kabel umstöpseln zu müssen.
Kann man das so ganz einfach sagen?
Kurze Antworten:
- Hilfe im Studio zum Dragon ansehen -> wird dein Controller
unterstützt?
- STK520 ist nur ein Addon Board zum STK 500 -> wenn die Pins zugänglich
sind, dann ist es kein Problem da auch mit dem Dragon zu debuggen
- ISP und JTAG/Debugwire (zum debuggen) liegen auf unterschiedlichen
Pins -> Umstecken erforderlich ABER über JTAG kann auch programmiert
werden, dann ist kein Umstecken nötig. JTAG braucht jedoch mehr Pins als
ISP. Man kann sie aber unter Umständen doppelt belegen -> Suchfunktion
Der Dragon kann so ziemlich alles Programmieren, was AVR im Namen hat.
Insbesondere spricht er ISP, JTAG, DebugWire, PDI (XMega!) und die
parallelen Modi.
Ich sehe also keinen Grund, warum du ihn nicht mittels entsprechendem
Kabel an das STK anschließen können solltest.
mfG
Markus
Markus J. schrieb:
> mittels entsprechendem>> Kabel
welches dann das 6-polige Flachbandkabel ist, was man normalerweise auf
nem nackten STK 500 für die ISP nimmt?
Hc Zimmerer schrieb:
> Du kannst auch über DW den Flash programmieren. Es besteht keine>> Notwendigkeit, jedes Mal auf ISP zurückzuwechseln.
Toll! Das ist ja viel komfortabler als ich dachte!
Wenn ichs richtig verstanden hab kann ich das Kabel lassen wo es ist und
kann flashen und debuggen wie ich lustig bin?!
Warum dann überhaupt ISP? Quasi JEDER AVR spricht doch entweder JTAG
oder DW???
Roter_Drache schrieb:
> welches dann das 6-polige Flachbandkabel ist, was man normalerweise auf> nem nackten STK 500 für die ISP nimmt?
Keine Ahnung, ich habe kein STK500 - aber in der Doku steht die
Pinbelegung mit Sicherheit - und die Anschlüsse am Dragon sind auch
dokumentiert, also kannst du dir bei Bedarf ein Adapterkabel bauen.
Roter_Drache schrieb:
> Warum dann überhaupt ISP? Quasi JEDER AVR spricht doch entweder JTAG> oder DW???
Weil DW per default nicht an ist, ferner ist DW neuer als ISP und nicht
jeder AVR hat DW oder JTAG.
Außerdem ist DW störanfälliger und afaik auch langsamer.
mfG
Markus
Markus J. schrieb:
>> welches dann das 6-polige Flachbandkabel ist, was man normalerweise auf>> nem nackten STK 500 für die ISP nimmt?>> Keine Ahnung, ich habe kein STK500
Jaja, ist genau so ein Kabel.
>> Warum dann überhaupt ISP? Quasi JEDER AVR spricht doch entweder JTAG>> oder DW???>> Weil DW per default nicht an ist, ferner ist DW neuer als ISP und nicht> jeder AVR hat DW oder JTAG.> Außerdem ist DW störanfälliger und afaik auch langsamer.
Alles richtig. Kommt hinzu, dass debugWIRE eine Art "in Hardware
gegossenes Monitorprogramm" ist (in ganz alten Atmel-Dokus wird es
zuweilen als "MonCon" bezeichnet). Damit kann es folglich nur auf
die Resourcen zugreifen, auf die die CPU selbst Zugriff hat, insbe-
sondere kann man über debugWIRE keine Fuses ändern.
Gut zu wissen.. Danke schonmal hierfür.
Nun habe ich aber etwas, dass meine ganzen Pläne nochmal durcheinander
wirft -.-
Bei eepro-student.de gibt es das ICE MKII für 140 Euro! Und den Dragon
für 30 Euro. Das heißt der Preisunterschied von vorher 240€ (300€ <->
60€) zu jetzt 110€ ist enorm!
Würdet IHR bei solch einem Angebot den ICE MKII dem Dragon vorziehen???
grübel
Das hängt davon ab, wie viel du damit machen willst und was du sonst
noch hast.
Vorzüge JTAG ICE mkII:
. ein Gehäuse; du kannst das Teil irgendwo in deinem Testaufbau
herum fliegen lassen, ohne dass du gleich einen Kurzschluss
riskierst
. bessere Schutzschaltungen an den IO-Pins als der AVR Dragon;
einen Dragon bekommt man relativ schnell kaputt, wenn man etwas
unachtsam ist, die aktuellen JTAG ICE mkII sind sehr robust (bei
der ersten Serie bekam man auch schon mal die Maxim-Levelshifter
geräuchert, aber die ließen sich auch noch ersetzen)
. weiß nicht, wie's mit AVR32 und dem Dragon aussieht, das ICE kann
das auf jeden Fall auch (falls das mal ein Thema werden sollte)
. kleinere Gimmicks wie die Tatsache, dass die diversen Adapter, die
man in der täglichen Nutzung braucht, im Paket beiliegen
. wenn einen die USB-Treiber aus irgendeinem Grund völlig nerven,
hat man noch den Fallback auf RS-232 (bei etwa halber Geschwindig-
keit gegenüber USB)
Vorzüge AVR Dragon:
. billiger; OK, das wusstest du schon ;-)
. kann zusätzlich zu den Funktionen des JTAG ICE mkII noch HV-
Programmierung
. kann mit einer Fassung bestückt und dadurch zum kompletten
standalone programmer werden
. kann 5 V als Versorgung für die Zielschaltung liefern
Eine eigene Frage?
Dieser Thread ist über 16 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
