AVRDUDE kann jetzt auch UPDI am nackten seriellen Port

[Ingo W. (uebrig)]

Kann sein, dass was ich hier schreibe, kalter Kaffee ist, in diesem 
Falle einfach ignorieren.

Bisher hatte ich für erste Gehversuche mit den moderneren Tinys, das 
Python-Script "pymcuprog" https://pypi.org/project/pymcuprog/ unter 
Debian 11 genutzt. Nach dem Wechsel auf Debian 12, ließ es sich erst 
nicht mehr mit "pip install pymcuprog" installieren (mittlerweile hab 
ich eine Lösung gefunden), aber eigentlich hatte ich es ohnehin nur als 
Notlösung angesehen und habe auch mit Python und der damit 
zusammenhängenden Infrastruktur keine Erfahrung. Daher mal den avrdude 
mit "-c ?" aufgerufen und in der Liste den vielversprechenden neuen 
Eintrag "serialupdi" gefunden.

$ avrdude -c serialupdi -P /dev/ttyUSB0 -p t814 -U flash:w:main.hex:i 

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9322 (probably t814)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file main.hex for flash
         with 100 bytes in 1 section within [0, 0x63]
         using 2 pages and 28 pad bytes
avrdude: writing 100 bytes flash ...

Writing | ################################################## | 100% 0.11 s 

avrdude: 100 bytes of flash written
avrdude: verifying flash memory against main.hex

Reading | ################################################## | 100% 0.03 s 

avrdude: 100 bytes of flash verified

avrdude done.  Thank you.

Also ist mein (nicht einmal geäußerter) Herzenswunsch in Erfüllung 
gegangen.
Vielen Dank an die fleißigen Entwickler von AVRDUDE (Jörg?) und Debian, 
welches von Version zu Version nutzerfreundlicher wird.

[Wastl (hartundweichware)]

Ingo W. schrieb:
> Also ist mein (nicht einmal geäußerter) Herzenswunsch in Erfüllung
> gegangen.

Was hilft's .... wenn man nicht einmal Debuggen kann. Da lob'
ich mir doch den Atmel ICE.

Ja, ich weiss, Debuggen ist nur was für Warmduscher. Ausserdem
ist der Controller so klein und so einfach gestrickt dass man
gar keine Programmierfehler machen kann.

[Ingo W. (uebrig)]

Wastl schrieb:
> wenn man nicht einmal Debuggen kann.

Mit pymcuprog kann man noch den RAM-Inhalt ausgeben. Das geht mit 
Avrdude (noch) nicht. Daher hab ich das Script auch erst mal wieder 
nutzbar gemacht.

[Gerhard H. (hauptmann)]

Ein Curiosity Nano kostet 20 Euro, damit ist samt Microchip Studio das 
ganze Thema abgeräumt.

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

Gerhard H. schrieb:

> Ein Curiosity Nano kostet 20 Euro, damit ist samt Microchip Studio das
> ganze Thema abgeräumt.

Ist das wirklich so? Kann man damit dann auch z.B. jeden AVRyDx oder 
AVRyEx programmieren und debuggen? Und all die anderen Megas und Tinys, 
die ein UPDI-Interface haben?

[Gerhard H. (hauptmann)]

Kurze Antwort: JA!

[Georg M. (g_m)]

3.5.1 Supported Devices
All external AVR microcontrollers with the UPDI interface can be 
programmed and debugged with the on-board debugger with Microchip 
Studio.


Versprochen ist versprochen ...

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

Gerhard H. schrieb:

> Kurze Antwort: JA!

Hast du das auch tatsächlich probiert (zumindest für einige Typen) oder 
gibst du hier nur die MC-Werbeaussage wieder?

Die habe ich natürlich selber auch gelesen, traue ihr aber, ehrlich 
gesagt, nicht wirklich über den Weg.

Der Grund ist einfach: Der exorbitante Preis für das Atmel ICE. Das 
passt irgendwie nicht zusammen. OK, man muss natürlich bedenken, da ist 
auch noch das SAM-Zeugs mit drin.

[Wastl (hartundweichware)]

Ob S. schrieb:
> Der Grund ist einfach: Der exorbitante Preis für das Atmel ICE. Das
> passt irgendwie nicht zusammen. OK, man muss natürlich bedenken, da ist
> auch noch das SAM-Zeugs mit drin.

Sollte das evtl. bedeuten dass man mit dem Curiosity Nano keine
ARMe (ATMEL SAMs) programmieren und debuggen kann?

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

Wastl schrieb:

> Sollte das evtl. bedeuten dass man mit dem Curiosity Nano keine
> ARMe (ATMEL SAMs) programmieren und debuggen kann?

Das ist wohl so, schließlich sprechen die ja nicht UPDI. Das würde mich 
aber kein bissel stören, ich mochte die SAMs sowieso nie. Auf ARM-Basis 
gibt es weit besseres am Markt zu wesentlich geringeren Preisen.

[Wastl (hartundweichware)]

Ob S. schrieb:
> Das ist wohl so, schließlich sprechen die ja nicht UPDI.

Aber das Curiosity Nano (ich kenne es nicht weiter) wird doch
wohl JTAG können? Dann wäre es ja zu den ARMen nicht weit ....

[Gerhard H. (hauptmann)]

Ob S. schrieb:
> Hast du das auch tatsächlich probiert (zumindest für einige Typen)

Selbstverständlich.
Ich habe den Debugger-Teil sogar ganz abgetrennt (obwohl das so nicht 
vorgesehen und nicht nötig ist). Ein bischen Schrumpfschlauch drum und 
fertig ist der Mini-Programmer und Debugger für UPDI.

Wastl schrieb:
> Aber das Curiosity Nano (ich kenne es nicht weiter) wird doch
> wohl JTAG können?

Nö das kann es nicht. Und braucht es auch nicht. Was willst Du noch mit 
dem pininflationären JTAG?
Heutzutage reicht ein einzelner UPDI Pin.

[Karl Z. (griffin27)]

Coole Sache! Weiß jemand mehr über die Hardware-Details der 
UPDI-Schnittstelle?
Also wer spricht wann mit welchen Strömen und 
Pullups/Pulldowns/Reihenwiderständen?

Hab letztens probiert mit einem Raspberry Pi Pico einen ATtiny424 zu 
programmieren, doch die Antwort des Tinys kam mit viel zu wenig Pegel 
raus.

Hatte 3.3V Versorgung, und das Antwortsignal hatte lag etwa zwischen 3.3 
und 2.3V, laut Oszilloskop.

[Ingo W. (uebrig)]

Der Tx/Rx-Pin (UPDI) des Controllers hat einen Open-Drain-Ausgang und 
einen sehr hochohmigen PullUp-Widerstand. Üblich sind 2 Varianten den 
UART (serielle Schnittstelle) vom PC anzukoppeln:
Im Eröffnungsbeitrag zu sehen: vom TxD des PC-UART, über einen 
Vorwiderstand (Beispiel: 470 Ohm) zum UPDI-Pin, den RxD direkt.

Die zweite Variante wäre, den UPDI-Pin über einen Pullup (gleicher Wert 
wie eben) an die Betriebsspannung, den TxD des UART über eine Diode zum 
UPDI, so dass nur der Low-Pegel übertragen wird (Kathode zum UART, Anode 
zum UPDI).

[Ingo W. (uebrig)]

Karl Z. schrieb:
> Hab letztens probiert mit einem Raspberry Pi Pico einen ATtiny424 zu
> programmieren, doch die Antwort des Tinys kam mit viel zu wenig Pegel
> raus.
>
> Hatte 3.3V Versorgung, und das Antwortsignal hatte lag etwa zwischen 3.3
> und 2.3V, laut Oszilloskop.

Klingt mir danach, dass dein Serien/Pullup Widerstand etwas zu hochohmig 
für die Übertragungsrate (üblicherweise 115200 Baud) ist.

[Karl Z. (griffin27)]

>> Hatte 3.3V Versorgung, und das Antwortsignal hatte lag etwa zwischen 3.3
>> und 2.3V, laut Oszilloskop.
>
> Klingt mir danach, dass dein Serien/Pullup Widerstand etwas zu hochohmig
> für die Übertragungsrate (üblicherweise 115200 Baud) ist.

Ich hab mich etwas unklar ausgedrückt: 2.3/3.3 sind die Pegel für 
Low/High. Der Open Drain zieht das signal also nicht stark genug nach 
unten. Ich muss mir die genaue Beschaltung nochmal ansehen. Danke an 
uebrig.