[S] Nachfolger für AVR Dragon: UPDI Programmer + Debugger für AVR 8-Bitter in MC Studio v7 gesucht

[Hans M. (h_meier)]

Hallo,

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.

Gruß, Hans

[Dieter S. (ds1)]

Hans M. schrieb:
>
> ...(nein, die 250€ für das Atmel ICE sind mir zu viel)...

Geht auch deutlich günstiger wenn man auf das Gehäuse und die Kabel 
verzichtet, z.B. hier:

https://shop.myavr.de/index.php?sp=article.sp.php&artID=200142

[Veit D. (devil-elec)]

Hallo,

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.

[Veit D. (devil-elec)]

Hallo,

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?

[Dieter S. (ds1)]

Veit D. schrieb:
>
> das Kabel muss man dann selbst bauen können.

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).

[Georg M. (g_m)]

Dieter S. schrieb:
> Geht auch deutlich günstiger wenn man auf das Gehäuse und die Kabel
> verzichtet, z.B. hier:
>
> https://shop.myavr.de/index.php?sp=article.sp.php&artID=200142

[Gerhard H. (Gast)]

Veit D. schrieb:
> 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.

[Stephan S. (uxdx)]

https://www.reichelt.de/universal-isp-programer-avr-stm32-esp-lpc-diamex-exa-prog-p305203.html 
kann laut Beschreibung auch UPDI

und 
https://www.reichelt.de/xplained-nano-attiny416-attiny416-xnano-p353975.html

[Georg M. (g_m)]

USB-C:
https://www.microchip.com/en-us/development-tool/EV73J36A

Micro-USB:
https://www.microchip.com/en-us/development-tool/EV66E56A
https://www.microchip.com/en-us/development-tool/EV72Y42A
https://www.microchip.com/en-us/development-tool/EV35L43A

[Gerhard H. (Gast)]

Stephan S. schrieb:
> 
https://www.reichelt.de/universal-isp-programer-avr-stm32-esp-lpc-diamex-exa-prog-p305203.html
> kann laut Beschreibung auch UPDI

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.

[Dieter S. (ds1)]

Stephan S. schrieb:
> 
https://www.reichelt.de/universal-isp-programer-avr-stm32-esp-lpc-diamex-exa-prog-p305203.html
> kann laut Beschreibung auch UPDI

Der TO sucht etwas zum Programmieren und Debuggen. Der Diamex EXA-PROG 
ist nach meinem Verständnis nicht zum Debuggen geeignet.

[Dieter S. (ds1)]

Georg M. schrieb:

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?

[Gerhard H. (Gast)]

Dieter S. schrieb:
> 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.

[Dieter S. (ds1)]

Gerhard H. schrieb:
>
> Wohlgemerkt immer in Annahme optimaler Hersteller-IDE Anbindung.

Aus der EXA-PROG Doku:

"Im AVR-ISP-Modus ist EXA-PROG kompatibel zu STK500 und funktioniert mit 
AVR/ATMEL/MICROCHIP-Studio sowie AVRDUDE (Arduino, Bascom)."

und

"Im UPDI-Modus emuliert EXA-PROG einen JTAG2UPDI-Programmer. Dieser kann 
derzeit nur mit AVRDUDE benutzt werden"

[Gerhard H. (Gast)]

Dieter S. schrieb:
> "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.

[Harald K. (kirnbichler)]

Bis auf das "High-Voltage-Programming" erfüllt Mplab Snap die 
Anforderungen.

Es lässt sich mit Microchip Studio verwenden, es kann AVRs via ISP, 
UPDI, DebugWire und auch klassischem Vier-Draht-JTAG ansteuern.

https://www.microchip.com/en-us/development-tool/pg164100

Das ist eine abgespeckte Variante des PICKit 4.

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).

[Hans M. (h_meier)]

Moin zusammen,

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ß,

Hans

[Gerhard H. (Gast)]

Harald K. schrieb:
> 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.

[Hans M. (h_meier)]

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.

[Gerhard H. (Gast)]

Gerhard H. schrieb:
> 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.

[Hans M. (h_meier)]

Gerhard H. schrieb:
> Gerhard H. schrieb:
>> 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

[Gerhard H. (Gast)]

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.

[Georg M. (g_m)]

Gerhard H. schrieb:
> GND/VCC/UPDI

VTG
GND
UPDI

[Gerhard H. (Gast)]

Georg M. schrieb:
> Gerhard H. schrieb:
>> GND/VCC/UPDI
>
> VTG
> GND
> UPDI

Nö. Siehe Bild!

[Hans M. (h_meier)]

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.

[Hans M. (h_meier)]

3 einzelne Pins, alles andere fliegt um die Ohren :-)

[Gerhard H. (Gast)]

Hans M. schrieb:
> 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 :)

[Hans M. (h_meier)]

Hans M. schrieb:
>
> Bzgl. eines manuellen Updates muss ich mich mal schlau machen, das kenne
> ich so noch nicht.

gefunden:
https://packs.download.microchip.com/

:-)
Für die ATMega lief es durch, das Tiny hat er nicht gemocht: invalid 
PDSC file

Na ja, ist wie immer: manchmal läuft es nicht und manchmal raucht es :-)

[Georg M. (g_m)]

Gerhard H. schrieb:
> Nö. Siehe Bild!

Microchip Standard

1
2 VTG
3 GND
4 UPDI
5
6
7
8

[Gerhard H. (Gast)]

Georg M. schrieb:
> Microchip Standard

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.

[Georg M. (g_m)]

Gerhard H. schrieb:
> Wenn Du Dich aber unbedingt am "Standard" festhalten
> willst - bitteschön.

Schon längst geschehen.

https://www.mikrocontroller.net/attachment/562066/AVR_UPDI_Programmer.jpg

[Georg M. (g_m)]

"the pinout shown below should be used"

https://www.microchip.com/en-us/development-tool/DV244140

[Gerhard H. (Gast)]

Georg M. schrieb:
> "the pinout shown below should be used"

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!

[Adam P. (adamap)]

Hans M. schrieb:
> (nein, die 250€ für das Atmel ICE sind mir zu viel)

163€ bei Farnell.

Bei Ali für 62€, aber da wäre ich mir nicht so sicher, dass es Original 
ist, auch wenn es so beworben wird.

[Veit D. (devil-elec)]

Gerhard H. schrieb:
> Veit D. schrieb:
>> 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?

[Ob S. (Firma: 1984now) (observer)]

Veit D. schrieb:

> 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.

[Gerhard H. (Gast)]

Veit D. schrieb:
> Wie sieht das mit diesen Curiosity Programmer aus?

Genauso:

Gerhard H. schrieb:
> 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.

Ob S. schrieb:
> Zwischen IDE und Debugadapter läuft ein völlig anderes Protokoll

Und die Verbindung ist auch völlig anders über USB.

Veit D. schrieb:
> 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).

Fürs Curiosity findet sich eine aktuelle Firmware unter
https://packs.download.microchip.com/

PKOB nano support (1.14.751)
im Verzeichnis Firmware als nedbg_fw.zip.

[Veit D. (devil-elec)]

Hallo,

Danke Euch. So kann man sich irren.