Ich bin verwirrt. Ich dachte bisher, JTAG benötigt zwar viele Leitungen, ist dafür aber recht flott. SWD benötigt nur max. 3 Leitungen, ist dafür aber langsamer. Nun lese ich mir aber gerade diesen Artikel zum STM32 durch: http://www.mikrocontroller.net/articles/STM32 Dort steht jedoch geschrieben (siehe screenshot), dass SWD schneller sein soll. Ist das ein Fehler im Artikel oder habe ich mich geirrt? Das würde dann schließlich bedeuten, dass JTAG gar keine Vorteile mehr bringen würde.
Hi, in deinem Bild steht doch einer der Unterschiede. "Device Chaining ist mit dieser Schnittstelle nicht möglich". MfG Alex
brechbunkt schrieb: > Ich bin verwirrt. Ich dachte bisher, JTAG benötigt zwar viele Leitungen, > ist dafür aber recht flott. SWD benötigt nur max. 3 Leitungen, ist dafür > aber langsamer. Für die Datenübertragung sind immer nur 2 Leitungen relevant, Takt und Daten. Dass JTAG die Datenrichtung unterscheidet bietet allenfalls beim Kabel Vorteile, aber nicht beim Tempo. Die zusätzlichen Leitungen von JTAG bringen fürs Tempo nichts.
Es ist so wie geschrieben: VORTEIL: Über ein JTAG Ringbus können viele verschiedene Bausteine angesteuert werden. NACHTEIL: JTAG ist nicht für SW-Debugging angedacht, sondern für HW-Testing (Lötfehler) in digitalen Schaltungen. Die meisten uC-Hersteller haben dann proprietäre erweiterungen in das JTAG-Interface gebastelt, um darüber auch programmieren und zu debuggen zu können, dann ist aber in der regel nix mehr mit Daisy-Chaining. SWD ist ausschliesslich zum debuggen ausgelegt, und ist daher effizienter und schneller...
Ich vermute, dass der Unterschied im Tempo am Protokoll liegt. Also dass SWD für die gleiche Aufgabe weniger Bits übertragen muss.
A. K. schrieb: > Für die Datenübertragung sind immer nur 2 Leitungen relevant, Takt und > Daten. Dass JTAG die Datenrichtung unterscheidet bietet allenfalls beim > Kabel Vorteile, aber nicht beim Tempo. Die zusätzlichen Leitungen von > JTAG bringen fürs Tempo nichts. JTAG ist bidirektional und SWD ist unidirektional. JTAG kann also beim Senden der Daten gleichzeitig Daten empfangen. Bei der SWD-Schnittstelle ist immer nur eine Richtung möglich und die Umschaltung zwischen Senden und Empfangen der Daten auch noch zeitaufwendiger und dadurch langsamer. Ob das SWD-Interface mit einer höheren CLK angesprochen werden kann weiß ich nicht.
SWD hat wohl doch einige Vorteile wenn man die richtige Debug-Hardware besitzt:
1 | Only 2 pins required - vital for very low connectivity devices or packages |
2 | Provides debug and test communication to JTAG TAP controllers |
3 | Enables the debugger to become another AMBA bus master for access to system memory and peripheral or debug registers |
4 | High performance data rates - 4 Mbytes/sec @ 50 MHz |
5 | Low power - no extra power or ground pins required |
6 | Small silicon area - 2.5k additional gates |
7 | Low tools costs, $100 build costs - may be built in to evaluation boards |
8 | Reliable - built in error detection |
9 | Safe - protection from glitches on pins when tools not connected |
10 | Single Debug Port for Multi-chip Products (ARM) |
Hoe? schrieb: > JTAG ist bidirektional und SWD ist unidirektional. JTAG kann also beim > Senden der Daten gleichzeitig Daten empfangen. Klar. Aber ein ebenfalls mit dem verwandten SPI duplex angebundendes Flash-ROM wird dadurch auch nicht schneller. Wäre also die Frage, ob man davon etwas hat. Beim Flashen jedenfalls nicht. TI erwähnt zum CM3 bei 20MHz JTAG/SWD-Takt eine Transferrate von 640KB/s für JTAG gegenüber 1500KB/s für SWD.
Salut, > NACHTEIL: JTAG ist nicht für SW-Debugging angedacht, sondern für > HW-Testing (Lötfehler) in digitalen Schaltungen. Die meisten > uC-Hersteller haben dann proprietäre erweiterungen in das JTAG-Interface > gebastelt, um darüber auch programmieren und zu debuggen zu können, dann > ist aber in der regel nix mehr mit Daisy-Chaining. Ich darf doch berichtigen: JTAG ist immens flexibel, und genauso fürs SW-Debuggen angedacht. Das Daisy-Chaining funktioniert dabei immer noch genauso, sofern der JTAG-Standard richtig implementiert wird (BYPASS). Das haben allerdings einige Hersteller wie z.B. TI bei etwas älteren MSP430 verbockt. Geht bei mir allerdings eher unter "bug" als "proprietäre Erweiterung". Was die Geschwindigkeit angeht, ist es meist eine Frage der Implementierung, wieviele Bits pro Aktion runtergeschickt werden müssen. Theoretisch dürfte man mit JTAG mehr Speed hinkriegen. Grüsse, - Strubi
Strubi schrieb: > Was die Geschwindigkeit angeht, ist es meist eine Frage der > Implementierung, wieviele Bits pro Aktion runtergeschickt werden müssen. > Theoretisch dürfte man mit JTAG mehr Speed hinkriegen. Kennst du die JTAG- und SWD-Protokolle genau genug, um abschätzen zu können, wieviele Bits beispielsweise für das Schreiben eines Wortes in den Speicher übertragen werden müssen? JTAG und SWD scheinen sich im Protokoll zu unterscheiden und das kann den Ausschlag geben.
Warum spekuliert Ihr hier eigentlich rum und holt euch nicht die passenden Dokumente von ARM? ARM® Debug Interface v5 Architecture Specification ARM IHI 0031A ARM® Debug Interface v5 Architecture Specification ADIv5.1 Supplement DSA09-PRDC-008772 fchk
Frank K. schrieb: > Warum spekuliert Ihr hier eigentlich rum und holt euch nicht die > passenden Dokumente von ARM? Weil du bestimmt grad dabei bist, dich da systematisch durchzuwühlen, und uns anschliessend informierst.
A. K. schrieb: > Frank K. schrieb: >> Warum spekuliert Ihr hier eigentlich rum und holt euch nicht die >> passenden Dokumente von ARM? > > Weil du bestimmt grad dabei bist, dich da systematisch durchzuwühlen, > und uns anschliessend informierst. Nö. Selber lesen macht schlau. fchk
Einen Vorteil hat SWD auf jeden Fall: Wenn man irgendwas vergurkt hat und per JTAG nicht mehr an den Controller ran kommt, per SWD geht es noch.
Frank K. schrieb: > Nö. Selber lesen macht schlau. Eine vage Vorstellung davon habe ich auch so schon. Also weshalb sollte ich versuchen, aus dem nicht ganz so trivialen JTAG-Wust herauszulesen, wie man damit den Speicher vollschreibt? Der Einzige mit einem konkreten Motiv wäre der TO, aber ich denke, genauer als das was TI schreibt braucht er es auch nicht.
Bitte 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.