Hallo Foren-Gemeinde, nach sehr sehr langer Zeit habe ich mal wieder mein altes OLIMEX AVR-P28-8MHz (https://www.olimex.com/Products/AVR/Proto/AVR-P28-8MHz/) ausgepackt und den Start mit Microchip Studio 7 gewagt. Leider bekomme ich den Debugging-Modus nicht zu laufen, sodass ich immer im Prinzip im "Blindflug" unterwegs bin, weil ich mir keine Register oder Variablen ansehen kann. Mein aktuelles Setup: - OLIMEX AVR-P28-8MHz - AVR MKII in-circuit programmer (siehe Anhang) - Laptop zum Programmieren nur mit USB-Schnittstelle Nach meiner Recherche benötige ich dazu den "debugWIRE", den ich leider nicht finde bzw. auswählen kann. Kann ich mit der Hardware überhaupt den Debug-Modus ausführen? Wenn nicht, welchen Programmer würdet Ihr für das OLIMEX empfehlen? Danke für die Unterstützung. Gruß Wolle
Das alte Hündchen ATMega8... Soweit ich mich erinnere hat der keinerlei debugmöglichkeiten.
Kay M. schrieb: > Kann ich mit der Hardware überhaupt den Debug-Modus ausführen? Weder kann man den ATMega8 debuggen, noch erlaubt es ein "Programmer AVR MKII" irgendeinen Controller zu debuggen. Im Manual (das du selbst hier bereitgestellt hast) ist von Debuggen auch kein Wort zu finden. Nur der Hinweis dass er so zu behandeln wäre wie ein AVR ISP MKII, und das ist auch kein Debugger.
Hallo, vielen Dank für die schnelle Rückmeldung. Stimmt, leider kann der Atmega8 das debugwire gar nicht ... Diesen könnte ich durch den pin-kompatiblen Atmega328 (2,50€ bei Reichelt) ersetzen, der die Funktion unterstützt. Jetzt ist noch der Programmer in Kombination mit den Olimex-Board (P28) die Baustelle. Das Board hat eine RS232 und ICSP-Schnittstelle. Ist das debugging überhaupt mit dem Board möglich und welchen Programmer bräuchte ich dazu? Könnt ihr was empfehlen? Danke. Gruß
Kay M. schrieb: > Stimmt, leider kann der Atmega8 das debugwire gar nicht ... Das können viele AVR8 nicht. Aber es gibt auch andere Debug-Schnittstellen. Das spezielle Problem beim AVR8 ist halt nur: er unterstützt KEINE davon. > Jetzt ist noch der Programmer in Kombination mit den Olimex-Board (P28) > die Baustelle. > Das Board hat eine RS232 und ICSP-Schnittstelle. > Ist das debugging überhaupt mit dem Board möglich Nein, natürlich nicht. Das einzige, was das "kann", ist halt ISP. Darüber konnte man noch nie Debuggen. Und ohne Hilfe eines zusätzlichen ISP-Programmers kann man mit dem Board ja noch nicht einmal programmieren, denn die Unterstützung für ISP beschränkt sich allein darauf, die entsprechenden Pins auf eine ISP-Buchse mit Atmel-Standard-Pinout zu führen. > Könnt ihr was empfehlen? Überantworte diese Board dem nächsten Wertstoffhof. Das ist heute praktisch zu fast nix mehr nütze.
Kay M. schrieb: > Ist das debugging überhaupt mit dem Board möglich und welchen Programmer > bräuchte ich dazu? Könnt ihr was empfehlen? Will man schnell in die Gänge kommen und allerlei AVRs debuggen empfiehlt sich ein Arduino Mega2560 und ein JTAG ICE MKII oder ein Atmel-ICE. Ein Mega2560 hat - das wissen viele nicht - ein JTAG-Interface und lässt sich damit debuggen wie "die Grossen". Der Mega2560 ist zudem weitgehend Register-kompatibel zu kleineren AVRs und bietet damit die Möglichkeit Programme zu entwickeln und debuggen um sie später auf den kleineren AVRs laufen lassen zu können. Bisschen Kleinarbeit ist noch nötig um vier JTAG Leitungen an den Debugger zu bringen. Beitrag "Re: TCP Server ATmega328" Und wenn es wirklich mal sein muss kann man mit dem Arduino 2560 und der Arduino IDE sogar einen echten Sketch laufen lassen.
Kay M. schrieb: > Ist das debugging überhaupt mit dem Board möglich und welchen Programmer > bräuchte ich dazu? DebugWIRE an sich sollte machbar sein. Es ist auf dem Board ein 10-kΩ-Pullup drauf an /RESET, das sollte OK sein. Ansonsten klemmt ein ZM33064 parallel dran, der hat hoffentlich nicht so viel Ausgangskapazität, dass er das debugWIRE stört. Der parallele Kondensator ist laut dem in deinem PDF enthaltenen Schaltplan nicht bestückt – der würde ein debugWIRE nachhaltig verhindern. Atmel JTAGICEmkII, AVR Dragon, Atmel JTAGICE3 und AtmelICE sind die, die das debugWIRE-Protokoll beherrschen. Dass du einen ATmega328 brauchst, hast du ja schon bemerkt. ATmega48, 88 oder 168 würden auch gehen und sind pinkompatibel, aber zum Debuggen ist es allemal sinnvoll, etwas Reserve bei Flash und RAM zu haben.
Hi Nun, Fehlersuche in einem laufenden Programm zu suchen ist immer etwas problematisch, aber wenn der Controller über einen USART verfügt, kann man auch eine Zusammenstellung von Daten über die serielle Schnittstelle an einen PC senden. Ist zwar nicht das gleiche wie JTAG, aber sehr hilfreich. Während eine LED lediglich eingesetzt werden kann, zu prüfen, ob bestimmte Programmteile auch durchlaufen werden, ist es über die serielle Verbindung möglich, Werte auf plausiblen Inhalt zu prüfen. Ich hab mir dafür, allerdings für Assemblerprogramme, eine Anwendung in VB geschrieben, die mir Variableninhalte zur Laufzeit liefert. Du kannst es sicherlich für deine Bedürfnisse anpassen. Das Programm findest du mit Aufbaubeschreibung und Quellcode bei MakerConnect in der Rubrik FAQ in dem Buch "PC und µC-Programmieren in VB und Assembler". Falls es dich interessiert, es ist kostenlos verfügbar. Gruß oldmaax
Martin V. schrieb: > Nun, Fehlersuche in einem laufenden Programm zu suchen ist immer etwas > problematisch, aber wenn der Controller über einen USART verfügt, kann > man auch eine Zusammenstellung von Daten über die serielle Schnittstelle > an einen PC senden. Oder man nimmt einen Controller der nicht alt wie Steinkohle ist und kann vernünftig debuggen. Am besten gleich einen mit UPDI, das spart auch Verkabelung.
Hi Cyblord -. schrieb: > Oder man nimmt einen Controller der nicht alt wie Steinkohle ist und > kann vernünftig debuggen. Am besten gleich einen mit UPDI, das spart > auch Verkabelung. Magst ja Recht haben, doch wennn halt noch ein paar von diesen Uraltdingern im Bastlerlager rumliegen, die für die beabsichtigte Anwendung völlig ausreichen,warum sich dann in Unkosten stürzen? Nebenbei, es ist doch letztlich egal, womit man anfängt. Der Punkt ist doch, wer sich mit seinen Käfern beschäftigt, will nicht jedesmal, wenn jemand sagt, dein Kram ist veraltet, loslaufen und gleich das Modernste auf dem Markt kaufen. Gruß oldmax
Und es gibt auch genügend Trivialanwendungen für kleine MCs, da braucht man gar kein on-chip-debugging.
Die folgenden AVR haben alle DebugWire und sind im DIP Format erhältlich: 8 Pins: ATtiny 25, 45, 85 https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet.pdf 14 Pins: ATtiny 24, 44, 84 https://ww1.microchip.com/downloads/en/DeviceDoc/doc8006.pdf 20 Pins: ATtiny 261, 461, 861 https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2588-8-bit-AVR-Microcontrollers-tinyAVR-ATtiny261-ATtiny461-ATtiny861_Datasheet.pdf 28 Pins: ATmega 48, 88, 168, 328 https://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061B.pdf Und diese haben JTAG und sind im DIP Format erhältlich: 40 Pins: ATmega 164, 324, 644, 1284 https://ww1.microchip.com/downloads/en/DeviceDoc/ATmega164A_PA-324A_PA-644A_PA-1284_P_Data-Sheet-40002070B.pdf
Stefan ⛄ F. schrieb: > Die folgenden AVR haben alle DebugWire und sind im DIP Format > erhältlich: Naja, er hat ein Board mit einer 28poligen Fassung, von daher braucht er die mit der 8 hinten.
Hallo, vielen Dank für die zahlreichen Antworten und Informationen. Das meine aktuelle Hardware das debugWIRE nicht unterstützt, habe ich verstanden. Gerade wenn man mit dem Programmieren anfängt und doch einige Fehler im Code einbaut und suchen muss, dann ist diese Funktion aus meiner Sicht unerlässlich, denn "Blindflug" kann nach einiger Zeit auch demotivierend wirken. Die Programmer für das debugWIRE (Atmel JTAGICEmkII, AVR Dragon, Atmel JTAGICE3, AtmelICE und co.) sind ja nicht gerade billig. Klar, der Atmega8 und das OLIMEX-Board sind "Steinkohle" aber das ist kein Grund die Hardware nicht mehr zu verwenden oder gar zu entsorgen. Ist meine Zusammenfassung so richtig, damit ich debugWIRE verwenden kann? - tausch des Atmega8 gegen Atmega328 (Quarztausch auf dem Board ist erstmal nicht nötig, sollte auch mit 8MHz laufen) - neuen/gebrauchten Programmer kaufen z.B. AtmelICE - OLIMEX-Board kann so verwendet werden Danke. Gruß Kay
Kay M. schrieb: > Gerade wenn man mit dem Programmieren anfängt und doch einige Fehler im > Code einbaut und suchen muss, Frag mal die Leute, die vor 30 Jahren MCs programmiert haben. Es gab zwar auch für den 8031/51 ICE, aber die waren für Privatanwender absolut unerschwinglich. Und aufs Eprom löschen musste man 20min warten. Folge: man dachte gründlicher nach und arbeitete sorgfältiger, weil man es eben nicht mal so ändern konnte.
H.Joachim S. schrieb: > Frag mal die Leute, die vor 30 Jahren MCs programmiert haben. Es gab > zwar auch für den 8031/51 ICE, aber die waren für Privatanwender absolut > unerschwinglich. Und aufs Eprom löschen musste man 20min warten. Folge: > man dachte gründlicher nach und arbeitete sorgfältiger, weil man es eben > nicht mal so ändern konnte. Ok Boomer
H.Joachim S. schrieb: > Und aufs Eprom löschen musste man 20min warten. Daher habe ich mir dann auch einen 6516 mit einer Flachbatterie versehen und als primitiven Emulator für den 2716 benutzt. ;-) Da ich meinen eigenen Eprommer verwendet habe, war es trivial, diesem noch den 6516 beizubiegen. Allerdings kippte beim Transport vom Eprommer zum Zielsystem gelegentlich schon auch mal ein Bit. ;-)
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Allerdings kippte beim Transport vom Eprommer zum Zielsystem > gelegentlich schon auch mal ein Bit. ;-) Wahrscheinlich hattest du die Abblock-Kondensatoren vergessen ;-) Kann schon mal passieren, so als junger Hupfer....
Hallo, Kay M. schrieb: > Gerade wenn man mit dem Programmieren anfängt und doch einige Fehler im > Code einbaut und suchen muss, dann ist diese Funktion aus meiner Sicht > unerlässlich, denn "Blindflug" kann nach einiger Zeit auch demotivierend > wirken. Sehe ich völlig anders. Gerade als Anfänger hat man mit den angesprochenen Möglichkeiten eine zusätzliche Ebene, die bei falscher oder missverständlicher Verwendung zu zusätzlicher Verwirrung beiträgt. Außerdem kommt man auch mit "Primitiv_Debugging" wie eine Led blinken lassen oder Ausgabe per serieller Schnittstelle erstaunlich weit. rhf
jo mei schrieb: > Wahrscheinlich hattest du die Abblock-Kondensatoren vergessen ;-) Natürlich war da ein Kondensator drüber, aber der hilft nichts gegen floatende Pins (Daten-, Adress- und Steuerbus).
Auch und gerade als Anfänger macht es Sinn sich direkt auch mit modernen Tools und Debugging auseinanderzusetzen. Somit wird man automatisch auch im Umgang damit sicherer. Jeder Fachmann soll und muss sein Werkzeug beherrschen. Reiner Skill ohne das richtige Werkzeug führt zu keinem guten Ergebnis. Lasse dich somit nicht von den Foren-Opas, welche sich mit Debugging erkennbar schwer tun weil sie es halt früher nicht hatten, verunsichern. Im prof. Umfeld wird nichts anderes gemacht. Debugging gehört zum Standard-Rüstzeug jeder SW Entwicklung. Dieses auszusparen hat keinen Vorteil.
Cyblord -. schrieb: > Debugging gehört zum Standard-Rüstzeug jeder SW Entwicklung. Wobei in-circuit-Debugging auch seine Grenzen hat (gerade bei Echtzeit), insofern sollte man das sehr wohl beherrschen, aber genauso gut andere Methoden. Die beschriebene LED kann manchmal hilfreich sein, aber man kann sie auch sehr schnell blinken lassen :) und dann die Signale eines GPIO auf einem Logikanalysator aufzeichnen um auf diese Weise zu ermitteln, an welchen Stellen die Software denn schon mal so "herum gerannt" ist – außerdem kann man bei dieser Gelegenheit auch gleich das Zeitverhalten analysieren.
Hallo, Jörg W. schrieb: > Daher habe ich mir dann auch einen 6516 mit einer Flachbatterie versehen > und als primitiven Emulator für den 2716 benutzt. ;-) Da ich meinen > eigenen Eprommer verwendet habe, war es trivial, diesem noch den 6516 > beizubiegen. Witzig, so was hatte ich mir auch gebaut. Nachher hatte ich dann einen "echten" EPROM-Simulator nach einer Elektor-Bauanleitung, der mittels Parallel-Schnittstelle des Entwicklungsrechner, einem Atari-St, "geladen" wurde. rhf
Jörg W. schrieb: > Wobei in-circuit-Debugging auch seine Grenzen hat (gerade bei Echtzeit), > insofern sollte man das sehr wohl beherrschen, aber genauso gut andere > Methoden. Die beschriebene LED kann manchmal hilfreich sein, aber man > kann sie auch sehr schnell blinken lassen :) und dann die Signale eines > GPIO auf einem Logikanalysator aufzeichnen um auf diese Weise zu > ermitteln, an welchen Stellen die Software denn schon mal so "herum > gerannt" ist – außerdem kann man bei dieser Gelegenheit auch gleich das > Zeitverhalten analysieren. Ich will ja andere Methoden gar nicht ausschließen. Manchmal will man einen GPIO verwenden um am Oszi eine Zeit zu messen. Das ist auch ok. Wobei es dafür dann auch wieder Trace fähige Debugger gibt, und den richtigen Controller vorausgesetzt (und genügend Kleingeld), kann man wirklich das allermeiste, auch das wirklich Zeitkritische, am OCD ansehen. Das ist aber natürlich nichts fürs Hobbylabor. Aber normales OCD ist eben heute billig zu haben, auch und sogar mit Task Awareness für gewisse OS usw., also sollte man es auch nutzen und nicht ständig Anfängern davon abraten.
:
Bearbeitet durch User
Hi Cyblord -. schrieb: > also sollte man es auch nutzen und > nicht ständig Anfängern davon abraten. Also, ich bin ja schon etwas müde auf den Augen, aber abgeraten von modernem Zeugs hat doch hier niemand. Ist doch klar, das man vorhandenes Werkzeug nutzt, aber wenn denn der Hammer so teuer oder nicht zur Hand ist, genügt auch ein Bügeleisen, um Nägel in die Wand zu kloppen. Wer es für erforderlich hält, dann doch erst mal zum Baumarkt zu fahren und sich mit geeignetem Werkzeug ausstattet, dazu hat er ja schon genügend Tipps erhalten und die müssen nicht dauernd wiederholt werden, der wird es früher oder später tun. Gruß oldmax
Martin V. schrieb: > Also, ich bin ja schon etwas müde auf den Augen, aber abgeraten von > modernem Zeugs hat doch hier niemand. Das würde ich eher als Betriebsblind bezeichnen.
Kay M. schrieb: > Nach meiner Recherche benötige ich dazu den "debugWIRE", den ich leider > nicht finde bzw. auswählen kann. 1. du solltest statt Mega8 pinkompatible Mega88 nehmen. 2. du solltest statt AVR MKII in-circuit programmer AVR JTAGICE XPII nehmen (es gibt noch in China). Dann hast du debugWIRE und für größeren Mega auch JTAG.
Erwarte nicht zu viel vom DebugWire. Ersten ist er nervig träge, zweitens muss für jeden Einzelschritt ein Schreibzugriff auf den Flash gemacht werden -> Verschleiß, drittens kann man noch lange nicht jedes Programm einfach so anhalten ohne dass die Maschine dabei ausfällt. Ein Self-Balancing Roboter würde zum Beispiel augenblicklich umkippen. Wenn die das Debuggen so wichtig ist, dann erwäge einen Umstieg auf STM32. Da bekommst du den Debugger (ST-Link) fast geschenkt. Und er ist viel schneller.
>zweitens muss für jeden Einzelschritt ein Schreibzugriff auf den Flash >gemacht werden -> Verschleiß, Aus Atmel-ICE_UserGuide.pdf: The debugWIRE OCD is drastically scaled down when compared to the Atmel megaAVR (JTAG) OCD. This means that it does not have any program counter breakpoint comparators available to the user for debugging purposes. One such comparator does exist for purposes of run-to-cursor and single-stepping operations, but additional user breakpoints are not supported in hardware.
neuer PIC Freund schrieb im Beitrag #6671714: >> muss für jeden Einzelschritt ein Schreibzugriff auf den >> Flash gemacht werden -> Verschleiß, > One such comparator does exist for purposes of > run-to-cursor and single-stepping operations Hmm, vielleicht kommt es auf den verwendeten Debugger an. Ich habe nur mit dem Dragon Erfahrung.
Stefan ⛄ F. schrieb: > Ich habe nur mit dem Dragon Erfahrung. Der war wohl insgesamt vergleichsweise lahm. Beim JTAGICEmkII hatte man zwei getrennte Controller für Target und Interface, beim Dragon musste gespart werden, was man nur sparen konnte, da wurden Kompromisse gemacht. Wohl um die Hintergründe der debugWIRE-Implementierung wissend, war ich damals erstaunt, dass es doch noch relativ schnell ging. Insgesamt waren JTAGICEmkII und Dragon mit AVaRICE relativ lahm, weil Atmel damals noch so ein hausbackenes Protokoll fürs Debuggen unterstützt hat, bei dem ein Gutteil der Debuglogik in das ICE ausgelagert worden ist, was dadurch vergleichsweise teuer wurde (mit großem RAM für tag memory), während man einen primitiven, selbst gestrickten Debugger anwenden konnte. Ein allgemein gehaltener Debugger wie GDB (oder später der vom Visual Studio) konnte dagegen mit alldem Krams im ICE nichts richtig anfangen, der hätte stattdessen von einem möglichst schnellen Kommandointerface profitiert, aber das hatte das JTAGICEmkII (und der Dragon) nun gerade nicht. Mit dem JTAGICE3 und dann AtmelICE hat sich das geändert. Man hatte ja nun hostseitig auf einem generischen Debugger aufgesetzt, brauchte keine Logik mehr groß im ICE, aber ein schnelles Interface. Die nackten PCBs vom AtmelICE waren ja anfangs sehr preiswert (< EUR 40), billiger als der Dragon seinerzeit. Leider ist das Zeug nach der Microchip-Übernahme im Preis mehr als doppelt so teuer geworden.
Der Dragon ist bei mir mehr oder weniger ungenutzt verschimmelt, jetzt im Halbleiterhimmel. Taugte von Hause aus nicht viel und viel zu empfindlich. War seine ca. 50€ nicht wert.
Jörg W. schrieb: > Mit dem JTAGICE3 und dann AtmelICE hat sich das geändert. Man hatte ja > nun hostseitig auf einem generischen Debugger aufgesetzt, brauchte keine > Logik mehr groß im ICE, aber ein schnelles Interface. Die nackten PCBs > vom AtmelICE waren ja anfangs sehr preiswert (< EUR 40), billiger als > der Dragon seinerzeit. Leider ist das Zeug nach der Microchip-Übernahme > im Preis mehr als doppelt so teuer geworden. Nö, gibt es an bestimmten Stellen immer noch für weniger als 40€. Wenn man Google benutzen kann, findet man sie, wenn nicht, wäre es sowieso Perlen vor die Säue. Deswegen absichtlich kein konkreter Link, um ausdrücklich diejenigen mit einer gewissen Mindest-Eigen-Intelligenz zu bevorzugen...
c-hater schrieb: > Nö, gibt es an bestimmten Stellen immer noch für weniger als 40€. Real kaufbar, oder nur auf der Website angepriesen? (Nicht, dass ich eins brauchen würde, bin ausreichend versorgt.)
Jörg W. schrieb: > Mit dem JTAGICE3 und dann AtmelICE hat sich das geändert. Man hatte ja > nun hostseitig auf einem generischen Debugger aufgesetzt, brauchte keine > Logik mehr groß im ICE, aber ein schnelles Interface. Die nackten PCBs > vom AtmelICE waren ja anfangs sehr preiswert (< EUR 40), billiger als > der Dragon seinerzeit. Ja und Preiswert ist halt relativ. Warum kann ich für 20 Euro im Original und für 6 Euro als Clone jeden STM32 debuggen aber für AVRs muss man einen Termin mit seinem Kreditberater machen? Ich habe auch einen JTAGICE3 weil ich immmer noch einiges auf AVR machen muss, aber lieber würde ich nicht.
Cyblord -. schrieb: > Warum kann ich für 20 Euro im > Original und für 6 Euro als Clone jeden STM32 debuggen aber für AVRs > muss man einen Termin mit seinem Kreditberater machen? Weil: Als das von Atmel eingeführt wurde war das eine ganz besonders tolle Sache. Vorher gab es keine derartigen Hardware Debugger. Man musste Hardware-Simulatoren benutzen, die so viel kosteten, wie ein Kleinwagen. Im Vergleich dazu war der Preis des Atmel ICE quasi nichts. Als dann die ARM Controller kamen, war das Debugging nichts besonderes mehr, eher eine Selbstverständlichkeit. Kaum jemand wäre auf ARM umgestiegen, wenn es kein hardware Debugging gegeben hätte oder wenn es noch so teuer wie bei Atmel gewesen wäre. Wenn du mal Fotos von einem ST-Link mit einem Atmel Dragon vergleichst, erklärt das auch einen Teil des Preisunterschiedes. Der Dragon ist um ein vielfaches aufwändiger. Ist halt Technik von vor 20 Jahren.
Cyblord -. schrieb: > Warum kann ich für 20 Euro im Original und für 6 Euro als Clone jeden > STM32 debuggen aber für AVRs muss man einen Termin mit seinem > Kreditberater machen? Weil Atmel damals der Meinung war, eine Debugschnittstelle müsse irgendwie ein Firmengeheimnis sein, sodass sie sie letztlich nur selbst implementieren können. Bei Cortex-M (nicht nur STM32, auch denen von Atmel nun Microchip) ist das anders, da ist die Debug-Schnittstelle offen, und du kannst einen preiswerten FT2232 zum Debuggen benutzen. Auch die auf den diversen Xplained*-Boards enthaltenen EDBG-Chips sind so teuer nicht, aber den alten Exoten "debugWIRE" hat denen halt keiner mehr beigebogen (denke ich zumindest – hab's aber zugegebenermaßen noch nie ausprobiert).
Stefan ⛄ F. schrieb: > Wenn du mal Fotos von einem ST-Link mit einem Atmel Dragon vergleichst, > erklärt das auch einen Teil des Preisunterschiedes. Der Dragon ist um > ein vielfaches aufwändiger. Ist halt Technik von vor 20 Jahren. Ich hatte den Dragon früher selbst. Ja da ist einiges drauf, ist aber trotzdem ein räudiges Teil. Habe den nie wirklich benutzt aber letztens wirklich gut auf eBay verkauft. Sehr preisstabil das muss man ihm lassen. JTAGICE3 ist hingegen auch gut zu gebrauchen und UPDI läuft damit angenehm schnell. Größter Nachteil, neben dem Preis, ist die schlechte Integration in 3rd Party Entwicklungsumgebungen. Einfach mal Eclipse + OpenOCD + GDB wie man das mit ARM Tools macht ist da nicht.
Musst halt AVaRICE statt OpenOCD nehmen, aber wirklich zufrieden war ich mit der Integration des ganzen EDBG/CMSISDAP-Rassels da nie. Das hat OpenOCD besser hin bekommen, keine Frage, aber die unterstützen halt die AVR-Protokolle nicht. Die ursprüngliche (nicht-CMSISDAP) Firmware des JTAGICE3 lief mit AVaRICE gar nicht so schlecht. Da hatten sie halt noch ihr komplett selbst gestricktes USB-Protokoll drauf. Wenn du das Teil aber einmal am Atmel Studio dann dran hattest, bekam es irgendwann eine CMSISDAP-Firmware (mit neuer PID), deren Unterstützung in AVaRICE ist nicht so gut. Dafür ist AVaRICE zu verbastelt, habe keinen Nerv, das noch zu ändern.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Real kaufbar, oder nur auf der Website angepriesen? Jepp, real kaufbar. Zumindest vor ca. 4 Wochen noch, da hat ein Bekannter nämlich eins gekauft. Weiß ich, weil ich ihm bei der Inbetriebnahme geholfen habe. Er hatte noch keine Erfahrung mit dem 7er Studio, hat bisher immer nur 4er Studio und und ein ISP-Dongle von Olimex benutzt.
Jörg W. schrieb: > Dafür ist AVaRICE zu verbastelt, habe keinen Nerv, das > noch zu ändern. So gehts mir mit dem Kram halt auch. Das hört ja bei Debugging nicht auf. Schon allein neuere AVR (ich nutze aktuell einen AVR128DA für ein Projekt) Toolchainmäßig extern ans laufen zu bekommen ist müßig. Die Pfadeinstellungen um die zusätzlichen Devicepacks da ordentlich zu nutzen sind unschön. Aber ich habe es hin bekommen. Aber dann kommt die Debugging Sache noch oben drauf. Da nehme ich lieber gleich das Studio. Pest oder Cholera.
c-hater schrieb: >> Real kaufbar, oder nur auf der Website angepriesen? > > Jepp, real kaufbar. Zumindest vor ca. 4 Wochen noch Cool. Hätte ich angesichts der Preisinflation bei diesen Dingern während der letzten Jahre nicht erwartet.
Jörg W. schrieb: > Hätte ich angesichts der Preisinflation bei diesen Dingern während der > letzten Jahre nicht erwartet. Nun, liegt vermutlich daran, dass nicht jeder Betreiber eines kleinen Webshop die Kapazitäten hat, umfassend den Markt für jedes der Produkte zu beobachten, die er anbietet. Aber auch bei größeren Läden kommt sowas immer mal wieder vor, obwohl die natürlich ihre Leute für sowas haben. Aber dafür auch viel mehr Artikel, als so ein kleiner Shop.
Microchip hat anscheinend etwas neues im Angebot für's debuggen: den MPLAB SNAP. https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/PG164100 Wie wäre es mit einer Bewertung von den Profis? Wie weit kommt man mit dem Teil?
Der müde Joe schrieb: > Wie wäre es mit einer Bewertung von den Profis? Finde mal die Liste der unterstützten Targets und welche Funktionen je nach Target unterstützt werden. Katze im Sack ist nicht so mein Ding. Auf jeden Fall ist das Ding inkompatibel zu AVR Studio, Atmel Studio und der Arduino IDE.
Der müde Joe schrieb: > Microchip hat anscheinend etwas neues im Angebot für's debuggen: den > MPLAB SNAP. > > https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/PG164100 > > Wie wäre es mit einer Bewertung von den Profis? Wie weit kommt man mit > dem Teil? Das ist die Sparversion des PICKIT4 von Microchip. Dafür gibts ein Erratum für AVRs: http://ww1.microchip.com/downloads/en/DeviceDoc/ETN36_MPLAB%20Snap%20AVR%20Interface%20Modification.pdf Ich meine, das PICKIT4 wäre davon nicht betroffen. Für PICs hätte ich jetzt kein Problem, einen SNAP einzusetzen, aber bei was anderem würde ich doch eher zum PICKIT4 greifen. Die PICKITs funktionieren soweit, keine Probleme - aber eben nur mit MPLABX und nicht mit dem AVR Ökosystem. MPLABX kann inzwischen auch viele AVRs, das sollte also kein Problem sein, und das PICKIT4 kann alles, was es bei Microchip aktuell gibt: ICSP, ISP, PDI, TPI, UPDI, JTAG, für PIC, AVR, ARM, MIPS. Ich denke, das ist die Lösung, auf die es langfristig hinauslaufen wird. Der EDBG-Chip im Atmel-ICE ist ein AVR32, und AVR32 ist seit Jahren tot, und ich frage mich, wie lange sie dieses letzte Überbleibsel noch produzieren werden. fchk
Bei soviel Kuddelmuddel bei Debuggern von Microchip/Atmel kann es auf Dauer nur in die Hose gehen. Eine klare, offene und mächtige Unterstützung wäre gefordert. Bei einem Debugger-Preis von wenigen Euros für einen STM Controller braucht man eigentlich nicht lang überlegen ....
>Microchip hat anscheinend etwas neues im Angebot für's debuggen: den >MPLAB SNAP. Meiner wird bald 3 Jahre alt. >Wie weit kommt man mit dem Teil? Mein derzeitiger Std-Debugger für die AVR. Kostete 12€; da hat mein Kreditberater grünes Licht gegeben ;-). Eingesetzt für Mega88, Mega328, Mega32, Tiny1614. Je älter die Firmware, desto mehr Probleme. Läuft derzeit so rund, auf dass das ICE immer mehr verstaubt.
Frank K. schrieb: > Der EDBG-Chip im Atmel-ICE ist ein AVR32, und AVR32 ist seit Jahren tot, > und ich frage mich, wie lange sie dieses letzte Überbleibsel noch > produzieren werden. Solange sie ihn verkaufen können, ist doch logisch.
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.