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.
I like these new AVR chips. For whoever is interested in programming the AVR 1 and 0 series using PlatformIO I wrote a similar guide here: http://www.bitbanging.space/posts/programming-attiny-1-series
I’m also using pyupdi but once PlatformIO is set up you just need to press a button to upload the code.
Really? Quite a slow monday…
I thought it was interesting, I was unaware of UPDI (mentioned in comments below), and the idea of programming this device with minimal tools was good to know.
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.
seriously! my dominant response on reading this thing was to get mad at PIC ICSP all over again
Why doesn’t avr-gcc include out of the box support for newer chips? Is it some sort of copyright issue?
Probably stability testing.
It’s used in professional production, so no fast & loose programming.
Basically opposite of win10
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.
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.
They actually document the debugging in the datasheet. May be we can see some open source hardware debuggers one of these days?