AboutDxSeries.md

Overall information regarding the AVR Dx-series

In early 2020, as the world was shutting down because of COVID-19, Microchip released the first of their new generation of parts. Along with many exciting features, it also brought one odd relic: a single nail, the meaning of which was clear when the naming of the parts was announced. That was last nail in the coffin of the ATmega branding, and it has been driven securely into place. The Dx and Ex-series have replaced it. The next question is how much longer tinyAVR has. There may well not be anything else called an ATtiny in the future either. Now that the company is no longer ATmel, why would they keep the AT-prefixed brands? And of course, since Microchip has all the creativity that you'd expect from a company that makes microchips and is named Microchip, the new naming system is uncreative in the extreme: AVRffXYpp - where ff is a number, the flash size in kb, XY are two capital letters indicating the chip generation, and family (likely both generation and family will generally go in alphabetical order, with a possible exception for USB-native parts, which could get a U (per the withdrawn DU-series brief) - I imagine "DC" was skipped because that has an obvious meaning in electronics. They will probably skip "F" as a generation letter, too, F being a failing grade in school, not to mention its association with a certain explitive. Certainly, if there is an Fx-series, they'd have to pick some other letter for the family with native USB support. An FU-series wouldn't be a marketing success story.

Specifications of AVR Dx-series parts by family and pincount

Strikethrough value is hypothetical assuming datasheet reflected the available silicon. Non-struckthrough values are actual values after considering all outstanding errata.

	AVR DD14	AVR DD20	AVR DA28	AVR DB28	AVR DD28	AVR DA32	AVR DB32	AVR DD32	AVR DA48	AVR DB48	AVR DA64	AVR DB64
Released	Q3 2022	Q3 2022	Q2 2020	Q3 2021	Q1 2022	Q3 2020	Q3 2020	Q3 2022	Q2 2020	Q2 2020	Q3 2020	Q3 2020
Memory (max) Flash/RAM	64k/8k	64k/8k	128K/16K	128K/16K	64k/8k	128K/16K	128K/16K	64k/8k	128K/16K	128K/16K	128K/16K	128K/16K
Memory (min) Flash/RAM	16k/2k	16k/2k	32k/4k	32k/4k	16k/2k	32k/4k	32k/4k	16k/2k	32k/4k	32k/4k	32k/4k	32k/4k
EEPROM	256	256	512	512	256	512	512	256	512	512	512	512
RWW/NRWW sections	No	No	No	No	No	No	No	No	No	No	No	No
User Row	32	32	32	32	32	32	32	32	32	32	32	32
Boot Row	No	No	No	No	No	No	No	No	No	No	No	No
Max. Frequency (rated, MHz)	24	24	24	24	24	24	24	24	24	24	24	24
Total pins on package	14	20	28	28	28	32	32	32	48	48	64	64
Avail. as TQFP	No	No	No	No	No	7x7mm .8p	7x7 .8p	7x7 .8p	7x7mm .5p	7x7mm .5p	10x10mm .5p	10x10mm .5p
Avail. as VQFN	No	3x3mm .4p*	No	No	4x4mm .4p*	5x5mm .5p	5x5 .5p	5x5 .5p*	6x6mm .4p	6x6mm .4p	9x9mm .5p	9x9mm .5p
Avail. as SSOP (5.3mm wide)	No	No	Yes	Yes	Yes	No	No	No	No	No	No	No
Avail. as SOP (N = Narrow)	Yes, N	Yes, Wide	Yes, Wide	Yes, Wide	Yes, Wide	No	No	No	No	No	No	No
Avail. as DIP (Narrow DIP28)	No	No	Yes	Yes	Yes	No	No	No	No	No	No	No
I/O Pins (not reset/UPDI)	9	15	22	21	21	26	25	25	40	40	54	54
Fully Async pins	11	17	6	6	23	7	7	27	40	42	54	54
UPDI as I/O Pin	Yes	Yes	No	No	Yes	No	No	Yes	No	No	No	No
PWM capable I/O pins	7	13	20	19	19	22 24	21 23	23	36 38	36 38	40 50	46 50
Max simultaneous PWM outputs	5: 3:2(8)	8: 6:2(10)	11: 6:2:3	11: 6:2:3	11: 6:2:3	11: 6:2:3	11: 6:2:3	11: 6:2:3	18: 12:2:4	18: 12+2+4	19: 12:2:5	19: 12:2:5
16-bit Type A Timers - pins ea	1: 2/3/2	1: 6/3/2	1: 6/4/6/2	1: 6/4/5/2	1: 6/4/5/2	1: 6/4/6/6	1: 6/4/5/6	1: 6/4/5/6	2: 34, 9	2: 34, 9	2: 42, 18 9	2: 42, 18
16-bit Type B Timers, (pins)	2: 0	2: 2	3: 3	3: 3	3: 3	3: 5	3: 5	3: 5	4: 8	4: 8	5: 10	5: 10
12-bit Type D pins (**)	2	6	4 6	4 6	8	4 8	4 8	10	4 10	4 10	4 16	4 16
16-bit Type E Timer w/WEX	No	No	No	No	No	No	No	No	No	No	No	No
24-bit Type F Timer	No	No	No	No	No	No	No	No	No	No	No	No
SPI (pin mappings)	1: 2	1: 3	2: 1/1	2: 1/1	1: 5	2: 1/1	2: 1/1	1: 5	2: 2/2	2: 2/2	2: 3/3	2: 3/3
TWI/I2C (pin mappings)	1: 2	1: 3	1: 2	1: 2	1: 3	2: 2/1	2: 2/1	1: 3	2: 2/2	2: 2/2	2: 3/3	2: 3/3
12-bit ADC input pins	4/7	10/13	10	9	14/18	14	13	18/22	18	18	22	22
Of those, neg. diff. inputs	all	all	8	7	all	8	7	all	12	12	16	16
Full differential + PGA	No	No	No	No	No	No	No	No	No	No	No	No
10-bit DAC	1	1	1	1	1	1	1	1	1	1	1	1
Analog Comparator (AC)	1	1	3	3	1	3	3	1	3	3	3	3
Zero-Cross Detectors (ZCD)	1	1	1	1	1	1	1	1	2	2	3	3
Custom Logic Blocks (LUTs)	4	4	4	4	4	4	4	4	6	6	6	6
Event System channels (out pins)	6: 3/3	6: 4/5	8: 3/5	8: 3/5	6: 4/6	8: 4/6	8: 4/6	6: 4/7	10: 6/9	10: 6/9	10: 7/13 11	10: 7/13
On-chip opamps (OPAMP)	-	-	-	2	-	-	2	-	-	3	-	3
MVIO, pins	Yes, 3	Yes, 3	No	Yes, 4	Yes, 4	No	Yes, 4	Yes, 4	Yes, 8	Yes, 8	Yes, 8	Yes, 8
Flash Endurance !!	1k	1k	1k 10k	1k 10k	1k	1k 10k	1k 10k	1k	1k 10k	1k 10k	1k 10k	1k 10k
Pricing, max flash, qty 1	$1.24	tbd	$2.06	$2.19	$1.31	$2.04	$1.19	$1.45	$2.19	$2.33	$2.54	$2.68
Pricing, min flash, qty 1	$0.95	$0.98	$1.66	$1.79	tbd	$1.52	$1.66	$1.79	$1.91	$2.05	$2.33	$2.46

Notes:

• Fully async pins may exceed input pins on the previous line. This is the case when all I/O pins are fully async, even the ones that require disabling reset and UPDI to use. It is not clear whether on DA/DB parts reset set as input is also fully async.
• For (V)QFN and (T)QFP packages my normal shorthand is used: AxBmm .Cp where A and B are the dimensions in millimeters of the package (except height, go read the datasheet if you need to know that), and C is the pin pitch also in mm (including the preceding decimal point of course)
• Event system channel outputs are available on pins 2 and 7 of each port (except on AVR128DAs, where PE4-7 and PB6-7 are "not connected to the event system" according to the errata. , but only one of those per port can be used at one time, though any EVSYS generator can be used by any port with EVOUT pins. Hence this table shows two numbers for the output pins: the first number is the number of simultaneously usable output pins, and the second, after the slash, is the number of total EVOUT pins. Each port input to EVSYS can be used by at most two EVSYS channels (on Dx-series, Ex-series allows every port to generate two event inputs that can be used by any channel). See the Event library documentation for more information.
• On the AVR DD-series, one of the output pins cannot be used unless UPDI is fused as GPIO, as PF7 is UPDI, and an event output option if used as GPIO. This feature is not available on other AVR Dx-series parts.
• Each CCL LUT is associated with exactly one port, which may or may not be present on that part. When present, inputs on the first 3 pins, and output on pin 4 or 6. LUTs without pins can still be used with internal inputs, which is the more interesting application of them. LUTs are associated with, in order, PORTA, PORTC, PORTD, PORTF, PORTB, and PORTG. There is no LUT associated with PORTE. Even and odd-numbered LUTs are not equal: Even LUTs determine the clock for the sequential logic (if used), and can use their own output (or the output of sequential logic, if used) as their inputs. Odd LUTs must use an event channel to get their own output, but can use the output of the even LUT. All CCL LUTs must be disabled in order to reconfigure any one LUT. See the Logic library documentation for more information.
• A LUT can be sacrificed to simply output an event channel if needed, or an EVOUT pin can be used to output the value of a LUT.
• Neither EVSYS nor LUT channel values can be read directly by software.
• AC output can only be on pins PA7 or PC6. ZCD output can only be on pins PA7 or PC7. The ACs on DA/DB parts can each use a subset of the pins on PD and PE. The AC on DD-series can also use a pair of pins on PC as inputs if MVIO is disabled. ZCD inputs are fixed, and output MUXing is broken on DA-series parts and cannot be set individually. See the Comparator or ZCD library documentation for more information.
• The DAC always outputs on PD6. This cannot be remapped. It cannot be internally routed to the OPAMPs on the DB-series, despite the documentation implying that it can be.
• Analog input is available on all pins of PORTD, PORTE, and pins on PORTF that are neither RESET nor UPDI. On DD-series only, PORTA pins can be used, and pins on PORTC for analog inputs (to ADC, and comparator for PC2/3) ONLY if MVIO is disabled.
• The AVR Dx-series ADC is only kinda-sorta differential. In differential mode, the maximum voltage on both pins must be lower than the reference voltage (making it equivalent to having 2 ADCs and simultaneously starting a conversion on both and taking the difference; you can't use a lower reference voltage to "zoom in" on a difference between two voltages where one or both is higher than the reference. On a true differential ADC, like is slated for the EA-series, that is valid). See the analog reference for more information.
• For TCAs, only pins on a single port can be used at any one time. The number of pins on each mux option is shown for parts with only one TCA. It becomes too cumbersome to list in the table (not to mention rather less critical - the 48+ pin parts have enough PWM capable pins that you probably don't have to worry).
• The third number on max simultaneous PWM outputs is if you go balls to the wall, and use
• The RESET pin can be used as an input (PF6) instead of reset. It cannot be used as an output, ever.
• The UPDI pin can be used as an input or output (PF7) instead of UPDI, requiring HV programming to reprogram. After an HV override of that pin.
• The OPAMPs have fixed pin mapping. All pins are always available on parts that have builtin OPAMPs.
• (SPI, USART, TWI) Only pin mappings which are not missing the "primary" pins (TX and RX for USART, SCK, MOSI and MISO for SPI) are included for those peripherals. For TWI, options that are strictly inferior are not included in that count (this would include the case where only the dual mode pins are available, and those pins are the full function pins on another multiplexing option which does not provide dual mode pins. This happens to TWI0 on DD14, or where the a multiplexing option has the same full function pins as another mux option but no dual mode pins). In these cases, that mux option cannot do anything that cannot be done by another option which offers more functionality, and is not counted here.
• * VQFN version of the AVR64DD20 is NOT listed as an available package on the preliminary datasheet, and does not appear to be planned. I do not believe the die quite fits in the tiny VQFN package.
• ** Only 2 independent TCD timer channels exist, but are distributed in groups of 4. Within each group, 2 pins are bound to a specific channel, while the other to can choose - though DxCore does not expose the ability to for pin C to output pwm B nor pin D to output pwm A. On DA and DB-series parts, current errata leaves only the first group of pins functional. The DD-series has 2 pins which appear in two groups (PA4 and PA5). The AVR DA-series is impacted by errata that prevent the PORTG mapping from working.
• !! Flash endurance was initially spec'ed at 10k for all Dx-series parts. Shortly before the release of the DD-series, they issued an erratum ("it's broken, but we'll fix it some day, maybe") for the DA/DB parts, which was subsequently changed to a "datasheet clarification" ("it's broken, and we ain't gonna fix it") - presumably their investigation concluded that there was no ready solution (likely this is related to the word-write capability that these parts have). The DD-series was released with the datasheet specifying 1k rewrite cycles. If the limit in realisic conditions of use is 1k, that is low enough that it would constrain use of the devices in cases which relied frequent self-programming. What isn't clear though is whether the lower limit is only observed in adverse conditions (I am of the understanding that tempeature has an impact) or if even mild and typical conditions will see such low endurance. It obviously brings consideration of the flash endurance to the table in a lot of scenarios where it could normally be neglected.
• There are large differences between the errata impacting the available hardware DA and DB parts (with DBs having less), and with the 128k flash versions having more than the smaller flash versions - they were released first. The AVR128DB also received a package of fixes almost immediately, likely due to a severe bug impacting the ADC when making single-ended measurements, and two problems with the OPAMPs in the initial silicon (A4 revision). Very few of those made it into the wild - even the parts I had that arrived before the preliminary datasheet had even been posted are A5. The DD-series has very little errata.
• Pricing is from late 2022 and obviously subject to change. Industrial temp spec, not in tape, least expensive package variant (see below - either QFN of TQFP, unless 14 pin parts which only have SOP option Microchip Direct, without any of the (significant) quantity discounts), non-VAO version.

Specifications of AVR Ex-series parts by family and pincount, plus the DU

	AVR EB14	AVR EB20	AVR EB28	AVR EB32	AVR EA 28	AVR EA32	AVR EA48	AVR DU14	AVR DU20	AVR DU28	AVR DU32
Released	TBA	TBA	TBA	TBA	Q1 2023*	Q1 2023*	Q1 2023*	"by end of	the year?	(which yea	r?)
Memory (max) Flash/RAM	32k/3k	32k/3k	32k/3k	32k/3k	64k/6k	64k/6k	64k/6k	32k/4k	32k/4k	64k/8k	64k/8k
Memory (min) Flash/RAM	8k/1k	8k/1k	8k/1k	8k/1k	8k/1k	8k/1k	16k/2k	16k/2k	16k/2k	16k/2k	16k/2k
EEPROM	512	512	512	512	512	512	512	512	512	512	512
RWW/NRWW sections	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No
User Row	64	64	64	64	64	64	64	512	512	512	512
Boot Row	64	64	64	64	No	No	No	256	256	256	256
Max. Frequency (rated, MHz)	20	20	20	20	20	20	20	24	24	24	24
Total pins on package	14	20	28	32	28	32	48	14	20	28	32
Avail. as TQFP	No	No	No	7x7mm .8p	No	7x7mm .8p	7x7mm .5p	No	No	No	7x7mm .8p
Avail. as VQFN	No	3x3mm .4p	4x4mm .4p	5x5mm .5p	4x4mm .4p	5x5mm .5p	6x6mm .4p	No	??	4x4mmm .4	5x5mm .5p
Avail. as SSOP (5.3mm wide)	Yes	Yes	Yes	No	Yes	No	No	??	??	??	??
Avail. as SOP (N = Narrow)	Yes, N	No!	No	No	Yes, Wide	No	No	??	??	??	??
Avail. as DIP (Narrow DIP28)	No	No	Yes	No	Yes	No	No	No	No	??	No
I/O Pins (not reset/UPDI)	10	16	22	26	22	26	40	7	13	21	23
Fully Async pins	12	18	24	28	24	28	42	9	15	23	25
UPDI as I/O Pin	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
PWM capable I/O pins	10	16	22	26	22	26	44	TBD	TBD	TBD	TBD
Max simultaneous PWM outputs	4 or 6	4-6 or 6-8	4-6 or 6-8	4-6 or 6-8	13: 9:4	13: 9:4	16:12:4	3-4	6-10	TBD	TBD
16-bit Type A Timers - pins ea	No	No	No	No	2: 18, 6	2: 22, 6	2: 34, 12	1: 2/2	1: 6/2	1:6/6/2	1:6/6/6
16-bit Type B Timers, (pins)	2: 0	2: 2	2: 2	2: 2	4: 4	4: 6	4: 8	2: 2	2: 4	2: 4	2: 6
12-bit Type D pins (**)	No	No	No	No	No	No	No	No	No	No	No
16-bit Type E Timer w/WEX	1: 2/3/4/6	1: 8/4/4/6	1: 8/4/8/2/6	1: 8/4/8/6/6	No	No	No	No	No	No	No
24-bit Type F Timer	1: 2	1: 2/2	1: 2/2	1: 2/2/2	No	No	No	No	No	No	No
USART (pin mappings)	1: 5	1: 6	1: 6	1: 6	3 5/2/1	3: 5/2/2	3: 5/2/2	2: 2/1	2: 4/1	2: 4/1	2: 4/1
SPI (pin mappings)	1: 2	1: 3	1: 5	1: 5	1: 5	1: 5	1: 5	1: 1	1: 2	1: 2	1: 2
TWI/I2C (pin mappings)	1: 2	1: 3	1: 3	1: 3	1: 3	1: 3	1: 3	1: 1	1: 2	1: 2	1: 2
12-bit ADC input pins	8	14	20	24	24	28	28	-	-	-	-
Of those, neg. diff. inputs	all	all	all	all	all	all	all	-	-	-	-
10-bit ADC input pins	-	-	-	-	-	-	-	5	11	17	21
10-bit DAC	No	No	No	No	1	1	1	No	No	No	No
Analog Comparator (AC)	2	2	2	2	2	2	2	1	1	1	1
Zero-Cross Detectors (ZCD)	No	No	No	No	No	No	No	No	No	No	No
Custom Logic Blocks (LUTs)	4	4	4	4	4	4	4	4	4	4	4
Event System channels (out pins)	6: 3/3	6: 4/5	6: 4/5	6: 4/6	6: 4/6	6	6	6	6	6	6
On-chip opamps (OPAMP)	-	-	-	-	-	-	-	-	-	-	-
MVIO, pins	No	No	No	No	No	No	No	No	No	No	No
Flash Endurance	1k	1k	1k	1k	10k 1k	10k 1k	10k 1k	1k likely	1k likely	1k likely	1k likely
Pricing, max flash, qty 1	???	???	???	???	???	1.79	2.05	TBD	TBD	TBD	TBD
Pricing, min flash, qty 1	???	???	???	???	???	???	1.79	TBD	TBD	TBD	TBD
* - Availability was initially almost nil as though some manager had his bonus linked to "did this chip ship in Q1?") - but the initially pessimistic ship dates have improved significantly, and general availability of EA-series parts was fairly good at the end of Q2, all but the 2 8k cheeseboxes were available (those appear to have been . They all have the same punishing errata, unfortunately.. Notes:

• The AVR16EB headers are out!!! Read em and weep:
  • Only 4 independent outputs on TCE.
  • A lot of wacky stuff about scaling that didn'nt make much sense
  • WEX lets you do deadtime insertion.
  • TCD-esque dither.
• Yes, there is a PLL, it's way cooler than any of the ones we've seen before, too.
• TCF is a strange strange duck. I don't entirely understand what it will be capable of. What crazy things will it do!? Just getting to use that PLL as clock source gives you a very powerful toy. TCB gained a feature the purpose of which I do not understnd.
• Yes the DU product brief said it was getting only a 10-bit ADC. I am not certain that this is correct, and certainly hope that was in error. No product brief to date has fully reflected the product that was released, though they're close. We'll know when the headers are released.
• Microchip appears to have forgotten how to make flash memory that works at the top of the high temperature ranges these chips are rated for. How they have managed this is rather baffling to me, as they are the world's leading producer of microcontrollers, with >30% share at last count, and both them and Atmel had been making parts with 125C max temperature and 10k flash endurance for some time now. All of the Dx-series received a downgrade from 10k to 1k, and it was issued as a "datasheet clarification" - combined with other information, one is forced to conclude that they do not seem to have a solution to this - despite their considerable experience on the matter. However, comments from my guy on the inside have indicated that the issue is specific to the high end of the temperature range. Most startling of all, the EA appears to have regressed, with brutal nvmctrl errata.
• Note: The DU product brief also suggests additional mapping options for the TCBs which are not present on the EB thus implying an unprecedented "loss of function".... unless the EB were to be released first. Which indications are that it might in fact be, as headers are available for the 16EB's but not any DU yet. But in that case, the DU would experience "loss of function" instead, as they do not have the PF7/PF6 mapping for USART0 listed. Hence, taken at face value, the briefs indicate that the "don't remove mux options" rule may have been abandoned, which would make my job a lot harder.

Big Picture

These parts depart from the naming scheme used for AVR devices in the past; these are named AVR followed by the size of the flash, in KB, followed by DA, DB, or DD (depending on the "series" or "family", then the number of pins. Note that the pin count also determines how many of certain peripherals the parts have available - parts with more pins have more peripherals to do things with those pins. 64-pin parts are not available in 32k flash size. The 128k flash size is the highest that can be supported with a 16-bit program counter (above that, a number of instructions become slower, and everything gets more complicated), and with the current scheme for interacting with the pins, the 55 I/O pins (56 less the UPDI pin which takes the place of PF7) are the limit of what a modern AVR can accommodate while allowing single cycle access to all pins - so these take them to the top end of what is possible without extensions to the architecture.

At present, there are three lines of AVR Dx-series parts currently available: The "baseline" DA, the DB with multivoltage (MVIO) and on-chip OPAMPs, and the "budget" DD-series which has MVIO but otherwise far fewer peripherals, and is available in pincounts as low as 14, bringing them dangerouly close to the tinyAVR parts (dangerous for the tinyAVRs, that is). There is also a confirmed new DU-series on the way. The U is for USB - it'll have native USB, and DD-like pincounts. This is no doubt very exciting for many of us, who have longed for more sophisticated native USB parts than the m32u4 used in the Arduino Micro - though it looks to have had to make significant sacrifices at the altar of native USB, in terms of peripheral count and selection. This core supports the DA, DB, DD, and EA-series (excepting AVR8EA). Pending availability, support for the AVR8EA parts, as well as the EB-series and DU-series is planned.

DA-series

The "baseline" full-size parts - however much I was in awe of these when they were first released, having seen the DB-series, it now appears that these are more akin to a 0-series than a 1-series - in every arena, the DB has the same or better. They do not support using an external crystal for the main clock, like the other Dx parts do, but the internal oscillator on these parts is still WAY better than the classic AVRs had - all the ones I've tested are weithin half a percent at room temp and typical operating voltages, even without autotune... To make sure autotune was working, I had to point a torch at it, because I couldn't get enough of a change in the internal oscillator frequency from changing the supply voltage - in fact, it didn't seem to change at all. It is also the only currently announced Dx series without MVIO. While they may not shine as brightly next to the other Dx lines. The fact that these look less than stellar beside the DB doesn't change the fact that they absolutely bury any AVR from before 2020. There is only one thing that they have and the DB doesn't - a peripheral touch controller (which we can't use in Arduino land because they won't share the source code or the equivalent to the datasheet, but rather, they continue Atmel's practices here: They force you to use their IDE in order to make use of it). Word is that there is going to be an official Arduino library based on Q-touch from Microchip. It will then fall to the deep hackers to wrangle that into a smaller and more performant version, I know several already awaiting it. I have been told stories of the sorts of things that Q-touch does internally - but as there may be children reading this I will refrain from an enumeration of these things.

DB-series

The DB-series is almost an exact copy of the DA-series (they fixed some of the most egregious silicon bugs, but only some), with a few even more exciting features tacked on: Support for a real high-frequency crystal as clock source (finally - first time since the modern AVR architecture was released in 2016), "MVIO" (multivoltage I/O), where PORTC can run at a different voltage than the rest of the chip (essentially, a builtin bidirectional level shifter). The other "headline feature", is the two (28/32-pin parts) or three (48/64-pin parts) on-chip opamps, with software-controlled MUX for the inputs and an on-chip feedback resistor ladder. These can be used as gain stage for the ADC, for example, or to buffer the DAC output (though these opamps can't supply that much current, they can supply tens of mA, instead of ~ 1 like the unaided DAC), and connected to each other for multistage amplifiers (on parts with 3, you can even connect them together as an instrumentation amplifier). The included <Opamp.h> library provides a minimalist wrapper around them exposing all of the functionality.

DD-series

The DD-series is a smaller-pincount lower priced product line; parts are available with 14-32 pins. They've got the MVIO (3 or 4 MVIO pins depending on pincount), and the UPDI pin can be configured as an I/O pin (in this case, further UPDI programming requires an HV pulse to be applied to the reset pin, while the reset pin, like the DA and DB parts, can be configured only as reset or input. (This sidesteps the awkward problem that tinyAVR has of "How do I put an HV pulse on the reset pin when it's an output being driven low?") One thing worth noting is that the 28-pin and 32-pin DD-series parts are, but for expanded port multiplexing options for SPI0, USART0, and the addition of ADC input functionality on pins in PORTA and PORTC, and the fact that it actually fixed the longstanding errata on modern AVRs. It's a DB with fewer copies of peripherals and no opamps.

I expect the 14 and 20 pin parts to be very popular popular among hobbyists but that the 28 and 32-pin ones will be quite popular with cost-conscious commercial users, as they offer a significant discount compared to the DA/DB parts. DB's for the higher pincounts.

It's worth noting also that the DD28, unlike the DB28, is available in a VQFN28 package (4x4mm, 0.4mm pitch) Will that be a hobbyist choice? No. But will manufacturers love it? Yes. Especially at that price.

If you were hoping to use a tinyAVR breakout board for the 14 or 20-pin versions, I hate to be the bearer of bad news, but the tinyAVR boards won't work. They swapped power and ground on the SOIC packages vis-a-vis tinyAVR, and the layout of the VQFN20 is different than the 20-pin tinyAVRs. The 28 and 32 pin parts are pin compatible with AVR-DB - but as I said, I don't think anyone is super excited about a poverty model DB unless they desperately need more flexible PORTMUX (or can't lay their hands on any DBs due to the agonizingly long backorder waiting lists). Actually, no, I don't hate being the bearer of this news. In fact, it brings me joy - I sell breakout boards, remember? And now everyone's going to need different ones than they'd been using for 14 and 20 pin tinyAVR parts!

EA-series

The EA-series is known only from it's product brief, and now some rather sparse headers. It looks like it is the first example of a new generation. Except for the whole lower maximum clock speed thing, that I don't get... It looks like it's internal oscillator is tinyAVR-like... According to the product brief it will be available only in 28, 32, and 48 pin packages, with up to 64k of flash - or as little as 8k (implying it is at least in part aimed at dragging the users of the old ATmega8 and such into the modern era, kicking and screaming), no Type D timer, but in exchange, there will be dual type A timers in all pincounts (confirmed by headers, with new 5-6-7 mappings for multiple ports) and it will feature the 12-bit true differential ADC with programmable gain amplifier that the tinyAVR 2-series has. The DAC appears to have some new functionality, albeit likely nothing huge. Event system looks to be getting significant changes with the laudable goal of making the channels all the same, which would make things like input capture easier but for the fact that people have written code for the current parts.

The most puzzling thing about these, though is that some of their specs like the oscillator seem to represent a step backwards. On the third hand, they will represent YET ANOTHER version of the NVM controller, being the first modern AVR to advertise NRWW and RWW sections of flash - but again, many would argue it's a step backwards- it is much more like the tinyAVR and megaAVR 0-series than the AVR Dx. We can expect that programming over UPDI using SerialUPDI will be able to reach high baud rates - but the effective data rate will likely remain lower than the DX-series because of the smaller page size and additional commands required to write pagewise - RWW helps, but not by nearly as much as eliminating several latency periods per page and quadrupling the size of the page like the Dx did.

DU-series

The DU-series existence was disclosed in a product brief which was almost immediately pulled down. It described something with DD-like pincounts, MVIO replaced with USB, and no TCD. One imagines that under the hood, TCD or at least the PLL has been repurposed is generating the 48 MHz USB 2.0 reference clock, and the MVIO functionality is levelshifting the USB data lines to 3.3v. It feature crystalless USB, the same flash options as the DD (except no 64k 14/20 pin). It is also suggestive of a builtin USB programming interface of some sort, which is of course very exciting news - though all USB stuff will depend on availability of reference code to write the USB modules. We look forward to the release of more information, and, evnetually, the product. I predict the DU14 and DU20 will be extremely popular.

EB-series

The second tranche of Ex microcontrollers has dropped its (product) briefs for us. If there was anyone who thought that there was a bright future ahead for the tinyAVR branding, this should bring them around. These are a strike direct at the target market of the tinyAVR parts. But there's an even more important development: Two new timers. No information yet on how widely they will be distributed, The big deal here is that it drops the TCA's for 2 completely new timers and a very intriguing PLL that can both multiply and divide the clock, and TCF0. These new timers are TCE0 + WEX, a 16-bit PWM timer, and TCF0, which is 24 bit. The range of plausible behaviors of TCE and WEX has been narrowed considerably by the release of the initial headers (though initial headers always contain errors), and the same of TCF. What have we learned?

• ADC identical to EA.
• CLKCTRL gets a shovel of features poured onto it, despite it's using the shitty oscillator instead of the good one. Nonetheless, the featurelist is formidable:
  • System clock source has new option: THE PLL.
  • There is a new prescaler with just two settings: /1 and /4. It is not clear to what this applies.
  • If PLL enabled, MULFACT is either 8x or 16x (!!!)
  • The PLL can also divide its input by 1, 2, 4, or 6, and then divide it's output by another factor of two...
    • All this begs the question of just how fast that PLL can run when used as an intermediate frequency.
  • Note that the two input sources are the internal HF osc (I believe before prescaling) and external clock (no system clock option).
• FUSES
  • Reset and updi pins both convertible to I/O pins (well, input for reset, since it's the HV pin you use to reprogram if you set UPDI to be GPIO)
  • There's now a 2-byte fuse you can write to disable UPDI NVM access entirely. Unclear the ramifications.
• TCB - Gained a CNTSIZE register... Why?!
• TCE - PWM Timer and WeX's right-hand peripheral.
  • 4 independent compare channels. Each portmux option has up to 8 pins.
  • HIRES_X8 option - adds 3 bits of resolution, and an x4 option.
  • Scale option, the meaning of which is unclear, but which may be related to hires.
  • No split mode!
  • Same two event inputs, most of same functions as a 3-channel single-mode only TCA.
  • The event outputs are now selectable puise or level! Praise Microchip! I always hated using a whole CCL LUT and an event channel just to redirect PWM from a pin that doesn't exist on the part to one that does.
  • In league with WEX Luther, notorious supervillian, described below.
• TCF
  • 24-bit timer with option to use PLL as its clock (why else would you want 24 bits on a timer?)
  • Has a 2 output 8-bit PWM mode (likely using a trick like what TCB does)
  • Or can generate a square wave (frequency mode) - okay this is simple enough.
  • Or a pulse of a specified frequency (in powers of two clock cycles)
  • Or a constant duty cycle waveform (I assume of the frequency derived from that?)
  • It seems that the second output is only for 8-bit mode.
  • The event generators are selectable between pulse and waveform mode too!
• WEX - Yes, WeX Luther, the infamous kryptonite wielding supervillian is back, having somehow gotten out of xMegatraz prison. And he's right back to his old schemes, with the TCE as his new accomplice.
  • Fault-control like TCD for TCE, only without the bewildering list of options that TCD has.
    • This is made up for by a far more bewildering array of new options and features.
  • Input blanking for fault inputs.
  • Selectable fliltering on fault inputs.
  • Pin-by-pin port override control
  • "Pattern generation" which is mentioned in the xMega datasheets. Unfortunately it is glossed over in a few paragraphs, and not a single diagram. Think they'll actually document it this time?
  • Dead time insertion
  • Can light up the other 4 WO pins with inverted channels with dead time inserted, or possibly use them for "pattern generation"
  • As in the past, WeX's diabolical schemes have been incredibly complicated, and that does not appear to have changed.
    • If giving me a headache with only the IO headers was part of his plan, it's going well.
• What the devil is BOOTROW?!
  • Whatever it is, we can now protect it, as well as the userrow, from writes just like we can other memory sections.

We should keep in mind is that this seems to be in some ways a low end family - based on flash/ram (like a tinyAVR), the unwelcome amputation of the second USART, etc. And yet, they seem to be blessed with what look like really fancy timers, considerably beyond my expectations. I can't even guess at the price anymore: tinyAVR-like memory, the crappy oscillator, with the crappy tuning register, but they have this crazy PLL and two fancypants new timers.

Seriously?

Pick whichever features you like! As long as they're one of these combinations,

Series	Good OSC	Word Write	Good ADC	TCD	128k flash/64 pin	Opamps	TCE+WeX	USB	TCF	Crystal	MVIO	Enough USARTs
DA	Yes	Yes	No	No PORTMUX	Yes	No	No	No	No	No	No	Yes
DB	Yes	Yes	No	No PORTMUX	Yes	Yes	No	No	No	Yes	Yes	Yes
DD	Yes	Yes	No	Yes	No 64k/32 pin	No	No	No	No	Yes	Yes	They took our USART2!
EA	No	No	Yes	No	No 64k/48 pin	No	No	No	No	Yes	No	Barely
EB	No	No	Yes	No	No 32k/32 pin	No	Yes	No	Yes	No	No	No
DU	Yes	Yes	No	No	No 64k/32 pin	No	No	Yes	No	Yes	No	Barely

Timeline

128k DA-series parts were released in April 2020, followed by 32k in early summer (though the initial release of the 32k parts suffered from a fatal flaw and was recalled, working ones were not available until the end of 2020), while the 64k parts became available late in summer of 2020, around the same time as the first AVR128DB-series parts became available, while the 32 and 64k versions of the DB arrived in the first half of 2021. The AVR DD-series product brief was released in spring of 2020, but didn't become available until two years later in June of 2022, starting with 64k parts with 28 and 32 pins, and 16 and 32k parts with 14 and 20 pins. The other versions arrived in late 2022. At which time everyone looked for the QFN20 64k part and realized there wasn't one. Die apparently doesn't fit?

Lots of errata

The silicon errata list in the initial versions of these parts - the DA-series in particular - is... longer than you may be used to if you were accustomed to the classic AVRs. The initial DB silicon looked bad too, but right after the release, a new silicon rev was added to the errata listing which fixed the worst of the bugs present in the "first" AVR128DB rev. All the parts I've gotten had the fixes, even the ones that arrived before they'd released the datasheet... Sadly, the AVR128DA never got a corresponding pack of fixes. In both cases, the smaller flash versions, released later, incorporated fixes that the 128k parts haven't gotten. If you've been working with the tinyAVR 0/1-series, many of these errata may be old friends of yours by now. A large number of those issues appear to have sailed through the new chip design process without a remedy - and five years after the release of those parts, new silicon errata were still being acknowledged in the tinyAVR 0/1 errata and DA/DB errata simultaneously - apparently issues that were discovered on the Dx-series and then found to impact the tinyAVR 0/1-series as well.

The DD series parts have done a much better job on the errata. There very few issues known as of late 2022. Not that this is surprising: There was no really new ground broken by the DDs in terms of peripherals or function. Just fixing bugs, expanding mux options, and reducing cost and pincount.

See our errata summary for more information.

The EA is largely free of errata... except for the NVM controller. The NVM controller has a bunch of really nasty errata relating to flash writing.

Comparative pricing

TinyAVRs shown for comparison, qty 1 I-spec part from Microchip Direct, cheapest version (Those VAO ones that look way which look way cheaper are not counted - look at the "please order in multiples of line". So the lower unit price is a mirage, and they don't ship until next september. They may not ever be available in quantities of 1 - On other series they're treated as special orders.

Pincount	DA128	DB128	64DA	64DB	64DD	32DA	32DB	32DD	16DD	t321x	t322x	t160x	t161x	t162x	64EA	32EA	16EA	8EA
14-pin SOIC	-	-	-	-	1.29	-	-	1.04	1.00	-	0.96	0.77	0.86	0.88	-	-	-	-
20-pin SOIC	-	-	-	-	1.62	-	-	1.35	1.31	1.21	1.23	1.06	1.10	1.16	-	-	-	-
20-pin VQFN	-	-	-	-	x	-	-	1.11	1.03	-	1.01	0.81	0.75	0.95	-	-	-	-
28-pin PDIP	3.22	3.48	2.77	3.08	2.32	2.58	2.87	2.17	2.05	-	-	-	-	-	2.98	tbd	tbd	tbd
28-pin SOIC	1.98	2.14	1.84	1.92	1.49	1.64	1.71	1.49	1.35	-	-	-	-	-	-	-	-	-
28-pin SSOP	1.93	2.07	1.80	1.88	1.64	1.66	1.66	1.35	1.42	-	-	-	-	-	1.60	1.41	1.27	tbd
28-pin VQFN	-	-	-	-	1.38	-	-	1.23	1.10	-	-	-	-	-	-	-	-	-
32-pin TQFP	2.16	2.30	1.91	2.06	1.51	1.74	1.87	1.39	1.31	-	-	-	-	-	1.83	1.61	1.45	tbd
32-pin VQFN	2.14	2.29	1.91	2.06	1.52	1.76	1.82	1.42	1.35	-	-	-	-	-	1.79	1.59	1.41	tbd
48-pin TQFP	2.40	2.54	2.19	2.24	-	2.11	2.27	-	-	-	-	-	-	-	2.09	1.93	1.83	tbd
48-pin VQFN	2.30	2.45	2.19	2.27	-	2.01	2.15	-	-	-	-	-	-	-	2.05	1.89	1.79	tbd
64-pin TQFP	2.67	2.81	2.45	2.58	-	-	-	-	-	-	-	-	-	-	-	-	-	-
64-pin VQFN	2.72	2.88	2.51	2.53	-	-	-	-	-	-	-	-	-	-	-	-	-	-

Updated - they raised prices. I would too if I was backordered like they are.

This gives DD prices, which (where comparable parts exist) represent a savings of around 20-27% vs the DB (the DA is only about 5% less than the DB). It's worth noting that the DD28 finally brings a 28-pin VQFN to the family, something I'm sure the product designers would have liked to see in the DA/DB parts. A TSSOP package is almost as big and awful as SOIC, and few people in production would pick that over a QFN these days. You can see some odd patterns in the numbers emerge here, particularly that the QFP versions of the 32-pin parts are approximately equal, while those of higher-pincount devices favor the QFN. Odd isn't it? In the EA parts, the premium has converged to around 4 cents for the TQFP.

As can be clearly seen in the above table, when it comes to bang-for-the-buck on the DD-series parts, the 28-pin parts in VQFN are a spectacular bargain

Prices for VQFN vs TQFP are pretty close, with the ratio varying by pincount, and over time, and the pincount dependence is smaller than it has been in the past. Wide SOIC packages, which are only slightly smaller than a typical passenger car (slight exaggeration) are the most expensive surface mount package here and 15-20% more expensive than the same part in VQFN where both are available. SSOP only undercuts SOIC-W slightly. 14-pin SOIC on the other hand, being "narrow SOIC", does not carry such a premium. There are no Dx-series parts available in SSOP-14 and SOIC-14, or SSOP-20 and SOIC-14, but for those interested in the comparison, from the tinyAVRs, SOIC-14 and TSSOP14 are within a few percent of each other, while the difference between SOIC-20 (wide) and SSOP-20 around 20%, and SSOP-20 and VQFN-20 are priced similarly. This is in stark contrast to the 28-pin SSOP, which is closer to the expensive wide SOIC than the bargain VQFN, a difference that is difficult to rationalize. That said, considering how the trends on the tinyAVRs and Dx-series matched up very well, I expect that in the not-unlikely event that a future AVR Dx or Ex part is sold in TSSOP-14 or TSSOP-20 (now this is revealed to have in fact been the case - the EB will be a scaled back 14-32 pin EA - except they have different timers, and a new PLL to drive them - I'm very curious how the pricing will compare between different pincounts. The prices will be roughly at parity with the SOIC-14 or VQFN-20, respectively. And surprising nobody, the 28-pin DIP packages are far and away the most expensive package, with a wallet-bending premium over the already expensive SOIC-28 of over 50%, and compared to the VQFN-28, it's even larger (around 75% for 64DD, 91% for 32DD, and 95% for the 16DD). While some of the pricing trends are a bit difficult to explain - this isn't one of them: Every imaginable factor works against the DIP package. Today the vast majority of production uses surface mount parts, so the economies of scale provide less of an advantage; the parts are also physically large, which as we saw with the wide SOIC parts, raises the cost; even moving them around is harder, because they have pins sticking out further which need to be protected in shipping.

The difference between AVR DA and DB parts, with the same size flash, is better modeled by a flat premium on the DB-series parts than a percentage, the same for the 128k vs 64k vs 32k vs 16k ($0.20, $0.15, $0.10) The discount of the DD vs the DA (excepting the DIP, where I think the economics get a bit more complicated), seems to be percentage-like, though - 20% at 32 pins, 9% for 28-pin SOIC and 15% for TSSOP, and 20% for both 32-pin packages. I would venture a guess that if there were a VQFN-28 DA/DB, it would have been 20% there, predicting DA prices of $1.83, $1.63, $1.46, and DB prices of $1.93, $1.73, $1.61 - which looks about right! I expect to see the AVR16DD32 in QFN come in at between 1.25 and 1.28 (not quite dead on I was $0.07 under. The DIP prices break all the rules, I'm not going to speculate there.

The DD20s seem maybe a hair on the expensive side - especially with the 28-pin QFN priced like it is. Could the the die be that big? Really? (I've got a 64DD20 here, someone pass the fuming nitric acid and dial calipers (separately, though, please!), let's see how big that die actually is * see below - yes, it is die size!). An AVR64DD20 available only in a massive and expensive wide SOIC package is not exactly destined for glory, not with a 28-pin QFN selling for less. If the die won't fit uh.. could we at least get a TSSOP like the 3226's have? Extrapolating from the tinyAVRs would suggest a price not far from the QFN price which we above estimated at 1.25-1.28 cents. A TSSOP-20 in that neighborhood would work if a QFN wouldn't. Or cop out and do a larger pitch QFN-20? Something? The AVR64DD20 in SOIC-20 only, at that price, ain't gonna set the world on fire - Between the unfavorable pricing and the crappy package selection, they seem to have it in for the DD20's... Well - we won't know until we see how EB and DU 20's are handled.

So about that DIP package. Why any through-hole part? I suspect the fact that the DIP package is being made, despite almost certainly constituting a tiny fraction of sales, is largely out of a desire to appeal to hobbyists and maker types, and maintain and grow the popularity of the AVR product line among that often surface-mount-averse group. This is likely not a gesture of kindness or goodwill, but simply a shrewd business decision: A significant number of those people go on to become entrepreneurs selling electronic gizmos, and many of those that don't either work in the electronics industry or will in the future. Since any microcontroller architecture has a considerable learning curve, the entrepreneurs will tend to stick to the architecture they know how to work with when they productize their creations and start selling them, while those working in the industry will be more likely to select or recommend (depending on their position) AVRs, and besides that, a larger pool of engineering talent who has experience with the architecture from their personal projects makes AVR more attractive to any company. Imagine being a personnel manager, trying to find applicants for a design project, you want people with experience programming those parts. Say it is based on a something with no open source compilers and which is rarely used outside of corporate products. If you want applicants with experience working with those parts, you'll have to hire them away from your competition, or accept that you can't find anyone with that experience, and try to hire people who are not turned off by the prospect of having to learn something they can't use outside of their job, then pay to train them to work with the parts, and accept the delays while they come up to speed. Neither of those options is particularly appealing. But if the project used an AVR, which is incredibly popular among hobbyists and makers - you'll have a much easier time finding applicants who have some familiarity (although the skill levels will vary widely, since the people in Arduino-land have life made rather easy for them, but they still have some experience, and it is the same programming language (most likely), so that makes a difference). Better still, those people are sufficiently enthusiastic about it that they use them in their spare time and are eager to get paid to do so. Some of them will be ready to jump right in, while others will need some time (though less than if they had no AVR experience) to pick up more rigorous programming practices (or maybe not - I've seen some code that was going onto commercial devices written in Arduino. I've written some. Sometimes there is more rigor than is common in Arduino-land even then, but other times, it looked like typical Arduino code - the only kind of rigor in sight was rigor-mortis. Indeed, sometimes I was being paid to address that, but that just reinforces this point). A larger talent pool available can only be good for Microchip and AVR, so appealing to hobbyists and makers who have not yet learned to love SMD probably pays off.

Prices are Microchip Direct qty 1 price for the item, industrial temp range, not in tape (They charge a few cents extra to put parts in tape for you, which is required for many pick-and-place machines (though not all - some can use trays - or even tubes - directly). Quantity discounts are significant - If this document was targeting industry folks instead of hobbyists, makers and maker-entrepreneurs, I'd be comparing the 5000+ price instead - but the two prices are have a simple correlation, so both are suitable as a means of comparing part pricing). The trend would be the same. The DA-series are available in an automotive (VAO) grade (available being a funny word here, since they're backordered for 15 months), but what's really surprising is that the price of extended temp range 128DA64's is lower than normal, non-extended temp range, non-VAO 128DA64's/

New pincounts/package/flash combinations seem to be dribbling out, probably as production capacity allows. Evidence over the past several years has implied that Microchip has difficulty meeting demand for QFN packaged parts in general, which would explain why they are coming out later (though not why they aren't more expensive)

* Nitric acid - specifically hot, fuming nitric acid (Ordinary "concentrated" nitric acid is just 68% HNO3. Above 86%, it's termed "fuming" nitric acid, and is more aggressive than the regular kind. As the name implies, when exposed to air, visible fumes can be seen above the liquid, and the fumes (as well as the liquid) can range from white to yellow to reddish brown, depending on the presence of nitrogen oxides, which highly concentrated nitric acid decomposes to when exposed to light or heat). Fuming nitric acid at around 90%, at 150C is what is used to "decap" chips (dissolve the encapsulation material) - at least that is what Sparkfun was told was being used when a few lucky Sparkfun folks got to visit an Atmel failure analysis lab to watch them examine some counterfeit 328p's that they'd been sold. It dissolves the plastic, but not the die (yes, that is plastic, not ceramic. Ceramic ICs exist, and were more common in the past, but they cost a fortune to make. Once plastic encapsulation technology was sufficientlyt worked, decades ago). For hopefully obvious reasons, it's much safer to heat the chip to 150C, and let that heat the nitric acid, and that's what is normally done, a drop at a time, rinsing the exhausted acid away with acetone (note that the mixture of the two is not something you want to leave around either). With the die revealed, you'd just measure it. In industrial settings, after decapping an IC with nitric acid, there are some other steps that they might use to get a better view by removing the topmost layers before putting it in an electron microscope to make those beautiful die photos we've all seen (a scanning electron microscope is what you'd use to take die photos, while a tunneling electron microscope can be used to manipulate individual transistors **. You wouldn't need an electron microscope, though, to answer the question at hand here, which is whether the die for the AVR64DD20 die is too big for a 3x3mm QFN. You probably don't even need the dial calipers, you could just look at whether the die size was close to the scale of the QFN package - but don't try this at home: Nitric acid is an extremely hazardous chemical, and the fuming sort even worse, particularly once you've heated it up to 150C. It should not be used at home, without a fume hood, or anywhere except for an appropriately equipped laboratory or industrial facility! Nitric acid is nearly impossible to get anyway for individuals - it is extremely expensive to ship (for very good reasons) and it is watched or restricted in many countries because of it's much-better-known application: It is used in manufacture of almost every high explosive, some low explosives, and it was used in rocket fuel, though it's been largely replaced, as it was too dangerous. You can see why governments might not want people to be playing with it. A more reasonable approach, which doesn't involve hot, fuming acids that are strong oxidizing agents would be to just grind or sand away the top of the package to reveal the die. You'd have no hope of getting one of those beautiful die photos, but you need an electron microscope for that anyway.

Update: tops of QFN ICs have been filed off. The die photos definitely don't look anywhere near as good as electron microsopy on nitric acid-decapped chips. But it involved handling no hazardous chemicals, and at most a digital microscope in the $30-100 range. Even if I was a company, I doubt I could get a bottle of WFNA for that (now if I was a company, and bought a tanker full of it, I'd be paying a fraction of that price per liter - but white fuming nitric acid - really any nitric acid, especially fuming, and I don't care whether the fumes are red or white, is one substance I do not want a tanker full of anywhere near me, nor something I'd want to have any liability for in the event of an accident. Right up there with Chlorine or Florine as compressed liquids, fuming sulfuric acid (Sulfuric acid with sulfur trioxide dissolved in it, which evaporates, and reacts with water in the air to form sulfuric acid), or any chlorohydrocarbon that wasn't bound up into a polymer (eg PVC - polyvinylchloride as opposed to chloroform, dichloromethane, chloromethane, Trichloroethane, tetrachloroethylene, aka perchloroethylene or "PERC" a name under which it became somewhat infamous as a pollutant) - really, very few chlorohydrocarbons, (unless the only cloro is on phenyl group, or which are polymers hence not mobile) are anything other than fairly toxic. Most of those insecticides that got banned in the 70s-2000's (DDT being the most prominent example *** though it was designed with a bit more care than many of them were, were made by chemists who suddenly had an excess of chlorine from the new chloralkali industry chlorinating practically anything they could get their hands on and seeing if the result was any good at killing things. They were banned a couple of decades ago, some much earlier (and some, like DDT, with very limited allowed uses), because they were good at killing things we'd rather they not. Like eagles, and humans, that sort of thing. Off target organisms.

Results: The ATtiny162x die appears to be the same across devices, surprising nobody. Interestingly, the 1626 die seems to be about as large as will fit into a QFN package. That implies that either my estimates of the maximum size the QFN can fit are off, or that 32k tinyAVRs are made on a different (finer) process node than 16k ones, at least when their destination is a small package. The 32DD20 die seems to be the same size and the tiny162x die, suggesting that it was likely made on the same process as the 3226 since it's a fancier chipwith twice the memory, so it should be bigger than the 1627. In any event, the insight from this is: 1. Yes, they were out of space in the 3x3 QFN for to put the 64DD20. 2. At least on tinyAVR, they appear to be fabbing different memory sizes at different process nodes!

A little bit more filing and measuring on DA's or DBs will tell us how much space the memory takes up!, or we will be able to see that they have moved to adifferent process node for smaller flash versions More Information

** The fact that such tools exist is one reason why no method of "locking" chips to prevent exfiltration of data from a chip is perfect. In many cases such extreme measures are not needed, and parts can be unlocked by electrical manipulation and - when using an external clock source - manipulation of that as well. Some measure of effort has been put towards making unlocking chips without erasing data as difficult as possible, and I certainly don't know how hard it is to break the lock on modern AVRs, beyond that it's harder than it was on classic AVRs (I have seen advertisements from companies who did that sort of thing - though they only listed classic AVRs, not modern ones). The lockbyte where a single bit controls the lock status of the chip on classic AVRs (sometimes several bits were involved, each covering different circumstances) was replaced with a whole byte, such that it is "locked" unless it holds a specific value (on modern AVRs, the lockbyte(s) protect against reads from UPDI, and there are other measures to protect against other methods that the flash can be read; see the NVMCTRL chapter of the datasheet for more information). This grew further to four bytes on the Dx-series (likely the objective is to ensure that things that simply disrupt operation would have to cause 8 or 32 bits to be misread in precisely the right way - a much harder proposition. I have no doubt that the specific "key" that is used was carefully picked in order to be particularly resistant to attack.

*** "A mosquito was heard to complaint/that chemists had poisoned his brain/the cause of his sorrow/was paradichloro/diphenyltrichloroethane"

We got initial Ex-series headers

The EA-series ATpacks are now available from Microchip. It has some surprises in it

EA turns out to be a mixed bag

The clock subsystem is a downgrade from the Dx and from the tinyAVRs. The only saving grace is the fact that the it can at least use a crystal. This is worse than expected - I had expected that if we got the tinyAVR clock speeds, we'd get tinyAVR cal bytes, and be able to get practically any speed we want under 32 MHz. Nope, DX-style calbytes. 5 measly bits leave both granularity and compliance lacking. The errata relating to the NVM is just brutal.

EA support expected to go in smoothly

Core adaptation will mean pulling in the clock speed logic from megaTinyCore, and the fancy-ADC code, and it'll mean some tricky adaptations to Event (the way RTC and Pin events are generated is different, though the specific differences also make the rest of Event simpler - or they would except that it's going to be #ifdef hell. Actually "going to be" is being charitable. Too charitable. Event.h and Event.cpp are already there as it is. EVSYS has received more major changes than any other peripheral on the modern AVRs. Yes, the feature checklist, outward appearance and the interface of Event.h has not really changed, the implementations are quite different.

EB may be a bigger deal

Though - not necessarily the EB-series parts themselves (their specs are hardly earthshattering. At these features, these had better be a budget part. But I think they will be. I think they're aimed at the t861 and the like, with TCE replacing the wacky timer0. I think WEX will be in charge of dead time and inverted PWM for motor drive applications) and we now know that the headline spec is 4 compare channels, implying either ganged TCDs or something different altogether - and we can likely forget about split mode.) so much as for the two new types of timer they are the first public release of. It all dependd on the details of the TCE+WEX and TCF - and on how widely distributed they will be. If TCE is targeted squarely at motor drive applications, we probably won't see it much, and can expect our old friend TCA was only traveling, and hasn't been bumped off by WEX Luther and his crony some fear .

The Ex-flagship is likely not yet annoumced

Or at least the EA-series had better not be it, cause it aint much of a flagship! I expect a 4-6 USART, 2 SPI, 2TWI, 3OPAMP, with 48 or even 64 pins and at least one dac for the OPAMPs to play with. Either that, or we're going to see Dx-series parts with all their splendid features - PLUS all the new features from the Ex-series. We're definitely going to need something with the new ADC and MVIO somehow. At least, I sure hope we see something like that, otherwise there's a seriously missed opportunity here.

Of course, what I want and what probably 1-2% of others at the most want, is a chip that doubles down on the CCL. Add an extra LUT to every port, which could be given a few different options (eg TCA WO 3-5, TCBs 3-5 (obviously this chip needs to have lots of TCBs and 2 TCAs to use as internal inputs and lash together with the event system)). You'd need more event channels too. And what I'd really like to see is a buffered shift register. 3 inputs: data in, clock in, and copy contents to a s

The Dx-series architecture

The Dx-series is the first AVR (as far as we know) that does what's quite common among ARM chips in order to support small feature sizes and higher speeds - they use an internal regulator to generate a lower voltage for the chip to run from, and only the I/O runs at the full supply voltage. So it is no surprise that you can vary the supply voltage as much as you like and it won't change the speed of the internal oscillator. Why would it, the oscillator doesn't see any change in voltage, it's running from the internal regulator! As with any regulator (particularly one with virtually no capacitance on the output), a sufficiently dramatic step-change in voltage will cause it to overshoot or undershoot. That's the reason for the maximum slew rate spec: 250 V/ms between 1.8v and the rated maximum voltage. So, if the voltage rail goes from 1.8V to 5V (3.2V) in less than 12.8 microseconds, you would not meet that requirement. This is fast, but plugging a board with minimal decoupling into a very well decoupled power supply can result in such fast rise times. This is why the datasheet suggests a 1uF capacitor in addition to the 0.1uF ones if power will be frequently connected and disconnected; that recommendation was not in the initial datasheet. This limit was rapidly encountered in the field - a small PCB with only the minimum number of 0.1uF capacitors on it that plugs straight into a USB socket could exceed it - and that prompted them to recommend the additional board level decoupling. I consider it prudent to put at least 4.7uF of capacitance on the PCB in general, and this is just another reason to do that.

As you can imagine, this made implementing MVIO much easier - they just had to sever the connection to Vdd from one port's level shifter bring it to an external pin, and add a BOD-like monitor on that voltage like they already have for VDD. It's worth noting that they don't have any means to internally connect that pin to Vdd when the chip doesn't have MVIO enabled. That's the responsibility of the user. This means that you won't damage the chip if you accidentally forget to enable MVIO before wiring up a dual supply configuration. It also means.... that if you have a different voltage on VDDIO2, PORTC will still use that voltage even if MVIO is off. So what is MVIO doing that takes an extra 400 nA (according to datasheet, peripheral power consumption)? With MVIO on, when the voltage on VDDIO falls below 1.8v, the port turns off and the pins are tristated, and read as zero. That actually seems to be all that MVIO being enabled does - so the extra power consumption is for the equivalent of a brownout detector (BOD) on the VDDIO rail so it can turn the pins off entirely if the voltage on VDDIO2 falls too low for proper operation. With VDDIO2 too low and MVIO off, the pins still try to function, but don't work properly (certainly, they read random values. I haven't tried writing to them; I'm not sure what would happen. Doing this is probably not a good idea - but it appears that putting a chip with MVIO turned off in the fuses into a circuit that uses MVIO will not get immediately harmed, though it may not handle excursions in VDDIO2 gracefully.

It would have been nice if they made MVIO status return a 0 when MVIO was fused off, on the grounds that if you're testing the status of MVIO, you're certainly expecting that you are operating in a multivoltage environment - so it would have been more prudent for the bit to always show zero if MVIO is disabled... or used a second bit. Either of those would have made it much more likely for code to notice, generating an error which would lead the user to investigate and realize that the device had the fuses set wrong. The only time we care about the fuse is when we intend to be making use of MVIO - nobody is going to check it if they're not.