AVR Freaks

I'm assuming (hoping) "pymcuprog-style" means avrdude can talk in the UPDI protocol directly via a USB/serial adapter.

Correct. It incorporates most of the improvements found in the SerialUPDI version bundled with DxCore, mainly improved speed.

After the project was moved from Savannah to Github, lots of new volunteers have started to contribute to the project, myself included.

I'd argue that the project is highly active again, and new volunteers that can help out with the reported issues are always welcome.

There are still things pymcuprog can do that Avrdude can't, most noticeably support for high-voltage UPDI programming using a PicKit4 or a Powerdebugger.

I technically got it to work, but it needs some work in order to be as functional and practical as the pymcuprog implementation is.

I'm by no means a Python programmer, and I'm having a hard time following the pymcuprog program flow, so I have basically given up and moved on.

</off topic>

Nice, I didn't knew there was a C version of pyupdi 

Looking at the source code I can see it doesn't support the AVR-Dx yet. This too quite a bit of work for jtag2updi.

Man, the Snap costs $35 now? I think I paid half of that.

That one has always been expensive, but the Snap was cheap when it was launched.

Here is a quote from this thread  https://www.avrfreaks.net/forum/mplab-snap-feb20

Oh, well, I guess that was when there was an actual supply chain for electronics.

HI 

i have question on  ATtiny1626 ic , can we program the ATtiny1626 controller using Pickit4 .  if yes what is hardware and software setting .

thank you 

Thank you  @ gchapman

Thank you fro quick response. I will go through the link and check

one more thing is which are all pins  connection between Attiny1626 to Pickit4  , as Attiny1626 has only one pin that's UPDI.  and any pull or pull down resistor or capacitor required? .

Thank you.

Sorry i am not clear , can you share the document link which clarify the connection details .

 - we have small project using in tools to read the voltage and temp.  Is plan is use to ATTiny1626 with MPLABx and Xc8 compiler  and Pickit4 debugger .

 - please corrected me  if my selection compatibility is wrong . 

 - One more thing  is  MCC (mplab code configurator)  supports for ATtiny controller ?

Thank you

Yup, I did that too during my experiments when writing jtag2updi - blink a LED via UPDI. Interestingly, UPDI can write some bits that are read only for the CPU, such as peripheral interrupt flags IIRC.

Also, if you are writing a new program, I would recommend that you extract the MCU memory regions from the "atdf" files that come from Microchip IDEs instead of using some kind of proprietary definitions, it will save work later.

For example, I need to manually update avrdude.conf with definitions each time a new UPDI chip comes into production.

Because I haven't been following the new versions of avrdude I guess. Anyway, someone needs to update the avrdude.conf file in any case.

edit: BTW, releasing a major version, 7.0, takes courage and boldness. I'll take a look soon and see if my favorite bugs are still there 

That would be great, and even better if you could open an issue so we could get rid of them once and for all!

A lot has happened since the project was moved to Github, and several skilled and courageous developers have joined.

An issue or a PR is usually resolved within a few days and not years like before. 

I'm not so sure about that! The terminal has seen a major overhaul, and the latest upstream Avrdude version has a lot of edge cases sorted out.

And in case you didn't know, terminal write mode now supports  1, 2, 4, and 8-byte integers, 32 and 64-bit floats, strings, characters, and "fill mode"!

Usage: write <memory> <addr> <data>[,] {<data>[,]} 
       write <memory> <addr> <len> <data>[,] {<data>[,]} ...

Ellipsis ... writes <len> bytes padded by repeating the last <data> item.

<data> can be hexadecimal, octal or decimal integers, double, float,
C-style strings and chars. For numbers, an optional case-insensitive suffix
specifies the data size: HH: 8 bit, H/S: 16 bit, L: 32 bit, LL: 64 bit, F:
32-bit float. Hexadecimal floating point notation is supported. The 
ambiguous trailing F in 0x1.8F makes the number be interpreted as double;
use a zero exponent as in 0x1.8p0F to denote a hexadecimal float.

An optional U suffix makes a number unsigned. Ordinary 0x hex numbers are
always treated as unsigned. +0x or -0x hex numbers are treated as signed
unless they have a U suffix. Unsigned integers cannot be larger than 2^64-1.
If n is an unsigned integer then -n is also a valid unsigned integer as in C.
Signed integers must fall into the [-2^63, 2^63-1] range or a correspondingly
smaller range when a suffix specifies a smaller type. Out of range signed
numbers trigger a warning.

Ordinary 0x hex numbers with n hex digits (counting leading zeros) use    
the smallest size of 1, 2, 4 and 8 bytes that can accommodate any n-digit hex
number. If a suffix specifies a size explicitly the corresponding number of
least significant bytes are written. Otherwise, signed and unsigned integers
alike occupy the smallest of 1, 2, 4, or 8 bytes needed to accommodate them  
in their respective representation.

Apparently, support for generic flash write in terminal mode for most ISP and UPDI(?) programmers are also on its way.