I've just been playing with one of the TinyAVR series 1 chips, the ATTiny1614 actually to do some extreme low power experiments with the inbuilt RTC together with an NRF24L01 radio module for battery applications.
Anyway, and this is the main point, for the development, I'm using the MegaTiny core (2.3.2) by @DrAzzy . One of the great feaures (OK. maybe not exclusively with this core) is that the UPDI programming can be done with simply an FTDI like device (USBTTL adapter) and simply a diode and resistor. A python script within the core toolbox handles it all. Even better, the same USBTTL adapter can be used also for the serial monitor (by swapping a couple of jumber wires). That means that, without even a boot loader on the device, it can be programmed, then the serial console output viewed in a way very similar to developing a program on a development board such as the Nano or Uno. But it gets even better. With a simple CMOS analog switch (example CD4052), it is not even necessary to fiddle around with jumper wires to get a *clean workflow through from loading the program onto the device to testing the program together with the serial console. *Clean here means 99% clean because, at the moment, a switch has to be flicked to put the rig in programming mode and back out. That would be the next refinement to automate this stage and then maybe create a full development board. I'm not sure though about a reliable detection method for the start/end of the programming phase.
This is what I've put together so far. There may also be better ways of achieving the same thing. Hopefully someone finds it useful.
I think the integration of a pyupdi-like tool (in this case, its based on pymcuprog, with numerous performance enhancements, to bring average data rates from 500-1k/sec (see like 2.2.0 or something, where it;'s too slow) to >10k which leaves jtag2updi in the dust) is unique to DxCore and megaTinyCore right now, I know MegaCoreX was going to add it too, don;t know off hand whether he has yet.
SerialUPDI is what we're calling it and I have been too busy to do a call with the other coauthor about reviewing some of my performance enhancements and getting the whole thing into shape where it;s fit for release separately.
But in any event - we're a step ahead of you here. SerialUPDI doesn't touch (or shouldn;t touch, haven't recently verified this,) the DTR or RTS lines. Most serial monitors drive them LOW. so that;'s what you use for the analog switch. I had some boards made to test this with, but thus far every one ive assembled had assembly flaws suich that I can't determine whether the design is sound otherwise.
I only started looking at your SerialUPDI stuff a few days ago when I had problems with the jtag2upd in that it refused to upload a sketch. I then noticed that it [jtag2upd] was no longer recommended on yout Github page, so I upgraded the core and the SerialUPDI part worked immediately, or better put, as soon as I had correctly interpreted the diode symbol in the description which is formed out of miscellaneous keyboard characters.
I didn't know much about the history of it but I did notice that Microchip provided what looks like raw basis of it with pymcuprog so I wasn't completely sure if this development was unique.
Anyway, I was very impressed about how it gave a very smooth development work flow when contrasted with something like an ATTiny84 development where you are fiddling around with an ICSP programmer (there is hardly room for a bootloader), then connecting up an FTDI for the serial console.
The CD4052 development was only an additional comfort feature to simplify role swapping of the USBTTL device, but then I did begin to dream of something like the development board type model (Nano, Uno ESP8266 etc etc. ) where, with a single cable connection, the entire development cycle could be completed. But, special with the ATtinys, the chances are that the user is also developing low power applications so jumpers to isolate the power hungry bits would also be good.
Well, I don't doubt that for a minute and am certainly looking forward to seeing what ideas and products emerge.
I mean you already have a a "pro mini" for the DX series by just putting it on any breakout, hooking up the standard DTR autoreset (1 resistor, 1 cap, and a diode - which you don;t even need on DA or DB parts because there's no HV programming mode to fear, and loading Optiboot onto it (the breakouts I sell already have that, and... actually I think I pre-bootload them to test that they work, since DxCore since 1.3.0 cleanly unbootloads a board you try to upload to that has a bootloader on it there's no reason not to use optiboot instead of blink - so yeah, they already exist, just not with the serial adapter on the board.
I recently made a run of AVR128DB32-based "Azduino Nano" prototypes, with a pair of solder bridges to select the voltage to run the MVIO pins from (3.3v from regulator, 5v for single supply operation, or PD2, which is the output of OP0 opamp peripheral, which you can set up as a voltage follower and set up to follow the DAC (you can't get very much current out of it - but this is a suggestion coming from Microchip. this isn't just some raving lunatic amateur in hobby circles (where electrically questionable things are the norm) - the raving lunatic is a professional writing official app notes!
I'm always fascinated to see what emerges from your lab and by the resources you put into maintaining the cores to make the AVR-like MCUs integrate into the Arduino eco-system.
However, I'm not going to spend too much time looking at the newer, more powerful 8 bit processors. Not at the moment anyway. My usage profile is currently either small 8 bit MCUs for battery powered applications where the TinyAvr series 1 seems perfect, distinguishing itself from the original Tiny series with at least a flexible RTC which can run in standby mode with a respectable 0.7uA and, now of course, simplicity of handling, which is where this thread started and, of course, many other ways like the event system, new peripherals etc. Having said all that, I may now plan some time to look in more detail at what you have done with the DX series which, from your description, could also be very interesting.
If low power is not an issue, then I tend to go to 32 bits and focus on the ESP. It is not that I don't find the other 32 bit MCUs interesting, in fact I do, but I simply have difficulty summoning up the enthusiasm to get familiar with another great stack of data sheets.
Just adding to this, I want now to program and test the ATtiny1614 project at 3.3 volts because I am adding a display which does not have 5 volt tolerant pins. Instead of using a purpose made USBTTL device, some of which anyway, even when offering a voltage selection switch, can only manage a few mA at 3.3 volts, I used a CH340G based Arduino Nano clone converted to 3.3 volts and with the reset pin forced low. I have described this Nano 3.3volt conversion from an earlier project here: Arduino Nano CH340G 3.3 volt conversion .
This worked OK for using the serial monitor but not for UPDI programming. The problem is that the TX and RX pins are each caught in voltage divider formed out of two 1K resistors and a red indicator LED trapping the RX/TX lines between 800mV and Vcc. This is crude method of getting some indication of activity on the TX/RX lines and is employed on some clones like this. Anyway, removing the high side resistors solved the problem but with, of course, the disadvantage that the RX and TX indicator lights no longer function.
In the meantime, MCUdude / @hansibull has produced what appears to be a similar design for a Serial UPDI programmer in that it uses an analog switch for the role swapping of the usb/uart chip but additionally with a solution (with some caveats) to make this role swapping automatic.
The last design I have published is here : Yet Another UPDI Programmer and I have this is in current use for ATTINY1614 development where I don't use a bootloader.
