www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Erfahrungen mit JTAGICE mkII


Autor: GF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen


Ich bin dran mir endlich einen JTAGICE mkII zuzulegen. Zielhardware für 
mein neues Projekt wird ein Mega32.
Wenn ich alles richig verstanden habe, dann gibts 3 Möglichkeiten für 
die Debug- und Programmierschnittstelle.
1. SPI
2. JTAG
3. debugwire

Ich dachte dran SPI zu benutzen. An Pins muß ich nicht sparen und bei 
JTAG brauchts halt mehr Leitungen.

Was ist euer Rat? Gibts handfeste Gründe für die eine oder andere 
Anschlußart?

Gruß
Gerhard

Autor: Jones (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mega32 nix debugWire. Debuggen über SPI geht sowieso nicht. Nur JTAG ;)
Also erübrigt sich die Frage wenn du debuggen willst

Autor: myscha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja kommt drauf an was du willst:
- mit ISP kannst du nur programmieren
- mit JTAG kannst du programmieren und debuggen
- debugWIRE kann der Mega32 meines Wissens nicht

Wenn du die Möglichkeit zum debuggen möchtest, nimm JTAG. Das braucht 
gerademal einen uC-Pin mehr als ISP.

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

Bewertung
0 lesenswert
nicht lesenswert
> Gibts handfeste Gründe für die eine oder andere Anschlußart?

Außer dem schon Genannten:

* JTAG taktet selbst, man kann damit also auch versaute
  clock fuses reparieren

* Programmieren über JTAG ist viel schneller als über ISP, wird an
  Geschwindigkeit nur noch von Parallelprogrammierung übertroffen,
  aber die geht nicht in-system (normalerweise jedenfalls).

Bei einem ATmega32 kannst du übrigens auch noch den preiswerten AVR
Dragon benutzen, falls du sparen willst.  Für professionelle
Anwendung ist am richtigen ICE aber das Gehäuse schon ein Vorteil,
auch gibt's da einen besseren elektrischen Schutz der JTAG-Leitungen
(mittlerweile).  Kommt hinzu, dass der Schaltregler auf dem Dragon
leider dafür berüchtigt ist, dass er schnell mal sich komplett in
Wohlgefallen auflösen kann.  (Falls das passiert, kann man ihn aber
auch überbrücken, das geht trotzdem noch.)

Autor: GF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt du hast Recht. Dann eben JTAG!
Danke für die schnelle Antwort.

Aber generell interessierts mich schon. Gibts praktische Vor- oder 
Nachteile zwischen JTAG und debugwire?

Autor: GF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke auch an Jörg und Myscha.
Ich werd dann mal mit JTAG loslegen.

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

Bewertung
0 lesenswert
nicht lesenswert
GF wrote:

> Aber generell interessierts mich schon. Gibts praktische Vor- oder
> Nachteile zwischen JTAG und debugwire?

debugWire ist ein 1-wire-Bus mit offenen Kollektoren.  Damit kommt
er prinzipbedingt nur mit einem engen Bereich von Pullups zurecht
und verkraftet keine zusätzliche Beschaltung am /RESET-Pin.  Auch
ist natürlich die Übertragung auf nur einem Draht viel langsamer
als auf drei Drähten, du musst im Protokoll Abklingzeiten für die
RC-Glieder mit einplanen und entsprechende Reserven haben.

debugWire kann nur auf die Ressourcen zugreifen, auf die auch die
CPU intern selbst zugreifen kann.  Daher lassen sich mit debugWire
keine Fuses manipulieren, nur Flash-ROM und EEPROM (und das ist
nach meinen Erfahrungen dann auch langsamer und anfälliger, als es
über ISP zu machen).  debugWire hat keine Hardware-Breakpoints,
sondern das muss alles mit BREAK-Befehlen (und entsprechendem
automatischem Umflashen ganzer Pages) erfolgen.  OK, wenn du bei
JTAG mehr als drei Breakpoints (der vierte ist für single step
reserviert) benutzt, hast du auch soft-BPs, aber dort kannst du
das zumindest damit noch steuern.  JTAG-Breakpoints lassen sich
auch auf RAM-Manipulationen ansetzen, das geht bei debugWire gar
nicht.

debugWire ist nett, weil man Drähte spart.  Es kommt in der Praxis
aber nicht ohne parallel genutztes ISP aus, damit ist die Ersparnis
gegenüber JTAG eigentlich futsch -- JTAG kommt komplett ohne ISP
aus, sofern man sich nicht gerade ins Knie schießt und die JTAGEN-
Fuse wegprogrammiert.  (Mit ISP kann man die SPIEN-Fuse nicht
wegprogrammieren, das ist dort gesichert.)

Dennoch ist debugWire eine gute Ergänzung für die kleinen Controller,
die man zuvor einfach mal gar nicht live debuggen konnte.  Wenn ich
mir's für die initiale Entwicklung aber aussuchen kann, würde ich
lieber auf einem AVR mit JTAG entwickeln und dann auf den Ziel-AVR
,,downsizen''.

Autor: GF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch an Jörg vielen Dank für die ausführliche Erklärung!

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> * Programmieren über JTAG ist viel schneller als über ISP, wird an

Das kann ich bisher nicht bestätigen. Hast du da Vergleichszeiten? 
Bisher war ich mit ISP (zumindest mit dem AVRISP mkII) schneller als mit 
JTAG, egal ob Dragon oder JTAGICE mkII (hab ich alles hier).

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

Bewertung
0 lesenswert
nicht lesenswert
Markus Burrer wrote:

> Das kann ich bisher nicht bestätigen. Hast du da Vergleichszeiten?

Lange nicht mehr ISP gemacht...  Mit JTAG bekomme ich hier gerade 21
KiB in 3,3 s geflasht und in 1,6 s gelesen.  Kommt natürlich sicher
auch auf den Prozessortakt an, mit dem AVRISPmkII kann man bei hohen
CPU-Frequenzen ja den ISP-Takt noch raufsetzen.  Ich habe mit ISP
nahezu aufgehört, bevor das AVRISPmkII rauskam, weil ich das JTAG
sowieso fürs Debuggen brauche.  Davor hatte ich nur ISP-Programmer,
die nicht so schnell gearbeitet haben.

Bei einem im Auslieferungszustand mit 1 MHz getakteten AVR
(ISP-Frequenz muss kleiner 250 kHz sein) dürfte man mit ISP
gegenüber JTAG keine Chance haben.  JTAG kann dank seines
eigenen Taktes ja trotzdem mit 4 MHz arbeiten.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß jetzt nicht wie es mit dem JTAGICE genau ist, mit dem hab ich 
noch nicht viel gemacht, aber der Dragon ist mit JTAG langsamer als der 
ISP mkII.

Kann JTAG tatsächlich immer mit 4MHz laufen, auch wenn der AVR selbst 
nur mit 4MHz oder weniger läuft? Ich hab mich damit noch nicht so 
intensiv auseinandergesetzt.

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

Bewertung
0 lesenswert
nicht lesenswert
Markus Burrer wrote:

> Ich weiß jetzt nicht wie es mit dem JTAGICE genau ist, mit dem hab ich
> noch nicht viel gemacht, aber der Dragon ist mit JTAG langsamer als der
> ISP mkII.

Ich wüsste erstmal nicht, warum er langsamer sein soll.  Habe mit
avrdude da bislang keine Unterschiede gesehen.  Ist ja praktisch
die gleiche Elektronik drin, auch das gleiche USB-Interface.

Wenn ich mal Zeit habe, mache ich selbst mal paar Tests.  Hab' den
Krempel ja komplett da.

> Kann JTAG tatsächlich immer mit 4MHz laufen, auch wenn der AVR selbst
> nur mit 4MHz oder weniger läuft?

Zum Programmieren: ja.  Zum Debuggen: nein.  Bei ersterem wird der
CPU-Takt ja nicht benötigt.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
>
> Ich wüsste erstmal nicht, warum er langsamer sein soll.  Habe mit

Vielleicht aus dem gleichen Grund wie bei ISP auch. Hab mal vor einer 
Weile ein bissel rumgetestet

Beitrag "AVR Dragon nur so schnell wie STK500?"

Ist alles nur ISP und ich war über das Ergebnis mehr als überrascht. Ich 
hab den Versuch mehrfach wiederholt immer mit dem gleichen Ergebnis.

Ein Kunde wollte mal einen JTAG Programmer für eine Fertigungsstraße. 
Daraufhin hab ich mal mit dem Dragon und JTAG rumexperimentiert und mit 
dem ISP mkII verglichen. Der Dragon kam einfach nicht mit. Ich glaube 
ich hatte damals auch den JTAGICE mkII getestet und war der Meinung er 
wäre genauso schnell wie der Dragon, bin mir aber nicht mehr sicher.

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

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Wenn ich mal Zeit habe, mache ich selbst mal paar Tests.  Hab' den
> Krempel ja komplett da.

OK, here we go.  Die Testdatei war 29704 Bytes groß.  Target ist ein
ATmega6490, der mit 8 MHz vom RC-Oszillator getaktet wird.  Das alles
mit einem AVRDUDE 5.5.
Programmer     Parameter     Zeit
                             Schreiben  Lesen

JTAG ICE mkII  default        2,58 s     3,27 s
JTAG           (4 MHz)

AVRISP mkII    250 kHz        5,37 s     5,46 s
               1 MHz          2,45 s     2,45 s
               2 MHz          1,89 s     1,99 s

STK500         900 kHz        5,84 s     3,49 s
               (schnellstes)

AVR Dragon     default        2,81 s     3,49 s
JTAG           (4 MHz)

AVR Dragon     1 MHz          8,34 s     8,64 s
ISP            2 MHz          -          -        (*)

JTAG ICE mkII  1 MHz          8,34 s     8,51 s   (**)
ISP

Parallelport-  keine Delay   13,20 s    12,45 s   (**)
Dongle "alf"   CPU 900 MHz

(*) Benutzung unmöglich, weder Fuses noch Signature zuverlässig
lesbar.

(**) Fuses und Signature OK, aber das programmierte Ergebnis is
fehlerhaft (verify errors)


Fazit:

* Meine Meinung, JTAG sei generell schneller als ISP stammt noch aus
der Zeit von vor dem AVRISPmkII.  Dieses kann wirklich schneller
arbeiten als JTAG, sofern man den SPI-Takt hinreichend weit hoch
setzen kann (genügend schnelle CPU).

* Für die 1 MHz Standard-CPU-Takt (maximaler ISP-Takt 250 kHz) ist
JTAG aber bereits etwa doppelt so schnell.

* Der AVR Dragon ist bei JTAG geringfügig langsamer als das JTAG ICE
mkII, warum auch immer.

* (Nicht hier dargestellt, aber früher gemessen.)  JTAG ICE mkII über
RS-232@115200 Bd statt über USB ist bei JTAG ca. halb so schnell.

* JTAG ICE mkII und AVR Dragon im ISP-Mode sind ziemlich langsam.  Das
könnte am relativ umständlichen Einbetten des kompletten AVRISPmkII-
Protokolls in das JTAG ICE mkII-Protokoll liegen.  Dieser Modus ist in
erster Linie überhaupt entwickelt worden, damit Nutzer von debugWire
beim Umschalten auf ISP nicht jedesmal noch den Programmieradapter mit
wechseln müssen (ursprünglich konnte das JTAG ICE mkII kein ISP), und
dafür ist er sicher brauchbar -- debugWire kommt ja eher bei kleineren
Controllern zum Einsatz.  (OK, beim ATmega328P gilt diese Aussage so
nicht mehr...)  Falls man auf die Geschwindigkeit Wert legt, kann man
aber einen AVRISPmkII damit keinesfalls ersetzen.

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

Bewertung
0 lesenswert
nicht lesenswert
Markus, wollte den Artikel nur nochmal ,,pushen'' (sorry für die
Eigenwerbung), da übers Wochenende so viel hier aufgelaufen war.

Frage an alle: sollte man so'ne Tabelle (von mir aus umgerechnet
nach KiB/s Lese- und Schreibgeschwindigkeit) irgendwo im Wiki
ablegen?

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

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Frage an alle: sollte man so'ne Tabelle (von mir aus umgerechnet
> nach KiB/s Lese- und Schreibgeschwindigkeit) irgendwo im Wiki
> ablegen?

Hat zwar keiner geantwortet, aber ich hab's nun trotzdem mal im
Wiki abgeladen:

AVR In System Programmer: Geschwindigkeitsvergleich

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.