Hallo Forumgemeinde, zurzeit verwende ich ein STK500 zur Programmierung meiner Mikrocontroller. Debuggen geht damit allerdings nicht und da mir die Ausgabe von Debugmeldungen auf einem LCD auf Dauer zu nervig ist und außerdem einen Port belegt, denke ich über die Anschaffung eines Debuggers nach. Bei meiner Suche bin ich dabei auf JTAG ICE3 und AVR Dragon gestoßen. Leider weiß ich nicht, wo die wesentlichen Unterschiede zwischen den beiden Teilen liegen. Wenn ich richtig verstehe, kann ich mit beiden programmieren und debuggen und die zurzeit von mir verwendeten Controller kann ich ebenfalls mit beiden ansprechen. Somit fällt mir die Auswahl schwer. Könnte man den AVR Dragon im Vergleich mit dem JTAG ICE3 evtl. als "Einsteigerversion" bezeichnen oder wo liegen sonst die Vorteile des JTAG ICE3, der gut das Doppelte eines AVR Dragon kostet? Ich würde mich freuen, wenn jemand etwas Licht in mein Dunkel bringen könnte :-) Übrigens habe ich gerade noch ein Teil gefunden, das, wenn ich richtig verstehen die beiden anderen (Dragon und ICE3) ersetzen soll: Atmel-ICE. Wie sieht es damit aus? Vielen Dank für Eure Hilfe, Ralf
:
Bearbeitet durch User
Richtig, das aktuelle Atmel-ICE ist ein Ersatz für den Dragon, der sich sogar preislich lohnt. Wenn man es mit dem Dragon vergleicht, müsste man die “bare metal”-Version (nacktes PCB) als Vergleichsobjekt heranziehen, bei der keinerlei Kabel und Adapter sind, denn genau so kommt auch der Drache daher. (Leider gibt's für die Kabel und Adapter dann einen heftigen Preisaufschlag bei Atmel. Deren Preispolitik ist da nicht immer wirklich verständlich.) Da Einzige, was der Dragon im Vergleich dazu noch als Plus hat, ist die Möglichkeit der HV-Programmierung von AVRs. Dafür ist das Atmel-ICE in der Lage, auch die Atmel-ARMs zu programmieren und debuggen.
Hallo Jörg, Danke für die Information. HV-Programmierung ist für die vom STK500 unterstützten Devices ja mit diesem möglich. Bisher habe ich diese Möglichkeit aber noch nicht benötigt. Beste Grüße, Ralf
Hallo, Aufgrund der höheren Performance gehen Dowload und Debug mit dem Atmel-ICE deutlich zügiger. Wenn du dir den leisten kannst oder willst, dann lieber gleich den. mfg
DerDan schrieb: > Aufgrund der höheren Performance gehen Dowload und Debug mit dem > Atmel-ICE deutlich zügiger. Bliebe noch hervorzuheben dass JTAG ICE3 (=JTAG ICE MKIII) und Atmel-ICE zwei verschiedene Geräte sind, wobei ersteres wohl ausgelaufen ist, aber wegen (vermutlich) grossen Lagerbestands bei manchen Anbietern immer noch hochpreislich angeboten (und der Atmel-ICE dagegen zurückgehalten) wird.
Mahlzeit, anzumerken ist noch dass der Dragon recht empfindlich ist und gerne mal, in Abhänkigkeit der USB Verorgung, in Rauch aufgeht. MfG
Sauger schrieb: > Mahlzeit, > > anzumerken ist noch dass der Dragon recht empfindlich ist und gerne mal, > in Abhänkigkeit der USB Verorgung, in Rauch aufgeht. > > MfG Was wiederum zu den "urban legends" gehört und durch ständige Wiederholung auch nicht wahrer wird. mfg.
Thomas Eckmann schrieb: > Was wiederum zu den "urban legends" gehört Jein. Der TI-Schaltregler da drauf war ein bisschen an der Kante seiner Specs, und konnte schon mal eine Neigung zum Abrauchen entwickeln. Noch dazu war er eigentlich gar nicht so recht nötig: man hatte ihn nur vorgesehen, da man am USB mit minimal 4,3 V rechnen muss, aber die benutzten AVRs für die gewünschte Taktfrequenz wenigstens 4,5 V benötigen. Ganz und gar praktisch kommen a) meistens mehr als 4,3 V raus und funktionieren sie b) auch mit 4,3 V noch bei der gewünschten Frequenz … deshalb bestand die übliche „Reparatur“ dann auch darin, den Chip rauszusezieren und Ein- und Ausgang zu brücken. Da sich der TE aber ohnehin für das Atmel-ICE entschieden hat, ist das aber nun auch egal.
Jörg Wunsch schrieb: > Da sich der TE aber ohnehin für das Atmel-ICE entschieden hat So genau weiss man das nicht! Ralf G. schrieb: > Ich werde dann wohl den JTAG ICE ordern. Die "Kästchen" schauen übrigens gleich aus .....
Mitlesa schrieb: > So genau weiss man das nicht! Ja, ich hoffe ja auch, dass das nur ein Schreibfehler war. Wobei: ein JTAGICE3 mit der alten Firmware (PID 0x2110) ist schneller als dieser leidvolle HID-Wahnsinn bei der CMSIS-DAP-Firmware. Aber das dürfte nur wenige interessieren. ;-) (Insbesondere keine Atmel-Studio-Nutzer, denn das bügelt ja in jedem Falle die neue Firmware drüber.) > Die "Kästchen" schauen übrigens gleich aus ..... Bis auf die Farbe: metallisch silbern beim JTAGICE3, weiß/cremefarben beim Atmel-ICE. Die Platinen sind aber austauschbar, man kann sich also das neue PCB bestellen und damit sein altes JTAGICE3 „pimpen“, wenn man das unbedingt will.
Jörg Wunsch schrieb: > Die Platinen sind aber austauschbar, man kann sich > also das neue PCB bestellen und damit sein altes JTAGICE3 „pimpen“, > wenn man das unbedingt will. Naja, der JTAG-ICE3 hat einen Anschluss in der Mitte, der Atmel-ICE hat zwei Anschlüsse für AVR und ARM.
Ich korrigiere meine Beurteilung: Mitlesa schrieb: > Die "Kästchen" schauen übrigens gleich aus ..... Die Kästchen schauen sehr ähnlich aus sodass bei einem ersten Blick auf ein Bild eine Verwechslungsgefahr besteht ....
Angehängte Dateien:
-
jtagice3-vs-atmelice.jpg
33 KB
Rudolph schrieb: > Naja, der JTAG-ICE3 hat einen Anschluss in der Mitte, der Atmel-ICE hat > zwei Anschlüsse für AVR und ARM. Macht nix: der Rahmen um den Stecker ist beim 3er größer. Die passen wirklich als Austausch. Anbei mal ein Foto auf die entsprechende Seite beider Tools.
Egal welcher von beiden, die Steckverbinder im 1.27mm Pitch sind ein ständiger Quell des Ärgernis ..... Man muss nicht ein Tool (Werkzeug) so fragil machen dass es im rauhen Alltags-Einsatz bald versagt und die Fehler- quote durch schlechte Kontaktierung steigt. Es sei denn man möchte seinen Ruf gerne ruinieren und gerne dauernd neue Ersatzkabel verkaufen .....
Mitlesa schrieb: > Egal welcher von beiden, die Steckverbinder im 1.27mm Pitch > sind ein ständiger Quell des Ärgernis Für Cortex-ARM ist der mittlerweile genau so standardisiert. Und ganz ehrlich: abgesehen von den fragilen Adaptern (2,54 auf 1,27 mm), die Atmel seinerzeit beim Raven-Kit mitgeliefert hat und bei denen sie vermasselt haben, dass man die 1,27er Buchsen hätte auch hätte auf der Unterseite verlöten müssen, habe ich bislang noch keinen Ärger mit den kleinen Steckern gehabt. Elektronik wird seit Jahren immer kleiner, damit müssen wir einfach leben lernen. p.s.: Die Flachkabel vom JTAGICEmkII seinerzeit dagegen haben uns immer wieder mal Probleme bereitet, da sie an einer der beiden Kanten Leitungsbrüche aufweisen. Hatte Atmel ja dann auch reagiert und überall gleich ein zweites reingelegt, aber solche Probleme habe ich mit dem 1,27er Kram noch nicht erlebt.
:
Bearbeitet durch Moderator
Ärger mit dem Kabel hatte ich auch, ich hab mir deshalb den Atmel-ICE als Ersatz für den JTAGICE3 bestellt. Um dann zu merken, dass nur das Kabel beim "alten" kaputt war. naja ... mfg
Hallo zusammen, der Atmel-ICE ist heute angekommen. Endlich keine Debug-Ausgaben auf dem LCD mehr :-) Das Einzige, was ich etwas nervig finde, sind tatsächlich die Kabel und zwar wegen der Länge. Die ca. 10 cm finde ich etwas kurz. Da muss ich mir wohl noch etwas längere basteln... Beste Grüße, Ralf
Hallo zusammen, ist es eigentlich normal, dass das Debuggen teilweise so langsam abläuft oder habe ich da nur irgendwo etwas falsch eingestellt? Konkretes Problem: Der µC schickt über den USB Daten zum PC (112 Bytes um genau zu sein). Läuft mein µC normal, funktioniert das und ich kann sie am PC lesen. Läuft er im Debug-Mode, wartet der PC und wartet und wartet. Und wenn er nicht abgestürzt ist, wartet er immer noch... Gibt es vielleicht mit Timern bzw. Interrupts im Debug-Modus Probleme die ich noch nicht kenne oder etwas Besonderes zu beachten? Und wie kann ich verhindern, dass das Atmel Studio den µC vor jedem Start neu flasht, auch wenn nichts am Programm geändert wurde? Vielen Dank für Eure Hilfe! Beste Grüße, Ralf
Ralf G. schrieb: > Die ca. 10 cm finde ich etwas kurz. Da muss ich > mir wohl noch etwas längere basteln... Naja, sei mal vorsichtig, kann gut sein, dass das mit längeren Kabeln nicht mehr richtig geht. Vorteilhaft an den neuen ICEs ist ja ihre Kleinheit, es stört daher nicht so sehr, wenn sie an ihrem Kabel „irgendwie herumbaumeln“. Ralf G. schrieb: > Läuft er im Debug-Mode, wartet der PC und wartet und wartet. USB direkt im Controller implementiert? Da kann man ihn normalerweise nicht zwischendrin anhalten, denn dann ist er ganz schnell weg vom USB. USB ist hochgradig interaktiv, ein Gerät am Bus muss immer in der Lage sein, auf Anforderungen des Hosts zeitnah zu reagieren. Bei einer USB-Implementierung im Controller bedeutet das zwangsläufig, dass die Firmware stets lauffähig sein muss, was sich mit dem Debugmodus naturgemäß ausschließt. Ansonsten, wie arbeitest du beim Debuggen? Einzelschritte, nur einige wenige Breakpoints und sonst frei laufen lassen?
Hallo Jörg, das mit der Geschwindigkeit hat sich fürs Erste erledigt. Wie so oft, lag das Problem zwischen Tastatur und Stuhl :-) Ich verwende einen FT245R zur Anbindung an den USB. Der ist, wie ein anderer Baustein auch, über den externen Adress- und Datenbus (wie externer Speicher) des ATmega162 eingebunden. Mein Problem ist, dass ich die Funktionsweise des USB anscheinend immer noch nicht richtig verstanden habe. Dass er, obwohl seriell, mit Datenpaketen und nicht mit einzelnen Bytes arbeitet, weiß ich zwar, aber wie gehe ich damit um? Die Anzahl der Bytes, die ich jeweils übertragen muss, ist variabel und nicht immer bereits vor dem Beginn der Übertragung bekannt. Somit muss ich wohl doch ein eigenes Protokoll implementieren, um Anfang und Ende eines Blockes zu erkennen. Das hätte ich gerne vermieden, aber auf einen Timeout von u.U. mehreren Sekunden zu warten um festzustellen, dass keine Daten mehr kommen, macht keinen Sinn, weil ich damit alles blockiere und der Datendurchsatz gegen Null geht. Ich habe schon viele Informationen zum USB gelesen, aber irgenwie isst der Groschen bei mir noch nicht gefallen. Falls Du gute Informationsquellen weißt, bitte her damit :-) Beste Grüße, Ralf
Die FTDI-Chips haben einen Timeout von einigen Millisekunden. Alles, was in dieser Zeit ankommt und noch ins aktuelle Paket passt, wird als ein USB-Paket versendet. Die entsprechende Menge an Datenbytes sollte dann auch ein read()-Aufruf an dein OS „am Stück“ zurückgeben, wobei ich mich da bei Windows nicht recht auskenne. Ja, wenn das nicht genügt, muss man ein simples Protokoll um die eigenen Daten legen. STX-ETX ist typisch, wenn man ansonsten nur ASCII-Daten sendet. Ein vorangestelltes Längenbyte ist auch nicht unüblich, allerdings muss man dann irgendeine Möglichkeit der Resynchronisation haben, falls Sender und Empfänger mal wirklich „außer Tritt“ gekommen sind.
Hallo Jörg, ich werde wohl doch ein einfaches Protokoll implementieren müssen, allerdings auch für Binärdaten. Vor ein paar Monaten hatte ich schon damit begonnen, es dann aber wieder verworfen weil ich dachte, es sei doch nicht notwendig. Dafür, dass die Daten sicher ankommen, sorgt ja das USB-Protokoll schon. Die Längenangabe macht m.E. nur Sinn, wenn die Anzahl der Bytes bereits vor der Übertragung bekannt ist. Das ist bei mir aber nicht immer der Fall. Ein Timeout von ein paar Millisekunden ist kein Problem, so zeitkritisch ist das Ganze nicht. Es geht mir vor allem darum, das Ende der Übertragung eindeutig von einem Fehler zu unterscheiden. Wenn keine Daten mehr kommen weil keine mehr da sind, muss ich das schnell wissen, um die Verarbeitung nicht zu blockieren. Wenn aber aufgrund eines Fehlers keine Daten kommen, darf es auch etwas länger dauern. Die längere Wartezeit deutet dann schon darauf hin, dass etwas nicht stimmt ;-) Beste Grüße, Ralf
Thread beobachten
Seitenaufteilung abschaltenBitte 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.