bisher bin ich mit der (ur-)alten Atmel HW gut zurechtgekommen, hauptsächlich nutze ich noch einen der ersten AVR Dragon zur Programmierung und Debugging. Trotz aller Unkenrufe hat er bis heute überlebt.
Aber so langsam holt mich der Fortschritt ein, möchte/muss jetzt die neuen Tiny uC (tiny402) nutzen, wobei der Dragon das lt. Microchip Studio v7.2594 nicht mehr kann (also UPDI programmieren). Im MC Studio wird mir das PICkit v4 angeboten, das hat lt. Webseite EOL und man möge doch bitte das v5 nutzen. Das MC Studio v7 listet das PICkit v5 aber nicht als untersützten Programmer, also auf MPLab umsteigen? Der Vergleich hier ist auch etwas älter, bzw. liefert keine Details:
https://developerhelp.microchip.com/xwiki/bin/view/software-tools/programmers-and-debuggers/#HProgrammer2FDebuggerComparisonChart
Daher meine Frage: gibt es einen halbwegs bezahlbaren (nein, die 250€ für das Atmel ICE sind mir zu viel) Programmer und Debugger für die AVR 8-Bit Controller der sich in das aktuelle Microchip Studio integriert?
Sonst würde ich umsteigen und das PCIkit v5 holen.
das Kabel muss man dann selbst bauen können. Kann das der TO? Hat er die RM 1.27 Schneid-Klemmstecker und passendes Flachbandkabel? Altes 80pol. IDE Kabel kann man dafür verwenden.
man kann doch mit dem Programmierteil von den Boards (bspw. Microchip ATtiny1627 Curiosity Nano) alles programmieren was UPDI hat. Kann man damit nicht auch alles debuggen was UPDI hat?
Oder man kauft das passende Kabel im oben verlinkten Shop. In der Summe etwas die Hälfte der genannten EUR 250 (Nein, ich habe mit dem Shop nichts zu tun).
Kann man damit nicht auch alles debuggen was UPDI hat?
Kann man.
Und die Curiositys dürften unter den ausgereiften Lösungen mit ca.25 Euro die günstigsten sein. Man kann sogar den nEDBG Teil vorsichtig abtrennen und hat einen kunkurrenzlos kleinen Programmer/Debugger.
Auch nicht schlecht!!!
Hier fehlen mir nur Erfahrungswerte wie gut das Teil mit Microchip Studio mitspielt!??
Mit den Curiositys bekommt man übrigens nicht nur einen Controller dazu sondern auch die Möglichkeit dessen bequemer USB-Programmierbarkeit vom Win-Explorer aus.
Was auch immer Du mit dem Bild sagen willst: ist es so schwer "Atmel-ICE" als Suchbegriff einzutippen wenn Du scheinbar nicht direkt auf den Link klicken willst?
Der Diamex EXA-PROG ist nach meinem Verständnis nicht zum Debuggen
geeignet.
Das stimmt wohl leider...
Also keine Konkurrenz für nEDBG.
Dafür ist aber das ISP Interface für die älteren AVR und generell die breitere Controllerarchitektur- Unterstützung von Vorteil. Wohlgemerkt immer in Annahme optimaler Hersteller-IDE Anbindung.
"Im UPDI-Modus emuliert EXA-PROG einen JTAG2UPDI-Programmer. Dieser kann
derzeit nur mit AVRDUDE benutzt werden"
Oh je. Danke Dieter, das fegt das Teil jetzt aus meiner Interessensphäre :)
Kompatibilitäten sind unbedingt zu hinterfragen nachdem ich z.B. mit chinesischen AVR-JTAG schlechte Erfahrungen unter Studio7 gemacht habe.
Studio4 funktioniert.
Man muss sich allerdings diverse Adapter zum Programmieren/Debuggen selbst schnitzen, da Mplab Snap nur eine achtpolige Buchsenleiste hat. Da die aber im bastelfreundlichen 0.1"-Raster ausgeführt ist, ist das jetzt keine Raketenwissenschaft.
Ich weiß nicht, was ich falsch gemacht habe, aber ich bin den hier Beitrag "Ärgernis MPLAB Snap" geschilderten Problemen nicht begegnet.
Ich musste auch die beschriebene Hardwaremodifikation (Entfernen von R48, Hinzufügen eines Pullups) nicht durchführen; die paar AVRs, die ich damit bislang programmierte (ISP und DebugWire), nahmen mir das nicht übel.
Aber vielleicht hatte ich auch nur mit meiner Auswahl Glück (328P, 2560 und Tiny85).
vielen Dank für eure Anregungen.
Auch wenn ich die eierlegende Wollmilchsau gesucht habe, aber die scheint es im low-cost Segment halt (noch?) nicht zu geben. Würde mir jetzt eins der Eval Boards holen und davon den Debug Teil abtrennen (ggf. sogar absägen für ein ganz kleines Gehäuse). Dann muss der Dragon für die alten uCs weiter durchhalten und die neuen bekommen eine Spezialbehandlung.
Vielen Dank, bin schon (hoffentlich) glücklich wenn der Postbote am Dienstag klingelt.
Guten Start ins WE und Gruß,
Ich weiß nicht, was ich falsch gemacht habe, aber ich bin den hier
Beitrag "Ärgernis MPLAB Snap" geschilderten Problemen
nicht begegnet.
Ich leider schon.
Das ist allerdings schon eine Zeit her, möglicherweise ist das heute besser.
Die Spreu vom Weizen trennt sich meist beim Debugging.
Und mutmaßlich bei der verwendeten IDE: MPLAB-Snap ist schon dem Namen nach eher zu MPLAB-X kompatibel, etwas anderes ist in der Doku erst gar nicht erwähnt... Auch der Preis ist jetzt nicht der günstigste.
Das Snap Teil gibt es bei Reichelt gerade im Angebot für 50€. Hatte ich mir auch angesehen, aber wegen Zwang zu MPlab verworfen. Dann lieber zwei HW Tools und bei der alten Umgebung bleiben.
Und die Curiositys dürften unter den ausgereiften Lösungen mit ca.25
Euro die günstigsten sein. Man kann sogar den nEDBG Teil vorsichtig
abtrennen und hat einen konkurrenzlos kleinen Programmer/Debugger.
Und die Curiositys dürften unter den ausgereiften Lösungen mit ca.25
Euro die günstigsten sein. Man kann sogar den nEDBG Teil vorsichtig
abtrennen und hat einen konkurrenzlos kleinen Programmer/Debugger.
Ja, so ähnlich wird meiner dann bald auch aussehen. Nur andere Aderfarben und einzelne Pins um flexibler zu sein, d.h. GND, VCC und UPDI liegen bei mir derzeit nur als Testpads vor
Falls Du mit Studio 7 arbeitest müsstest Du nur unter Device Programming/Tools/Tool-Settings "Hide unsupported devices" = False stellen. Bei der Adern/Pinanschluss- Reihenfolge auf GND/VCC/UPDI achten- denn genauso sind die Pins bei den (meisten) UPDI-Controllern nebeneinander angeordnet. Das nEDBG Firmware-Updaten auf die neuesten Controller (AVR-EB/DU) geht nur noch mit MPLAB-X oder manuell, da das mittlerweile 2 Jahre alte Studio7 maximal noch mit DevicePacks geupdatet wird.
Ok, das habe ich gefunden und auch die Einschränkungen bzgl. drag & drop. Da ist die Doku doch sehr Anfängerfreundlich und nicht kryptisch :-)
Mal sehen wann ich aus Versehen (probiere) einen alten Tiny oder Mega flashe...
Bzgl. eines manuellen Updates muss ich mich mal schlau machen, das kenne ich so noch nicht.
3 einzelne Pins, alles andere fliegt um die Ohren :-)
Allerdings. Für solche Fälle muss man die Pins des Controllers natürlich passend zum UPDI-Interface der eigenen Platine führen. Es wäre nur frustrierend wenn das dann später just nicht zum einander pinkompatiblen AVR-Dx/Ex Universum kompatibel wäre :)
OK aber was hilft der Dir wenn die Realität anders ausschaut Georg?
Ich bin hier bei einem passenden Anschluss fürs Curiosity-Tool und für eigene Platinen eigener Projekte. Selbst mit PIC5 Kit würde ich da die 3poligen Anschlüsse abändern. Gerade auf Lochraster ist eine 3polige Steckleiste fürs Programmieren genau 1:1 neben das IC verbunden nämlich überaus praktisch! Wenn Du Dich aber unbedingt am "Standard" festhalten willst - bitteschön.
@Hans: Die manuelle Firmware Update-Möglichkeit besteht definitiv, die Info müsste ich hier noch nachreichen. Bei den heutigen Festplatten- Größen hab ich aber keine Vorurteile, MPLAB-X parallel zu installieren zumal das die AVR-IDE Zukunft sein soll. Via Zugriff über MPLAB-IPE war das Updaten schnell, automatisch, unbürokratisch erledigt.
Ich vermute, warum 'should be used' kannst Du nicht erklären :)
Sei unbesorgt Georg. 3 simpel nebeneinander stehende Pins tuns genauso und sparen ordentlich Platz!
Kann man damit nicht auch alles debuggen was UPDI hat?
Kann man.
Und die Curiositys dürften unter den ausgereiften Lösungen mit ca.25
Euro die günstigsten sein. Man kann sogar den nEDBG Teil vorsichtig
abtrennen und hat einen kunkurrenzlos kleinen Programmer/Debugger.
Hallo,
eine Frage dazu noch. Werden diese Teile auch mit Updates versorgt? Mein Atmel ICE wollte einen AVRxEA erst nach einem Firmware Update bespielen. Wie sieht das mit diesen Curiosity Programmer aus? Ist darüber etwas bekannt? Mein Gedanke ist sowas als "Backup" hinzulegen.
Eine Frage wäre noch. Warum benötigt sowas wie ein Atmel ICE für neue Controller überhaupt ein Firmware Update? Sollte das nicht alles über das UPDI Protokoll zwischen IDE und MCU laufen? Klingt ja fast so als müssen alle Controller in der Firmware hinterlegt sein. Nur warum?
Eine Frage wäre noch. Warum benötigt sowas wie ein Atmel ICE für neue
Controller überhaupt ein Firmware Update? Sollte das nicht alles über
das UPDI Protokoll zwischen IDE und MCU laufen?
Nein. Leider. Zwischen IDE und Debugadapter läuft ein völlig anderes Protokoll. Die typische aufgeblasene eierlegende Wollmilchsau. Und dieses Potokoll ist auch überhaupt nicht dokumentiert.
Leider fehlen übrigens aber auch bei UPDI-Dokumentation einige kleine (für's Debugging aber unverzichtbare) Stückchen. Das sind aber so wenige, dass man sie per RE ermitteln kann.
Bloß: wenn man das getan hat, hat man ja immer noch keinen Debugger (also die PC-seitige Software), die direkt UPDI reden könnte. Die vorhandene kann halt wiederum nur dieses aufgeblasene und komplett undokumentierte Protokoll.
Klingt ja fast so als
müssen alle Controller in der Firmware hinterlegt sein.
Naja, in Wirklichkeit gibt es dort sowas wie "Controller-Klassen". D.h.: nicht wirklich jeder einzelne verschissene Controller muss dort hinterlegt sein, aber z.B. für die EA gibt es dort eine Klasse, die sich nur mit diesen Targets beschäftigt.
Oder es gibt sie eben nicht. Dann kann der Adapter mit den EA nicht reden.
Das nEDBG Firmware-Updaten auf die neuesten Controller (AVR-EB/DU) geht
nur noch mit MPLAB-X oder manuell, da das mittlerweile 2 Jahre alte
Studio7 maximal noch mit DevicePacks geupdatet wird.
Warum benötigt sowas wie ein Atmel ICE für neue Controller überhaupt ein
Firmware Update?
Interessante Frage. Ich meine mich erinnern zu können daß manuelle Firmware- Updates irgendwo mal mit Infos zu behobenen Fehlern daherkamen. An die Hinterlegung einzelner Controller glaube ich nicht. Eher an eine punktuelle Anpassung an neuere UPDI Hardware/ Protokoll (z.B. Implementierung des PDID Features).
