Arduino support for the new tinyAVR-0, tinyAVR-1 and megaAVR-0 seires

[MCUdude]

I know this isn't really an issue, but I needed a place I can discuss with you directly.

As you already know the latest ATmegas and ATtinys are completely different than anything we've seen before, and adding Arduino support for these from scratch would be extremely time consuming. However since the megaavr core is now public it's possible to borrow a lot.

A few hours ago I dug up the ATtiny817 Xplained mini board I got for free from Arrow last year. AFAIK you and @per1234 have one too. After some fiddling in Atmel studio 7 I got it working well, and I feel like I understand more of the low level stuff here after a bit of research.

The ATtiny817 (and the rest of the family) is really neat, and Arduino support for this would be great! It turns out that the ATmega4809 and ATtiny417/814/816/817 have a lot in common. In fact, all tinyAVR-0, tinyAVR-1 and megaAVR-0 chips share the same register names, and many register address locations are the same. This makes porting the megaavr core to other devices quite simple because all the hard work is done by the Arduino developers (in collaboration with Microchip).

A big drawback with the tinyAVR-0, 1 and megaAVR-0 families is the new UPDI programming interface. It requires new hardware, and is completely different from the ISP interface we all know and love. Luckily the Xplained boards have an ATmega32u4 on board with mEDBG firmware. This works really well with Atmel Studio and with Avrdude. Even though the mEDBG firmware isn't open source its hex and eep file is available for download. This means you can (probably, most likely) turn an Arduino Leonardo or Micro into an mEDBG device!

So, what do you think? Is this something you want to collaborate to? My plan was to use the megaavr core files as a starting point and add support for ATmega808/1608/3208/4808/1609/3209 as a first step, since these has practically the same hardware as the 4809. I'll try to get my hands on some 4809 hardware to begin with.

[SpenceKonde]

I would like to get something to support this - it sucks that they got rid of normal ISP programming. I don't want to just support Atmel's development boards - I'd like a core that I maintained to support just a bare attiny chip. Do you know of any affordable UPDI programmers, or if anyone has released code to support that? What is done on the Arduino Uno Wifi Rev. 2? Is there a chip on there with firmware that programs it? Is that firmware available, if so? That would provide a much easier route towards getting started with this if so.

It's good to hear that the registers are the same on the new-style tiny and new-style mega's. I got a couple of Arduino Uno Wifi Rev. 2 boards, but haven't had time to even take them out of the packages yet. And that's really the core of my problem here - his is the sort of thing I'd love to work on. but time has been in really short supply lately, and I'm not sure how much work I'd be able to contribute in the near future.

[sleemanj]

Do you know of any affordable UPDI programmers, or if anyone has released code to support that?

https://github.com/ElTangas/STK2UPDI

https://github.com/ElTangas/jtag2updi

[SpenceKonde]

Nice! Thanks!

[tedder]

Looks like avrdude can speak UPDI.

[per1234]

If dev boards or chips are needed to make this happen I'd like to donate to that cause. I recently started a new job and am earmarking part of my first paycheck to go back to the Arduino community that helped me get here. This is definitely a worthy cause.

I'm happy to provide assistance with the project as my skills allow. The usual Boards Manager and Travis CI thing of course, but I can also write documentation or other "grunt work" if you like.

---

Note that Arduino megaAVR Boards uses the new ArduinoCore-API system. All the non-architecture specific core code has been moved to a separate repository, from which it can be shared between all cores. That means less code you need to worry about porting and maintaining. I'd love to see this project be one of the first 3rd party hardware packages to take advantage of it. You should be able to use a subtree for this.

[MCUdude]

What is done on the Arduino Uno Wifi Rev. 2? Is there a chip on there with firmware that programs it? Is that firmware available, if so?

Yes, there's a chip that programs the 4809 over UPDI. It's an Atmega32u4 that acts like a programmer and a USB to serial device. That means the 4809 doesn't have a bootloader, but has to be programmed by and UPDI programmer every time. You should have a look at the Xplained Yourself board over at Avrfreaks and Hackaday.io.

..but time has been in really short supply lately, and I'm not sure how much work I'd be able to contribute in the near future.

That's perfectly fine. I'll start with the megaAVR-0 series first, and then you may join when you feel like you have time for it.

I'm planning to create a repo to host the core files, where the ArduinoCore-API is included as an updatable subtree (Like I'm already doing with MCUdude_corefiles.

If dev boards or chips are needed to make this happen I'd like to donate to that cause. I recently started a new job and am earmarking part of my first paycheck to go back to the Arduino community that helped me get here. This is definitely a worthy cause.

Great to hear you got a new job, but you haven't given up on glass blowing have you? I could indeed need some hardware! The first thing that comes to mind is the need for an ATmega3208/4808 board. AFAIK the AC164160 is the only dev board available. The XNANO boards (104 and 416) would be great to have too. Arrow.com provides free world wide shipping at no minimum order.

Another important thing missing is the support for the new tinyAVR-0 and tinyAVR-1 in the current IDE. It's quite difficult creating Arduino support for these when the toochain doesn't support them. We need to push the Arduino developers to update the toochain to support (all) new tinyAVR-0 and 1-series.

[MCUdude]

After I've gotten used to the UPDI interface I'd like to design a neat and tidy mEDBG board we can use for programming and debugging standalone boards. Part of what I do for a living is designing PCBs in Altium, so this shouldn't be an issue.

Maybe we (the community) can standardize on a 6-pin connector (like the "old" ISP interface) that provides both upload/debug functionality and UART RX and TX in the same connector. I'd prefer to have it like this, because it would then be UART compatibe with ATmega64/128/1281/2561. It also doesn't fry your target of you acidentally insert it the wrong way.

EDIT: Maybe the last unused pin should be connected to the CLKOUT pin on the mEDBG chip? This way we could use the clock generation functionality of the mEDBG chip to recover MCUs with faulty external clocks. Pinout pic updated!

[per1234]

Great to hear you got a new job, but you haven't given up on glass blowing have you?

No, but the glass sales have been on a steady decline for years. The trend is clearly pointing to a time in the near future where I can no longer support myself. The upside to the glass downturn is that I spent the time freed up by lack of work teaching myself electronics and programming (with no idea of turning it into a career). When I got a job offer to do even more of the Arduino work I'm so passionate about, I couldn't pass it up.

The first thing that comes to mind is the need for an ATmega3208/4808 board. AFAIK the AC164160 is the only dev board available. The XNANO boards (104 and 416) would be great to have too. Arrow.com provides free world wide shipping at no minimum order.

Done! I'll send you a private message on the Arduino Forum to get your shipping info.

Another important thing missing is the support for the new tinyAVR-0 and tinyAVR-1 in the current IDE. It's quite difficult creating Arduino support for these when the toochain doesn't support them. We need to push the Arduino developers to update the toochain to support (all) new tinyAVR-0 and 1-series.

Is it only avr-gcc, or AVRDUDE as well? From https://github.com/arduino/ArduinoCore-megaavr/issues/17#issuecomment-463101674, it sounds like at least the tinyAVR-0 are already supported by avr-gcc 7.3.0-atmel3.6.1 in the beta Arduino AVR Boards package, which is installable via Boards Manager. This would be a similar situation to how the PB support was initially handled in MiniCore. That seemed to work out OK. I wouldn't be surprised if the tinyAVR-1 aren't also supported by that avr-gcc. I also think that Arduino is on the fast track to a new production release of Arduino AVR Boards release that uses avr-gcc 7.3.0-atmel3.6.1, since there is a serious problem with the current avr-gcc 5.4.0 they're using. So it may be out by the time your new core is ready to use.

[MCUdude]

Is it only avr-gcc, or AVRDUDE as well?

I think it's only avr-gcc. I downloaded the latest boards manager release for UNO Wifi Rev2, and had a look in the avrdude.conf file that came with it. It seems like all tinyAVR-0, tinyAVR-1 and megaAVR-0 devices is there. It needs to be tested properly though. I'm especially curious about how the new fuses work with Avrdude. I'd like to expose useful fuse settings to the user in the IDE tools menu. I'd probably have to use bit manipulation.

[mraardvark]

I could indeed need some hardware! The first thing that comes to mind is the need for an ATmega3208/4808 board. AFAIK the AC164160 is the only dev board available. The XNANO boards (104 and 416) would be great to have too. Arrow.com provides free world wide shipping at no minimum order.

The Curiosity Nano platform is another option, eg: DM320115 The on-board debugger can be isolated by cutting some straps and used to program & debug other devices. There are also utils like pyupdi which use any CDC/VCOM as UPDI programmer.

[MCUdude]

It seems like the DM320115 uses a different EDBG chip, a SAMD21 based one instead of an ATmega32u4. Do you know if this is compatible with the xplainedmini_updi programmer option in Avrdude? It would be great if the Curiosity Nano 4809 would work with Arduino IDE out of the box by installing the UNO Wifi Rev2 package.

[mraardvark]

Correct. Both DM320115, and the AC164160 previously referred to here, use the SAMD21-based debugger. The xplainedmini_updi option will probably not work since it uses the 0x2145 PID while the SAMD21 debugger uses 0x2175, but that should be simple to add. Both variants are technically EDBG-based, so the protocol is the same.

[MCUdude]

@mraardvark your pyUPDI project looks very neat. Is there a chance that this could be implemented as a dedicated protocol (uart2updi) in avrdude someday? This will totally eliminate the need for an EDBG chip, and it will work "out of the box" for anyone who have Arduino IDE installed.

[SpenceKonde]

The stk500v2 to UPDI code linked above looks really appealing IMO - assuming it works (I haven't had a chance to investigate it) it would allow use with avrdude with no changes to avrdude or anything else...

[MCUdude]

It seems like the STK2UPDI project is replaced with the jtag2updi project. However you still need a microcontroller with firmware for this + a USB to serial adapter, whereas with the pyUPDI only need the USB to serial adapter. I wonder if there exist any hardware for testing this? Can the ATmega32u4 be used for this with serial port emulation?

[mraardvark]

So many ideas, so little time :/ I have a modified tiny416 xplained mini which I use for pyupdi testing, using the mEDBG's CDC instead of its HID/UPDI stack.

[WestfW]

Atmel is adding new device info to their compiler via "packs", rather than complete re-issue of new compiler toolchains. Studio knows how to find the packs, but the CLI toolchains (for pretty much any OS that you used the toolchain installer) make it a pain to use them. There does seem to be a way to copy the "pack" files into the toolchain dirs:

https://www.avrfreaks.net/comment/2526416#comment-2526416

Example:

****
**** Expected failure of non-existing device.
****
 avr-gcc foo.c -mmcu=attiny416
In file included from foo.c:1:0:
/usr/local/avr8-atmel-3.6.1.495/avr/include/avr/io.h:623:6: warning: #warning "device type not defined" [-Wcpp]
 #    warning "device type not defined"
      ^
/usr/local/avr8-atmel-3.6.1.495/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld: cannot find crtattiny416.o: No such file or directory
/usr/local/avr8-atmel-3.6.1.495/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld: cannot find -lattiny416
collect2: error: ld returned 1 exit status

****
**** Add Device space from Atmel Pack.
****
WWHackintosh<9977> sudo cp /Downloads/Atmel.ATtiny_DFP.1.3.229/gcc/dev/attiny416/device-specs/specs-attiny416 /usr/local/avr8-atmel-3.6.1.495/lib/gcc/avr/5.4.0/device-specs/
Password:

****
**** Add needed libraries and linker scripts and such
****
WWHackintosh<9979> sudo cp -R /Downloads/Atmel.ATtiny_DFP.1.3.229/gcc/dev/attiny416/avrxmega3/* /usr/local/avr8-atmel-3.6.1.495/lib/gcc/avr/5.4.0/avrxmega3/

****
**** Add devide .h file.
****
WWHackintosh<9980> sudo cp -R /Downloads/Atmel.ATtiny_DFP.1.3.229/include/avr/iotn416.h /usr/local/avr8-atmel-3.6.1.495/avr/include/avr/      

****
**** And now it works!
****
WWHackintosh<9981> avr-gcc foo.c -mmcu=attiny416
WWHackintosh<9982> 

[MCUdude]

I've just made an experimental Arduino core for the new megaAVR series public. https://github.com/MCUdude/MegaCoreX.

It's probably full of bugs, but I'd appreciate if you gave it a shot if you have some supported hardware. Maybe we can extend the core files to support tinyAVR-0 and 1 in the future? Anyways I've done all the testing with ATmega4808 and 4809 since I'm having some trouble with the 32kB variants. Weird bugs like crash if I put 4 or more characters in the serial TX buffer. I'm currently waiting for a new toolchain to be built.

[leachim6]

Hey Folks,

I've been following the development of this since #174 was created. I'm a sysadmin by trade, not a developer, so I'm not sure I'd be very useful there. However! In searching for an affordable UPDI programmer for these cool new chips I found this:

It's called the MPLab SNAP https://www.microchip.com/developmenttools/ProductDetails/PartNO/PG164100

It's a no-frills version of the (quite expensive) PickIT 4 and fully support UPDI for about $15 from Arrow.

Hope it helps!

[mraardvark]

@leachim6 Be aware that the Snap needs a hardware mod to work properly with AVR UPDI, as mentioned in the MPLAB release notes/readme:

10.2   AVR UPDI Support

A 1K ohm pull-up resistor must be installed between the MPLAB Snap ICD ICSP connector's (PCB reference designator J4) pin 4 (PGD) and pin 2 (Vdd) to allow proper UPDI programming/debugging support for AVR parts that support the UPDI interface.

In addition Snap does not have 12V capability, so you can lock yourself out.

[MCUdude]

@mraardvark @leachim6 Good to know! Does anybody know if the Snap programmer works with Avrdude by using the jtagice3_updi protocol?

[leachim6]

@mraardvark @leachim6 Good to know! Does anybody know if the Snap programmer works with Avrdude by using the jtagice3_updi protocol?

I'll test and report back

[MCUdude]

Thanks!

You might have to add it as a separate programmer in avrdude.conf on order to change the USB PID to match the target.

[SimonMerrett]

Hi everyone, I'm hoping to contribute on the avrdude.conf side but I can't work out how to generate the 32 bit fuse programming strings in the part memory description. E.g. (from attiny84)

memory "lfuse"
         size            = 1;
         write           = "1 0 1 0  1 1 0 0  1 0 1 0  0 0 0 0",
                           "x x x x  x x x x  i i i i  i i i i";

         read            = "0 1 0 1  0 0 0 0  0 0 0 0  0 0 0 0",
                           "x x x x  x x x x  o o o o  o o o o";
        min_write_delay = 9000;
        max_write_delay = 9000;
       ;

I have the ATtiny402 datasheet and I tried to reverse engineer it from the Attiny85 part description and datasheet but my lack of familiarity with avrdude and baremetal in general.

I have googled for guides to writing part descriptions in avrdude but nothing shows how to translate from datasheet fuse settings to avrdude.conf parts. Has anyone got any tips? I'm happy to do this for a range of chips if someone shows me how!

[MCUdude]

I don't own any 202/402 hardware, but it already exists a working avrdude.conf option for these (I think).

See this: https://github.com/MCUdude/MegaCoreX/blob/ba5f29c9df0b1dac81495b7d39995c4bbd2dc459/megaavr/avrdude.conf#L15206-L15229

[SimonMerrett]

Thanks @MCUdude that's working for me (as is the recent version shipping with jtag2updi) but they only include flash and eeprom elements of the part description. I'm interested in setting fuses from avrdude but updi interface doesn't make it easy for me to work out what to put in the .conf part description (ie there's no section of the datasheet which describes serial programming instruction bytes, like there is in other avr data sheets).

[mraardvark]

I think all UPDI devices (so far) have the same common fuse map at 0x1280: memory "fuses" size = 9; offset = 0x1280; ;

[SimonMerrett]

@mraardvark thanks, I hadn't noticed this. Do you know if there is any way of working out the 32 bit serial programming strings for avrdude.conf from the 9 byte FUSE section?

[mraardvark]

@SimonMerrett - I am no avrdude.conf expert, but I suspect the 32-bit strings are the SPI programming sequences, which have nothing to do with UPDI at all.

[SimonMerrett]

Yes, I think you are right, sadly!

[freemovers]

A couple of months ago a new toolchain was build with support for all the tinyAVR-0, tinyAVR-1 and megaAVR-0 series (see MCUdude comments above as well). Back then it was a special build to test the progress, but it looks like it is standard in the latest megaAVR board release 1.8.1 with the support of the new Arduino Nano Every. I had to make a minor change to wiring.c line#379 where PORTMUX.USARTROUTEA was set, but that is not available for the ATtiny. In boards.txt file I added the ATtiny1616 with the ATtiny specifications. It is great that the clock for millis is part of the flags, so it was easy to change it to TCB1 instead of TCB3. Next I created a custom variance file with the correct pin-out for the ATtiny1616, and updated the platform.txt with some changes to: tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} -p{build.mcu} -c{upload.protocol} -P{serial.port} -e "-Uflash:w:{build.path}/{build.project_name}.hex:i" After that I was able to upload a sketch from Arduino using the modified AVR JTAG ICE to a break-out board of the ATtiny1616. I can start a repository, but it might make sense to make it part of the SpenceKonde ATtinyCore? Let me know your thoughts. I started a project on Hackaday.IO as well were I posted some pictures: https://hackaday.io/project/165881-attiny1616-break-out-board-for-arduino

[SpenceKonde]

Woah!

Amazing. I think it should be a separate core, since (as I understand) it has different dependencies and doesn't share any libraries, but I'm happy to maintain it and now that we have something working, I could try to expand it to more parts - it looks like Atmel released a whole ton of them. I guess I should hit up digikey and get some of these parts.

I made a new repo for it https://github.com/SpenceKonde/megaTinyCore - want to submit it there?

[freemovers]

Excellent! I can send you some of the break-out boards when you give me your address (I don't know how to PM on Github, any suggestions?). I will commit the original Arduino code and make my changes after so that we can keep track of the differences between the two.

[per1234]

The offer I made earlier in the thread still stands:

If dev boards or chips are needed to make this happen I'd like to donate to that cause. I recently started a new job and am earmarking part of my first paycheck to go back to the Arduino community that helped me get here. This is definitely a worthy cause.

[SpenceKonde]

Email me - spencekonde@gmail.com

[WestfW]

BTW, I've been working on a board with ATmega4809, pin-compatible with the Uno WiFi 2, but having ONLY the core processor. https://hackaday.io/project/165661-freeduino-4809

There's a problem using the ICSP connector for programming, since Uno-like projects expect SPI to be there, and the 4809 uses a separate UPDI pin. On the plus side, the UPDI pin is dedicated, and the way I read it, the programmer doesn't need access to RESET at all.

However, I haven't had any luck using a SNAP to program a 4809 :-( (A PICKit4 works fine, though.) (No, I haven't built an Uno-like board yet. I also built a DIP 4809 (did y'all notice that the 4809 is now available in a 40-pin DIP?) https://photos.google.com/photo/AF1QipO8DDeTjznXb-ADBSy9YsbH2pKPi71LcT-v1BbF

The 0/1 series do bootloader "support" differently than previous chips, with the protected bootloader section at the beginning of memory instead of the end. (which I dislike, since it means your application has to be aware at link time whether it will be loaded by a bootloader or not.) OTOH, you can set the whole memory to be the "bootloader section", which I think leaves you in the same place as the old tinys with self programming but no bootloader support. In theory, that'd be a small modification of optiboot's virtual boot partition capability.

[SpenceKonde]

Hey guys - this is happening! https://github.com/SpenceKonde/megaTinyCore Follow the repo for updates (be aware, github notification emails will be coming fast and furious).

There are going to be a lot of opportunities for help that don't require being comfortable with core programming. Here's one - filling in a spreadsheet of feature lists

https://github.com/SpenceKonde/megaTinyCore/issues/34

[MCUdude]

Sorry for bringing this topic back to life, but I have some updates regarding a universal programmer I wrote about earlier.

I've now been able to dump the flash and EEPROM contents of a 32u4 based mEDBG chip and replicate it using a cheap pro micro board. I'm planning to design a small UPDI adapter board for it, but first, we should agree on a pinout we all can live with.

Here are some important features (to me at least)

• 6-pin header, just like our old, trusty ISP header
• Vcc on pin 2 and GND on pin 6
• Compatible with the official Atmel UPDI pinout See pic below)
• Would be nice if it could carry RX and TX signals too

This is how the "official" Atmel pinout looks like:

Here's my final suggestion: Again, the CLKI is a pure clock signal that can be used to recover chips with bad fuse settings.

The adapter board I'm planning to order looks like this:

Has anyone any thoughts on the "new" UPDI pinout? Pros and cons? is the adapter board missing any vital features? I assume something like this would be perfect for the small boards you sell @SpenceKonde

[MCUdude]

Oh, here are the schematics for it too.

[SimonMerrett]

@MCUdude it looks great. I will probably use it with an 8 pin IDC socket so will make an adapter to go with your sensible 6 pin arrangement.

Would it be possible to have a 2 pin jumper on the 5V line so that you can program chips that are supplied by e.g. 3.3V from their own regulator/battery? Sometimes it's nice to leave the programmer in situ while using a power supply to test what happens to the device under test with different voltages.

Is the 330R from a reference design? the jtag2updi HW is using a 4.7k resistor, so wondering if it needs to be so low (thinking about protection in both directions).

Thanks.

[MCUdude]

Would it be possible to have a 2 pin jumper on the 5V line so that you can program chips that are supplied by e.g. 3.3V from their own regulator/battery? Sometimes it's nice to leave the programmer in situ while using a power supply to test what happens to the device under test with different voltages.

To prevent the programmer from powering the target? That's definitely doable, but maybe it should have a 3.3V regulator on board too? This way we can select between 5V, 3.3V and no target power with a single jumper.

Is the 330R from a reference design? the jtag2updi HW is using a 4.7k resistor, so wondering if it needs to be so low (thinking about protection in both directions).

I'm using 330R because that's used with all mEDBG circuits I've seen so far. Have a look at the Uno Wifi Rev2 schematic for instance.

[SimonMerrett]

This way we can select between 5V, 3.3V and no target power

Nice!

that's used with all mEDBG circuits I've seen so far

Fine, just wondering really!

[MCUdude]

I'm thinking about adding a buffer to the TX line. However, it's not that easy to automatically select the buffer voltage based on the voltage select jumper, because it should work even with no jumper at all. Will there be a problem if I just connect the TX buffer to 3.3V? This will cause the TX line to switch between 0V and 3.3V no matter what setting the voltage select jumper has.

[SimonMerrett]

That sounds fine to me. But I hope you're getting input from other people too!

[MCUdude]

But I hope you're getting input from other people too!

Yeah, would love some input from others too, even if they agree. I'd like to know if there will be a problem if the RST line isn't present. It's not needed for "regular" UPDI programming AFAIK and most of the new tinys doesn't even have a dedicated RST pin. But in the UNO Wifi Rev2 schematic it's connected to PB5 on the 32u4 through a 330R resistor.

[SpenceKonde]

Definitely agree with voltage select jumper. I'd throw a 1117-series regulator on there for the 3.3v, for sure.

You don't need a buffer on the TX line - a series resistor is enough - that plus the protection diode will keep the target safe (I would probably do 2.2k though).

I would suggest adding a 3-pin header for just UPDI, power, ground, without the resistor - that will ease connection to boards that don't have the full 6-pin header. Gnd should go in the middle so that reversing the connector is non-destructive. Of course, there's some self-interest here, as I have a line of boards with that sort of 3-pin UPDI header and the 4.7k resistor on the board - the xy6 and xy7 versions are already up on Tindie https://www.tindie.com/products/drazzy/attiny32171607-dev-board-arduino-compatible/ https://www.tindie.com/products/drazzy/attiny32161606-dev-board-arduino-compatible/

I would be uncomfortable with just 330 ohm resistor there if that's going to be connected directly to the UPDI pin without any additional resistor. That may work for boards where the programmer and target are both running at same voltage, but I would imagine it could cause problems when they are not.

[MCUdude]

Definitely agree with voltage select jumper. I'd throw a 1117-series regulator on there for the 3.3v, for sure.

Yes, I'm adding a 1117 regulator for sure.

You don't need a buffer on the TX line - a series resistor is enough - that plus the protection diode will keep the target safe (I would probably do 2.2k though).

The reason why I'm adding a TX buffer as well is that I have a pile (5000+) of 74LVC1G125's. It doesn't cost me anything to add it. I'm also switching out the 74HCT1G08 buffer for the RX line to an LVC1G125 to keep the BOM low.

I would be uncomfortable with just 330-ohm resistor there if that's going to be connected directly to the UPDI pin without any additional resistor. That may work for boards where the programmer and target are both running at the same voltage, but I would imagine it could cause problems when they are not.

AFAIK the UPDI line doesn't have protection diodes (OK, probably a high-voltage zener or TVS), and is 12V compatible. "forcing" 5V into a 3.3V device shouldn't be a problem really. But it's simple enough to swap out the resistor for a different type.

I would suggest adding a 3-pin header for just UPDI, power, ground, without the resistor

The problem with this is that now we got two "standards" we got to follow. The Mega0, Tiny0 and Tiny1 series is still quite new, and now we have a chance on agreeing on one pinout for programming before they get "too popular". Another thing is space on the PCB. The board would be significantly longer when a target voltage selector and a three-pin UPDI connector (with silkscreen labels) is added.

[MCUdude]

BTW I'm going to open source everything when I'm done. Including production files so that's easy to order PCBs even if you can't open the Altium project files.

[SimonMerrett]

now we got two "standards"

I think those of us who want to go smaller can just make a breakout adapter. I will be using SOICbite with 8 pin IDC adapter, Spence would need a 6 -> 3 pin adapter.

One way you could accommodate @SpenceKonde 's request is to have a 2-way solder jumper to pin 4. The default NC is Tx, the other NO is UPDI. This would introduce a twist in the wire unless you adopt Spence's suggestion to make GND in the centre (pin 4). Or you could offer 2x 2-way solder joints to allow pin 2 to be GND (default) or UPDI and pin 4 to be Tx (default) or GND. The solder jumpers could go under the board to save surface space on top.

[MCUdude]

One way you could accommodate @SpenceKonde 's request is to have a 2-way solder jumper to pin 4. The default NC is Tx, the other NO is UPDI. This would introduce a twist in the wire unless you adopt Spence's suggestion to make GND in the centre (pin 4). Or you could offer 2x 2-way solder joints to allow pin 2 to be GND (default) or UPDI and pin 4 to be Tx (default) or GND. The solder jumpers could go under the board to save surface space on top.

That sounds like a lot of hassle to achieve with solder jumpers, especially while keeping the same pinout as I've come up with (Vcc on pin 2, GND on pin 6). Anyway since the UPDI line only has a 30R resistor in series, it can still be used on a board where a 4.7k resistor is already present.

Here's what it would look like with a target power jumper. The reason why I've chosen TRGT and STAT instead of TARGET and STATUS is that inverted silkscreen tends to be very ugly on a finished PCB if the text is too small. Especially when ordering from cheap board houses.

Here's how the status LED will behave (screenshot from the ATtiny817 Xplained Mini user guide)