Many readers will be familiar with Microchip’s ATtiny85, which has been a popular choice for DIY projects in the past for its low price and (for the time) small size. But those looking for a more modern and capable 8-bit chip may find the ATtiny1616-MNR of interest. It offers expanded flash storage, more GPIO, and ditches SPI programming in favor of UPDI — a protocol that can be done using nothing more than an USB-UART converter and a resistor.
But here’s the catch: the new chip is only available in SMD and there are far fewer tutorials for it! That’s why [Bradán Lane] has created ACK1, a cute little AVR Coding Kit for those of us who want to play with the ATtiny1616 and a companion for his free and open-source course.
The board contains an array of 6 by 7 LEDs in a charlieplexed configuration, a large piezo buzzer, two push buttons, an on/off switch, and a CR2032 battery holder to keep it on without the need for a cable. The kit looks gorgeous in its white-on-black theme with gold plated contacts and can be had for $20 on Tindie at the time of writing.
The ATtiny1616 itself runs at up to 20 MHz and has 17 GPIO pins, 16 KiB of flash storage, 2 KiB of RAM, and 256 bytes of EEPROM for configuration — making it roughly on par with the original Arduino Uno.
The course that goes hand-in-hand with the ACK1 is all about the features of the ATtiny1616, from the basics of using the programmer to reading the buttons, using timers, driving the charlieplexed LEDs, storing data in the EEPROM and much more. Though it does not cover the basics of C, the course is free, and even licensed MIT, so that anyone can share it and improve upon it.
If you enjoy seeing beautiful microcontrollers, you’ll definitely want to see the stylish Uno Plus+.
I have started using this series of AVR chips. There are very few examples online but once I managed to set them up they turned out to be wonderful chips. The peripheries are very logical. I love them. They are also cheap compared to the “old” ones.
How does it compare to the RP2040? It’s my new go to controller, for being cheap, fast, small and very capable.
They are different beasts. Though they appear to have similar prices, the ATTiny1616 basically requires no external components to work (save a couple passives), while the RP2040 will need a flash chip and I think external clock at a minimum to work.
On the other hand, the 2040 is an order of magnitude more powerful. So basically it depends as always on your budget constrains and what you need at that particular time, and how confortable you feel tinkering at low level and how tight your budget is.
heh but if it’s SMD then the attiny1616 needs an external component called a ‘breakout board’ for my casual hobbyist use, which is more nuissance and cost ($20 vs $4?) than the rp2040 pico board.
i really liked the DIP-8 PIC12s for all the reasons you laid out…but once you leave DIP, those advantages disappear from my particular vantage.
The beauty of AVRs is their dead simplicity of implementation. It won’t be nearly as performant as the RP2040 (especially if you make use of its nice DMA, PIO or second core), but on the AVR’s side you have:
-More intuitive (IMO, though this may just be because of familiarity) timer/PWM. I’m not a huge fan of how RPi tried to “PWM”-ify timers in the RP2040, I feel it’s just obfuscation and decreases flexibility
-Fewer externals (especially SPI flash) needed
-Rock solid peripherals (RP2040’s ADC, for example, has a mis-sized resistor in its ADC’s ladder. Not a big deal unless you’re really leaning hard on its precision, though). Tons of flexibility on all the peripherals with great defaults in the registers.
-Dead simple instruction set. ARM is a real pain if you have to do any kind of assembly. It also has very predictable instruction cycle count, making true real-time operations almost trivial compared to any ARM instruction set. ~~Everything~~ you need is in a non-dense 160pg manual, whereas ARM is a huge headache.
-EZPZ toolchain. Have mainline GCC? You’re set. The RP2040’s SDK is nice, but AVR is just that much more convenient.
-Simpler programming (debatably). I’d rather have a serial conversion board/chip than deal with the RP2040 needing to be power cycled to program it (a real drag on the Pico, which is missing the second button that IMO is requisite). For people just getting started, though, I can see the benefits of it showing up like a USB drive that you drop your binary file onto.
As other alrady mentioned, the RP2040 is totally different. For me the real question is how does it compare to something like the STM32G0 series? They are small chips (starting at 8 pins), but usually have much more RAM, FLASH and more advanced peripherals than any AVR I ever used. Similar chips are also available from other manufacturers. I don’t see any reason to still use AVRs, however I’m probably missing something important, because otherwise it would make no sense for Microchip to release these new AVR chips.
As fiddlingjunky has mentioned the AVR commands have predictable execution time. And in my opinion the periphery is a little bit more logical than in STM32. But this may be my bias. I also find the STM32 periphery good but not as good as the AVR series.
I have also worked with ARM core based chips whose periphery and its documentation was very bad. I think in the ARM MCU world there are bad chips.
The faster clock does not help much because the AVR executes 1 command every cycle while most ARMs don’t. Ok, the command can move around 32 bits but in cases when you only need to move a single bit then the 8 bit MCU can even be faster. You have a chance to toggle a pin in 1 command that executes in 1 cycle. It is not possible on the ARM MCUs. So in case you don’t have much data to process but only classical MCU tasks like controlling something then the AVR may be easier to use.
The size of program memory is something that can be compared just by the datasheet. I don’t have info about how the code size compares but I would guess that for simple programs the AVR code is smaller. For me the high end of AVRs were enough for all my hobby projects programmed in C. Some projects programmed in ASM could even fit 2K. The ones I program professionally would not fit the program memory of the AVRs. So it always depends on what task you have. For projects which fit the AVRs I use them because they are my favourite.
One thing I forgot: I would bet that IRQ reaction time is also faster on AVR. I am not totally sure but I have measured it on the AVRs and it was very few cycles overhead and in some cases you can implement the IRQ handler to only access registers (if you allocate registers statically to functions).
I have not measured yet the ARMs that I work with exactly but just by looking at the specs I am almost sure that it is much slower than the AVR IRQ handlers. It is a nice feature in ARM that you can use the caller saved registers without pushing them onto stack even in the IRQ. But it has its cost: the IRQ subsystem has to save these regs automatically and that can be a constant overhead. I don’t know how optimized its implementation is on real processors, maybe they do it parallel and fast. Has anyone measured these things on ARM chips?
i agree with the gist of both your comments but ARM microcontrollers aren’t all as bad as all that. it’s definitely not as straightforward as with an AVR or PIC. but if you’re careful, you can achieve high speed controlled-timing bit banging on the ARM microcontrollers i’ve used. and a lot of them really do have a good set of peripherals. especially when we start looking at the RP2040 with its PIO peripheral, it can do almost anything…but i’ve looked at the documentation for the PIO and it’s not really very clear how to use it. it’s very capable but you have to bring some imagination to figure out how to bend it to your specific need. it’s certainly easier to reason about how the AVR or PIC instruction set works with its GPIO peripherals.
I have never actually ran out of flash, or ram(well, there was this one time with a pic that had 264 b ram. Bytes, not kb.)
And once when I wanted to use u8g to display text, and I realized that it would not fit. Since the library was 98% of the program size.
Found a different library and then had mostly free space again.
But I guess that might not be everyones fancy, and some might prefer a CPU that just can cope with such waste of space without any extra steps, that’s fine too.
Not sure I actually have a point, I guess I just wanted to say that.
And that these mcus are not restricted, they can pretty much do anything*, and a million times faster than a human.
*Anything typical MCU stuff, if you are doing data science or video, then I’d consider my component choices first.
Why use anything more, when this 8bit MCU is probably overkill for 90% of use cases already?
Therefore, the hobbyist use it based of familiarity, and at least in my case also fondness.
But for atmel it’s of course money, and a solid business case that’s not based of any hobbyist use at all.
Other things not mentioned already by others:
RP2040 has more GPIO pins, which are officially 3.3v. Unofficially it might not fry when up to 5.0v is supplied to an input pin under very certain circumstances, but the pins are not considered 5v-tolerant for various reasons.
Like other AVR chips it appears the ATtiny1616 GPIO pins are 5v when the VDD is 5v, and 3.3v when VDD is 3.3v. (Absolute maximum allowed input voltage is VDD+0.5v, general operating maximum is VDD+0.2v)
Supporting a new protocol (UDPI) sounds good, but – did they really drop SPI support?
There’s a whole bunch of peripheral chips needing that, in order to connect.
No, it has SPI, I2C, and UART (far nicer than the ATtiny85 as similar.)
It just dropped (incoming) SPI as a device programming protocol.
There are several other ATtiny1616/etc boards available on Tindie, including some from Spence Konde, author of the Arduino Core that supports these chips.
I wish Microchip would do a more exact replacement for the tiny85, though. All the new 8pin chips have less than 8k of Flash, and no DIP packages.