Minimal TinyAVR 0 Programming

When [Alain] wanted to use some of the new TinyAVR 0 chips — specifically, the Attiny406 — it seemed overkill to use the Windows IDE. There are plenty of sources of information on programming other AVR chips using simple command line tools, but not for these newer 0-series parts which use a new programming protocol known as UPDI. That led to a deep diving into how to program a TinyAVR 0 with a text editor, makefile, and USB-to-serial cable.

The Attiny406 has 4K of flash, 256 bytes of RAM and can run at 20 MHz with no external clock. You might think programming would be similar to a regular AVR part, but these tiny devices use UPDI (Unified Programming and Debug Interface) which uses 3 pins for programming. Older devices used different protocols.

It is very easy to create a UPDI programmer. A USB to logic-level serial cable and a 4.7K resistor is all it takes. There’s Python code that knows how to drive the protocol, too. You can also use the logic-level serial port on the Raspberry Pi with some device tree modifications explained in the code’s documentation.

[Alain] made a nice breakout board for the device. It fits a breadboard, allows for 5V or 3.3V operation, and has an LED and switch. Nothing fancy, but handy. Once you know how to ship a hex file to the chip, the rest is pretty standard. While the AVR version of gcc doesn’t cross-compile for the ATTiny out of the box, there is a device pack from Microchip that enables that feature.

The trend is to go to bigger processors, not smaller, but when you need to cram something in a small space, save a few pennies per unit, or draw very little power, these tiny processors can be just the ticket. The processors may be small, but if you work you can do some pretty big things with them.

10 thoughts on “Minimal TinyAVR 0 Programming

  1. So like, can we just make this UPDI thing the standard for all things that need programming, period, from now on? At most, this stuff should only need 2 wires, but doing it with 1 data line is awesome.

  2. I really don’t like Atmels’ (now Microchip’) idea of yet another programming interface each year or so. For me it’s pretty simple. If the AVR processor don’t work with avrDUDE and usbASP, then I ‘m not interested.

    Also, I don’t like the idea of software development on small processors much. A bigger processor with room for debug statements, extra pins for adding an LCD, serial port and / or using pins to spit out debug info to a logic analyser is a big benefit for developing firmware.

    And on top of that. All the subtle differences between their peripheral hardware makes it hard to port an application to another variant, and write and debug on a bigger AVR, and then deploy on a smaller.

    A few years ago I switched to ARM uC’s.
    With Atmel (now mircochip), it’s always been this timer has this and that bit, while that other timer has an extra register here, but is missing that other function. With ARM, you get a description of a timer, and a single line saying, Oh, there are 8 of these timers in this chip.

    It happened a few too many times that i wrote a custom little library for an AVR peripheral, and then had to re write it, just because it used Timer 1, and I badly needed Timer 1 for some other function, so I had to port that lib to Timer2 and even though it was a simple lib it did not work because the timer overflow ISR or some other little detail was different in Timer2.

    Just yuck. never again.

    1. Its literally a USB-to-UART converter + a 4k7 resistor. I probably own a fist full of those.

      I for one, am glad that manufacturers are moving towards open and easy to implement programming method. This is much better than having to buy 100$ programming devices which probably contain a the same microcontroller that you’re trying to program.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.