I've recently moved from Arduino to "bare AVRs", and now making my own PCBs. Most recently, I've decided to explore the newer AVRs, and specifically I've chosen attiny1614 (very low cost, hobbyist-friendly SOIC-14 package) -- I see it as attiny84 replacement.
Just want to share my experience and maybe start a discussion on a few things.
Toolchain:
Having a preference for free (as in freedom) software and small footprint, I was able to successfully set up a minimal toolchain on Linux (Ubuntu) without having to use Atmel/Microchip IDE.
I've documented the process on my github: https://github.com/vladbelous/tinyAVR_gcc_setup -- hopefully someone might find this useful.
Some key takeaways:
- These new AVR parts are much closer to atxmega rather than to (previous) attiny/atmega parts. In GCC, it is classified under avrxmega3 architecture.
- Recent GCC versions natively support avrxmega3 / attiny1614, but there's no support (yet?) in avr-libc (as of version 2.0.0). My workaround here is to get a few additional files (in my case, just 5) from Atmel/Microchip packs.
- avrdude can be used for programming using El Tangas (thanks!) modified avrdude.conf and jtag2updi firmware -- it allows you to setup another AVR as the programmer (similar to the popular "Arduino as ISP" approach). However, the avrdude.conf modifications are not yet upstream (as of version 6.3).
Questions:
Is there any information on adding these new parts to upstream avr-libc (i.e. http://download.savannah.gnu.org/releases/avr-libc/)? Do we have anyone from avr-libc in these forums?
When (if at all) do we expect the jtag2updi work of El Tanga (or some other form of UPDI support) to be added to mainline avrdude?
I think it's quite important to have a simple/small cross-platform toolchain if these new parts are to become more popular in hobbyist community.
avrxmega3 architecture:
Having some experience with (older) attiny and atmega parts, and no experience with atxmega, a lot of things ended up a surprise to me during programming, causing a non-trivial debugging time.
One the one hand, some architecture unification in 8-bit AVR parts seems like a good idea to me (new megaAVR 0-series is also avrxmega), and personally I'm ok with it being atxmega-like, but I'm worried that in hobbyist community there's much more experience/material on the (previous) attiny/atmega, and atxmega is less known. What do you think about this?
Also, do we know if this is indeed Microchip's plan to have all new 8-bit AVRs use avrxmega architecture, or do we expect new attiny/atmega-like parts to come too?
Attiny1614-based board:
I've designed (and had it manufactured) a PCB for attiny1614 and put all the design files and further information here: https://github.com/vladbelous/avr-attiny1614-mini
So far, the board works well, and I was able to use UART, timers and even drive an APA106 programmable LED (similar to the popular WS2812). I'm not using any frameworks, just C++ with avr-libc.
One issue I ran into is UPDI/RESET pin: you have to select either UPDI functionality or RESET functionality via a fuse (default is UPDI). If you choose to make it a RESET source, you'll need to apply 12V to program it again.
I've recently had an issue in one of my designs, where a small leakage through a turned-off MOSFET ended up harvested enough by a boost converter circuit to "partially" start the connected AVR MCU. "Partially" means it got stuck in some non-working condition such that even after supplying a stable 5V, a physical RESET was still necessary.
Basically, I learned the importance of RESET signal and voltage supervisors, but now it appears the new attiny parts are somewhat inconvenient in this regard -- or am I missing something here?
What are your thoughts on the new tinyAVR 0/1-series and megaAVR 0-series parts? Is it the future of AVR for hobbyists?
I'm quite interested in seeing (and contributing to) it becoming more popular, but it's not yet clear if there are enough stakeholders. I know the new Arduino boards are using atmega4809 (which is megaAVR 0-series), but I have some doubts it will lift off.