Hallo,
ich habe vor Jahren in einem Praktikum eine Mikrocontrollerschaltung mit
ATmega32 aufgebaut. Zum Debuggen wurde die JTAG-Schnittstelle und ein
Atmel JTAGICE verwendet.
Nun würde ich gerne mehr mit Elektronik machen, nicht nur, aber evtl.
auch mit dem ATmega32.
Welcher Debugger ist dafür zu empfehlen? Ich habe recherchiert, finde
das Angebot aber verwirrend. Nur zum Herumprobieren sind die
Originalgeräte von Atmel mit dreistelligen Preisen etwas zu teuer.
Ich hätte bereits einen geschenkten AVR Dragon, den mir aber jemand
unbedingt abkaufen möchte. Und er soll ja etwas anfällig sein und
wahrscheinlich reicht mir ein günstigeres Gerät - es sollte halt neben
programmieren auch debuggen können.
Wären die folgenden Debugger gleichwertig, und welchen könnte man
empfehlen?
1) "AVR-JTAG USB" von Olimex, u.a. bei
https://elmicro.com/de/avrjtag.html
2) "AVR-ISP-MK2", u.a. bei
https://www.digikey.de/product-detail/de/olimex-ltd/AVR-ISP-MK2/1188-1008-ND/3471448
3) "USP-mkII (AVR Programmer)"
https://www.ehajo.de/boards/151/usp-mkii-avr-programmer
4) evtl. ein gebrauchter Original ICE von Atmel?
5) ein "Atmel ICE"-Klon von ebay zur unter 10 Euro
Mein erster Gedanke, wäre Nummer 4 zu nehmen. Oder habt ihr andere
Tipps?
Frage dich bitte erst, für was Du einen Debugger für ATmega* benötigst.
Habe ich selbst nach 15 Jahren nie benötigt.
Die Programmlogik steckt im Programm und das muss man verstehen.
(Test-)Ausgaben können heute serial über einen TTL-USB Wandler an jeden
PC übermittelt werden.
Oder man verwendet nur eine LED zum Signalisieren..
Karl M. schrieb:> Frage dich bitte erst, für was Du einen Debugger für ATmega*> benötigst.>> Habe ich selbst nach 15 Jahren nie benötigt.>> Die Programmlogik steckt im Programm und das muss man verstehen.> (Test-)Ausgaben können heute serial über einen TTL-USB Wandler an jeden> PC übermittelt werden.> Oder man verwendet nur eine LED zum Signalisieren..
So mache ich es meistens auch. Seit Jahren keinen Debugger mehr benutzt.
Auf den Platinen, die später verkauft werden, ist kein Jtag-Ausgang
(o.ä.) mehr drauf. Also muss ein Uart mit printf reichen.
Man sollte allerdings schon C (oder seine benutzte Programmiersprache)
beherrschen, und nicht versuchen, erst auf dem Controller die Sprache
kennenzulernen.
Softwareentwicklung ist nicht das Thema, da bin ich fit.
Das mit der seriellen Schnittstelle find ich auch eine gute Option.
Aber die Alternative, auch Breakpoints setzen zu können statt (zum
Beispiel in dem alten Projekt) erst mal einen Uart in Betrieb zu nehmen,
find ich trotzdem nicht schlecht.
Mittlerweile gibt es von Microchip (wozu Atmel gehört) zwei sehr
günstige Optionen:
Microchip SNAP ca 25€ (Programmer/Debugger für die meisten neueren AVR
und PIC Mikrocontroller, reine Platine)
Microchip PicKit 4 ca 50€ (Wie SNAP aber in einem Gehäuse, mit
zahlreichen Zusatzfunktionen wie Programming on the Go, HVSP und
einstellbare Target Versorgung)
Man kann Dunkelheit natürlich zum Standard erklären und
sich an einem LED-Kerzenlicht erfreuen.
@TO: Such dir Controller die dir da keine Steine in den
Weg legen. Es gibt wirklich genug davon.
Bei den 8-Bittern z.B. die STM-8.
@Gabriel: Danke für den Tipp. Dass es da jetzt Geräte unter der Marke
Microchip gibt, wusste ich noch nicht.
@...: Danke, ggf. würde ich auch STM32 oder PIC in Betracht ziehen. Aber
hier geht es mir vor allem um das alte Projekt.
Spricht den generell etwas gegen einen günstigen Klon für den Anfang?
Oder sollte ich den Dragon dringend behalten?
New schrieb:> Spricht den generell etwas gegen einen günstigen Klon für den Anfang?
Hängt daVON ab, von woher er stammt und ob er die passende Firmware hat.
Hier ein Link zu einem Projekt dem USBasp:
https://www.fischl.de/usbasp/
Clone aus Übersee haben häufiger nur alte Firmware installiert, evtl.
auch keine Möglichkeit 5V und 3,3V AVR µC Chip zu programmieren.
Der USBasp ist anscheinend auch nur ein Debugger.
In dem bestehenden Projekt ist der JTAG-Zugang bereits herausgeführt.
Was mich vorrangig interessiert, das ist, möglichst günstig diesen
ATmega32 zu flashen UND zu debuggen.
Neue Projekte sind erst mal nicht der Fokus...
Karl M. schrieb:> Frage dich bitte erst, für was Du einen Debugger für ATmega* benötigst.>> Habe ich selbst nach 15 Jahren nie benötigt.>> Die Programmlogik steckt im Programm und das muss man verstehen.> (Test-)Ausgaben können heute serial über einen TTL-USB Wandler an jeden> PC übermittelt werden.> Oder man verwendet nur eine LED zum Signalisieren..
Das sehe ich ganz genau so. Wenn Du in C-Programmierung fit bist, ist
das schon einmal eine gute Voraussetzung. Spezielle
Assembler-Programmierung kann man im Simulator ablaufen lassen, um zum
Beispiel die Flags im Statusregister anzusehen.
Die AVR-Peripherie ist so einfach, daß man dafür keinen Debugger
braucht, wenn man mit ein wenig Geschick den Programmablauf anhand
gesetzter Portpins verfolgt.
Ein Oszilloskope würde ich eher empfehlen.
> daß man dafür keinen Debugger braucht
Die AVR sind so beschissen designt, dass man einen auf JTAG
verhunzelten ATM32 nur mit JTAG anreden kann.
Nimm einen Dragon.
Aber Vorsicht. Selbst scharfes Ansehen kann ihn zerstoeren.
Oder tu das alte Ding entweder in die Bastelkiste zurueck
oder wirf es einfach in den Muell.
Karl M. schrieb:> Frage dich bitte erst, für was Du einen Debugger für ATmega*> benötigst.>> Habe ich selbst nach 15 Jahren nie benötigt.
Aha ;-)
> Die Programmlogik steckt im Programm und das muss man verstehen.> (Test-)Ausgaben können heute serial über einen TTL-USB Wandler an jeden> PC übermittelt werden.> Oder man verwendet nur eine LED zum Signalisieren..
Wenn der OP einen Debugger haben möchte, soll er doch einen benutzen -
da gibt es doch nichts zu diskutieren.
Warum sollte man mittlerweile auf Debugging verzichten? Ich hab oft gar
kein RS232 und keine LED, weil ich das nicht brauche - ich hab einen
Debugger ;)
Ich überlege mir, künftig eher STM8 als AVR einzusetzen, weil man über
SWIM wunderbar debuggen kann. Für alles größere benutze ich STM32 und
hab da eh SWD. Proprietäres Debugging-Gedöhns wie beim AVR ist nicht
mehr zeitgemäß - aber das werden die schon noch lernen.
Hallo,
der ATMEGA32 ist doch "Asbach Uralt". Den würde ich mir nicht antun.
Wenn Du Geld sparen willst: ATMEGA328 in Form eines Arduino Boards.
Vorteil preisgünstig, an jeder Ecke zu haben. Niemand zwingt dich die
Arduino Oberfläche zu benutzen.
Ich habe zum basteln einige Boards und habe mit einem Atmel Dragon
Programmer/Emulator angefangen. So empfindlich wie mansche Leute
sagen/schreiben ist der nicht. Meiner hat mindestens 10 Jahre auf dem
Buckel.
Aber ich habe auch einen neuen Atmel ICE und wenn Du auf ein
"Sonderangebot" von Microchip warten kannst, ist der auch nicht so
teuer.
Ciao
@Mampf F. : Genau. Es geht um einen ATmega32 - und welcher Debugger
dafür eine gute Wahl ist.
Danke für alle Empfehlungen für andere Controller usw., ist ganz
interessant, aber beantwortet leider nicht meine Frage.
@Hans: Danke für den Tipp, vielleicht finde ich ja auch noch so ein
Sonderangebot.
Was spricht ansonsten gegen einen Klon? Oder für einen Dragon?
Nimm den AVR-Dragon wenn den noch bekommen kannst.
Der ist nicht zu teuer und so empfindlich ist er nun auch wieder nicht.
Einfach in ein passendes Gehäuse einbauen gut ist.
Der kann ISP, Jtag und HV-Programming also ich find dieses Teil seit
Jahren super gut dafür.
Sogar one-wire debugging über ISP.
Danke für die Beiträge, aber leider helfen sie mir nicht in meiner
Ausgangsfrage.
Behalte ich den AVR-Dragon oder reicht für ein bisschen flashen und
debuggen eines ATmega32 auch ein günstigerer Debugger (welcher?), so
dass ich den Dragon verkaufen kann?
New schrieb:> Behalte ich den AVR-Dragon
Ich gestehe habe dein Eingangspost nicht ganz gelesen.
Behalte deinen Dragon, etwas vergleichbares unter 50€ wirst du
so schnell nicht finden.
Es bleibt dir sonst noch selber bauen oder warten bis etwas verfügbar
ist.
New schrieb:> Behalte ich den AVR-Dragon oder reicht für ein bisschen flashen und> debuggen eines ATmega32 auch ein günstigerer Debugger (welcher?), so> dass ich den Dragon verkaufen kann?
Nur für's Flashen geht's wesentlich günstiger und ist dann kompatibel zu
allem Möglichen.
Das Problem ist das Debuggen. Natürlich kann das hilfreich sein, aber
wirklich brauchen tut man es nicht. Insbesondere dann nicht, wenn es für
das Target einen einigermaßen brauchbaren Simulator gibt. Und das ist
beim Mega32 definitiv der Fall, da hat man sogar die Wahl zwischen
zweien. Jeweils mit ziemlich furchtbaren Unfähigkeiten und Fehlern, aber
bei kompetenter Nutzung unter der Berücksichtigung der jeweiligen
Schwächen sind beide durchaus brauchbar, irgendwie ergänzen sie sich
auch gegenseitig ein wenig.
Unter Berücksichtigung der Tatsache, dass der ATmega32 längst nicht mehr
"state of the art" ist, würde ich meine Entscheidung ganz sicher nicht
mehr davon abhängig machen, ob der unterstützt wird...
