AVR64DD28/AVR32DD28/AVR16DD28
June 24, 2023 ยท View on GitHub
Pin Mapping / Pinout
SOIC/SSOP/DIP
QFN
This pinout image is temporary - I know we had the proper square version ready but not what happened to it.
Features and Peripherals
| Feature | AVR16DD28 | AVR32DD28 | AVR64DD28 |
|---|---|---|---|
| Flash Memory | 16384 | 32768 | 65536 |
| Flash Memory (with Optiboot) | 15872 | 32256 | 65024 |
| SRAM | 2048 | 4096 | 8192 |
| EEPROM | 256 | 256 | 256 |
| User Row | 32 | 32 | 32 |
| Max. Frequency (rated, MHz) | 24 | 24 | 24 |
| Clock Sources | INT, EXT, XTAL | INT, EXT, XTAL | INT, EXT, XTAL |
| Packages Available | SOIC, SSOP, | SOIC, SSOP, | SOIC, SSOP, |
| Packages Available | DIP28, VQFN28 | DIP28, VQFN28? | DIP28, VQFN28 |
| Total pins on package | 28 | 28 | 28 |
| I/O Pins, not counting Reset | 21 | 21 | 21 |
| Fully async pins | 23 | 23 | 23 |
| UPDI as I/O Pin | Yes | Yes | Yes |
| PWM capable I/O pins | 19 | 19 | 19 |
| Max simultaneous PWM outputs | 11: 6:2:3 | 11: 6:2:3 | 11: 6:2:3 |
| 16-bit Type A Timers - pins ea | 1: 6/4/5/2 | 1: 6/4/5/2 | 1: 6/4/5/2 |
| 16-bit Type B Timers, (pins) | 3: 3 | 3: 3 | 3: 3 |
| 12-bit Type D pins | 6 | 6 | 6 |
| USART (pin mappings) | 2: 3/1 | 2: 3/1 | 2: 3/1 |
| SPI (pin mappings) | 1: 5 | 1: 5 | 1: 5 |
| TWI/I2C (pin mappings) | 1: 3 | 1: 3 | 1: 3 |
| 12-bit ADC input pins | 14/18 | 14/18 | 14/18 |
| Of those, neg. diff. inputs | all | all | all |
| 10-bit DAC | 1 | 1 | 1 |
| Analog Comparator (AC) | 1 | 1 | 1 |
| Zero-Cross Detectors (ZCD) | 1 | 1 | 1 |
| Custom Logic Blocks (LUTs) | 4 | 4 | 4 |
| Event System channels (out pins) | 6: 6 | 6: 6 | 6: 6 |
| On-chip opamps (OPAMP) | - | - | - |
| MVIO, pins | Yes, 4 | Yes, 4 | Yes, 4 |
| Flash Endurance | 1k | 1k | 1k |
| LED_BUILTIN (and optiboot led) | PIN_PA7 | PIN_PA7 | PIN_PA7 |
- VQFN is 4mm x 4mm 0.4mm pitch. 16 and 32k parts in this package are not for sale at time of this writing.
- SSOP is 5.3mm wide
* As with all Dx-series, the flash didn't live up to expectations at extreme conditions. 1k is the worst case rating though, and under typical conditions, it is believed that the endurance is >= 10k cycles. I do not know how far along Microchip is in developing a solution, but it's being treated as datasheet clarification, so that's not encouraging. I am hoping for additional information on how flash endurance is influenced by various factors.
AVR DD28 - Poverty model DB without the opamps and fewer peripherals, but with a bunch of errata fixes and added port mappings
That basically sums up the DD28 and DD32 parts. They're much cheaper than DB-series, barely above ATtiny parts, but come with most of the full suite of features. Obviously some things were cut versus the DB - they still come in three sizes, but the sizes have half the flash. There is only 1 analog comparator and no USART2, and we're down to just one SPI and I2C peripheral. On the other hand, the pin multipleximg options of USART0 and SPI0 have gotten luxury treatment. Note also that the alternate pin mapping numbers don't start at 1.
The 8 pins that the 28-pin parts pick up versus the 20-pin parts are PC0, PD1-3, PF0-1, and 1 each Vdd and Gnd.
Possibly more importantly, they pick up, even at 64k, a minuscule yet dirt cheap package: VQFN-28 4x4mm 0.4mm pitch.
Fully async pins
All pins on the DDs are "fully async" and can respond to events shorter than 1 clock cycle, and can wake the chip on RISING or FALLING edges, not just LOW_LEVEL and CHANGE, whether or not the I/O clock is running. There are good and bad sides to this. The good are obvious, the bad is reduced noise rejection if you're able to respond to such brief signals.
Portmux options
Options for which no pins are available are not listed, and options missing critical pins or which are strictly worse than another pinset are struckthrough.
USART0 mux options
| USART0 | swap | TX | RX | XDIR | XCK |
|---|---|---|---|---|---|
| DEFAULT | 0 | PA0 | PA1 | PA2 | PA3 |
| ALT1 | 1 | PA4 | PA5 | PA6 | PA7 |
| ALT2 | 2 | PA2 | PA3 | - | - |
| ALT3 | 3 | PD4 | PD5 | PD6 | PD7 |
| ALT4 | 4 | PC1 | PC2 | PC3 | - |
USART1 mux options
Alt1 unavailable - no PC4-7.
| USART1 | swap | TX | RX | XDIR | XCK |
|---|---|---|---|---|---|
| DEFAULT | 0 | PC0 | PC1 | PC2 | PC3 |
| ALT2 | 2 | PD6 | PD7 | - | - |
SPI0 mux options
Suddenly we have 5 usable mux options!
| SPI0 | swap | MOSI | MISO | SCK | SS |
|---|---|---|---|---|---|
| DEFAULT | 0 | PA4 | PA5 | PA6 | PA7 |
| ALT3 | 3 | PA0 | PA1 | PC0 | PC1 |
| ALT4 | 4 | PD4 | PD5 | PD6 | PD7 |
| ALT5 | 5 | PC0 | PC1 | PC2 | PC3 |
| ALT6 | 6 | PC1 | PC2 | PC3 | PF7 |
TWI0 mux options
| Mapping | swap | Master or Slave | Dual Mode Slave |
|---|---|---|---|
| DEFAULT | 0 | SDA/PA2 SCL/PA3 | SDA/PC2 SCL/PC3 |
| ALT2 | 2 | SDA/PC2 SCL/PC3 | |
| ALT3 | 3 | SDA/PA0 SCL/PA1 | SDA/PC2 SCL/PC3 |
Note that this means that you want Wire.swap(0, 2, or 3, but not 1).
PWM Pins
Even with 28 pins, there still isn't a whole lot of choice...
- TCA0 goes on PORTD to match how the DB does it. This is less than ideal, but there is just so much comp for PORTA pins.
- TCD0 can go either way as required, we leave it at default. PF0/1, PD4/5, and PF0/1 are not used for
- The TCBs are unlikely to see much PWM use - they share PA2 and PA3 with TCA0, and no different PORTMUX option can return at least the three pins you lose from switching to PORTC instead of PORTA, though they will be used if PORTMUX is set to point TCA0 to a port other than PORTA, and the timer isn't being used for millis, which TCB1 usually is.
TCA mux options
| TCA0 | WO0 | WO1 | WO2 | WO3 | WO4 | WO5 |
|---|---|---|---|---|---|---|
| PORTA | PA0 | PA1 | PA2 | PA3 | PA4 | PA5 |
| PORTC | - | PC1 | PC2 | PC3 | - | - |
| PORTD | - | PD1 | PD2 | PD3 | PD4 | PD5 |
| PORTF | PF0 | PF1 | - | - | - | - |
It is strongly recommended to not have any PWM output enabled involving either the timer being moved nor the pins it is being moved to when setting PORTMUX.TCAROUTEA. In the latter case, you will not be able to turn off the existing PWM through the API functions.
PORTMUX.TCAROUTEA = PORTMUX_TCA0_PORTA_gc // PWM on PORTA
// Note since there is only one TCA, you can use simple assignment to write values to PORTMUX.TCAROUTEA to.
Note also that this core default differs from the hardware default - The hardware defaults to PORTA, which is TCA-complete but shares pins, (most notably the two xtal pins) with a ton of peripherals, and generally has intense competition for pins on PORTA. PORTD is chosen because it's less likely that all of it will be in conflict with other user at the cost of one TCA channel. But it's trivial to change!
TCB mux options
Not much of a choice was left for the core designer - the pins that the high council blessed at TCB capable, we only have one per timer. Note TCB2 by default is used so PC0 PWM should not be expected with millis on default settings..
| TCBn | Default | Alt |
|---|---|---|
| TCB0 | PA2 | - |
| TCB1 | PA3 | - |
| TCB2 | PC0 | - |
TCD0 mux options
| TCD0 | WOA | WOB | WOC | WOD |
|---|---|---|---|---|
| DEFAULT | PA4 | PA5 | PA6 | PA7 |
| ALT2 | PF0 | PF1 | - | - |
| ALT4 | PA4 | PA5 | PD4 | PD5 |
Like TCA, in 1.5.0 of DxCore, if you set the TCD portmux (PORTMUX.TCDROUTEA), digitalWrite and analogWrite() will be aware of it (digitalWriteFast is never aware of PWM, don't use it to shut off PWM, it won't). TCA is used in preference to TCD when both are available on one pin. Since default is usable, we don't change it.
LED_BUILTIN
To match other parts, PIN_PA7 shall be the pin that the core "expects" to be connected to an LED. If you want to have a different pin be recognized by the application (this does not change the bootloader - you would still need to do a custom build of that too), this can be overridden if a custom board definition is created by passing -DLED_BUILTIN=(some other pin) as part of build_extra_flags, building via the CLI, or by equivalent means provided by other third party development environments.
Official Documentation
When all else fails, read the real documentation. They keep moving the .pdf files around, so now I just link to the prduct page, from whence the datasheet, errata, and "technical briefs".
At a minimum, everyone using a modern AVR should plan on having a PDF viewer open with the datasheet, and a text editor with a good search function and the ioavr______.h file open so that when you're trying to use a constant, but the compiler says it isn't declared/defined, you can search the io header for a key phrase in the constant and figure out how it was spelled/formatted or copy/paste it to your sketch. (see the IO headers for more information and links to them. I also keep the AVR instruction set manual open in the PDF viewer as well as the silicon errata and datasheet clarification. Datasheet clarifications are a bigger deal than an erratum, usually. An erratum says "Okay, this doesn't work, but it will some day, maybe" while a datasheet clarification says "This would be an errata, but we're not even going to pretend that we'll fix it some day". But watch out - datasheet clarifications vanish from the list once the datasheet has been updated!
The "Technical Briefs" are somewheat inconsistent in their value, but some are quite good.