| Feature | AVR16DD14 | AVR32DD14 | AVR64DD14 |
|---|---|---|---|
| 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 | SOIC | SOIC |
| Total pins on package | 14 | 14 | 14 |
| I/O Pins (not reset/UPDI) | 9 | 9 | 9 |
| Fully async pins | 11 | 11 | 11 |
| UPDI as I/O Pin | Yes | Yes | Yes |
| PWM capable I/O pins | 7 | 7 | 7 |
| Max simultaneous PWM outputs | 5: 3+2 | 5: 3+2 | 5: 3+2 |
| 16-bit Type A Timers - pins ea | 1: 2/3/2 | 1: 2/3/2 | 1: 2/3/2 |
| 16-bit Type B Timers, (pins) | 2: 0 | 2: 0 | 2: 0 |
| 12-bit Type D pins | 2 | 2 | 2 |
| USART (pin mappings) | 2: 3/1 | 2: 3/1 | 2: 3/1 |
| SPI (pin mappings) | 1: 2 | 1: 2 | 1: 2 |
| TWI/I2C (pin mappings) | 1: 2 | 1: 2 | 1: 2 |
| 12-bit ADC input pins | 4/7 | 4/7 | 4/7 |
| 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: 3 | 6: 3 | 6: 3 |
| On-chip opamps (OPAMP) | - | - | - |
| MVIO, pins | Yes, 3 | Yes, 3 | Yes, 3 |
| Flash Endurance | 1k | 1k | 1k |
| LED_BUILTIN (and optiboot led) | PIN_PD6 or PD4 | PIN_PD6 or PD4 | PIN_PD4 or PD6 |
* 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.
The DD-series parts are low-cost, low-pincount AVRs with MVIO and all the headline features of the DB except for the opamps and the sheer number of peripherals. To make the most of the small pincount, these have significantly expanded mapping options for USART0, USART1, SPI0, and TWI0.
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.
(options for which no pins are available are not listed, and options missing critical pins or which are strictly worse than another pinset are structhrough)
| USART0: | swap | TX | RX | XDIR | XCK |
|---|---|---|---|---|---|
| DEFAULT | 0 | PA0 | PA1 | - | - |
| ALT3 | 3 | PD4 | PD5 | PD6 | PD7 |
| ALT4 | 4 | PC1 | PC2 | PC3 | - |
As default is kinda useless, USART1 defaults to swap(2).
| USART1 | swap | TX | RX | XDIR | XCK |
|---|---|---|---|---|---|
| ALT2 | 2 | PD6 | PD7 | - | - |
ALT5 is not the most useful multiplexing option, and should probably not be used - ALT6 however gives you SPI on the right pins of PORTC to be useful for MVIO, while ALT4 (the default) gives you non-MVIO-referenced SPI levels.
| SPI0 | swap | MOSI | MISO | SCK | SS |
|---|---|---|---|---|---|
| ALT4 | 4 | PD4 | PD5 | PD6 | PD7 |
| ALT6 | 6 | PC1 | PC2 | PC3 | PF7 |
Note that this means that you want Wire.swap(2, or 3, but not 0 or 1). While swap level 0 is "implemented" in hardware it is not useful - you can do everything you could with swap 0 using swap 2 or swap3 3 and then some - and with binary size smaller than or equal to what can be achieved with swap 0. None of the pins used by swap 1 exist at all.
| Mapping | swap | Master or Slave | Dual Mode Slave |
|---|---|---|---|
| ALT2 | 2 | SDA/PC2 SCL/PC3 | Not avail. |
| ALT3 | 3 | SDA/PA0 SCL/PA1 | SDA/PC2 SCL/PC3 |
With 14 pins, there isn't a whole lot of choice...
- TCA0 obviously wants to be on PORTC. On PORTD it would be fully redundant with the TCD, and PA0 and PA1 are the pins used for external clock sources.
- TCD0 only has pins on PORTD, so we set that by default
- The TCBs don't get used for PWM. They support no pins present.
The Type A timers (TCA0) can be mapped to different pins as a group only, and analogWrite() is PORTMUX-aware - you can set TCA0 to output on any port's pin 0-5. Using this feature is easy - you simply write to the portmux register PORTMUX.TCAROUTEA = (TCA0 pinset) and then analogWrite() normally. TCA0 pinset is the port number (0-5 for ports A-F), or one of the named constants of the form: PORTMUX_TCA0_PORTx_gc where x is A, C, or D.
| TCA0 | WO0 | WO1 | WO2 | WO3 | WO4 | WO5 |
|---|---|---|---|---|---|---|
| PORTA | PA0 | PA1 | - | - | - | - |
| PORTC | - | PC1 | PC2** | PC3 | - | - |
| PORTD | - | - | - | - | PD4 | PD5 |
Yeah - for a timer with 6 PWM outputs, these pin mapping options are pretty bleak.
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. Simple assignment can and should be used to write to the PORTMUX.TCAROUTEA register. This is the only bitfield there, so you needn't worry about stomping on anything else.
No TCB output pin exists as a physical pin on the DD14s
Only one set of pins actually exists. Default is not a valid option here as it has no pins, core defaults to ALT4, the only one with pins.
| TCD0 | WOA | WOB | WOC | WOD |
|---|---|---|---|---|
| ALT4 | - | - | PD4 | PD5 |
It is not possible to match other parts; PIN_PA7 does not exist here. We also don't want to use PA0 or PA1 (because then they would conflict with a crystal, and crystals can be damaged by such abuse). It shouldn't be an MVIO pin, because there are no safe choices. If you want serial to go to a different-voltage device, you NEED PC1 and PC2 free. If you want I2C, you NEED PC2 and PC3. And you need all three for SPI. So PORTC is out of the running, leaving only PD4, PD5, PD6 and PD7 - and either PD4 and PD5 or PD6 and PD7 are may be used to talk to the bootloader, PF6 is reset and has no output drivers, and PF7 is UPDI and reconfiguring it will brick it if you don't have an HV programmer. So that leaves us with... uhhh.... Hmm, let's go over that again
~PF6~ <- Typically reset, and in any case doesn't have output drivers at all.
~PF7~ <- UPDI, cannot be used as I/O pin without disabling UPDI. UPDI will not function with an LED on the same pin, so LED would also need to be connected afterwards.
~PA0~ ~PA1~ <- Crystal pins, need to avoid so we don't damage any crystal installed. These pins are also highly sought after - they have practically every peripheral available on them. Crystal (32 kHz or high speed), TCA0 PWM, SPI ALT3, TWI0, and both are also inputs for CCL0 (the 14-pin parts have input pins present for only 2 of their CCL logic blocks - and only 2 out of the three inputs.
~PC1~ ~PC2~ ~PC3~ <- MVIO pins, might not be powered, more likely to interfere with operation in multi-voltage scenarios.
~PD4~ ~PD5~ ~PD6~ ~PD7~ <- might be used for Serial communication with bootloader.
That leaves us with all candidates disqualified for some reason, yet choose one we must. Kind of like a lot of elections - certainly here in the US, and I'm pretty sure everywhere else with free and fair elections has felt that way at times.
The quartet of pins on PD are the best candidates. These can be split into two pairs for consideration, and seen that way there are two decisions that need to be made:
- Does one pick the higher (PD6, PD7) or lower (PD4, 5) pair? This depends on the serial port used, obviously - if USART1 is used, it can only use PD6 and PD7 for TX and RX, so the LED then has to go on PD4 or PD5; if USART0 is used, there are 3 pinsets possible, one of which implies that the LED must be on PD6 or PD7, while the other two do not impose specific constraints. So this question is trivially answered for 2 of the 4 bootloader pinset choices, and we know that those two should have the same pinout, as the alternative would be more confusion that is necessary.
- Within each pair, is the lower or upper pin a better LED pin? The pins may at first appear to be of equal value. But this is not the case. The communication methods we are concerned with here are SPI and Serial. In the case of Serial, the even pin is TX, the odd pin RX. While for SPI, even pins are MOSI and SCK for pins, or MISO or SS for odd ones.
Let's consider these uses of the pin, and what would happen if an LED was connected to the pin as well.
- SS - this pin is not used as an SPI pin through the Arduino SPI.h library. I am aware of no library that implements SPI slave (there are some awkward things about an SPI slave that make it more difficult to use than TWI slave, or a UART peer, while being very easy to use as a master. Chief among those concerns for Arduino is the expectation by masters that SPI respond fast. There is no mechanism for the slave to make the master slow down or wait until data can be prepared. Unlike UART, which is fully asynchronous and has no limit unless the programmer of the other device implements one, TWI/I2C where the slave can hold the clock line because the bus is open drain, neither of those are possible in the case of SPI. Making matters worse, SPI is generally run at much higher data rates than I2C or serial, which makes SPI slave less feasible and the SS pin less relevant). The point is, the fact that PD7 is the SPI SS pin doesn't really matter, as Arduino applications typically have SPI in master mode with the SS pin disabled (certainly that's how the SPI.h library configures it).
- TX, MOSI, SCK All of these have in common that they are typically controlled by the AVR. This is of course not always true - a USART can be used in open drain mode, or an SPI device can be a slave rather than a master (as discussed above, the SPI case is unlikely). With the exception of USART in open drain, single wire mode, these all involve the AVR driving the pin as an output, and unlike TWI, the maximum current is not throttled. These alternate functions will thus not be problematic if a LED is also connected, provided one has picked a reasonable series resistor. Imagine a 1k ohm resistor - across a LED with 1.8V forward voltage and a 1k resistor, you would have just over 3 volts across the resistor, hence just over 3 mA of current. That is what I use in my products (in fact 1k usually looks right for all colors). It is easy to demonstrate that for virtually any LED of modern manufacture, being used for a purpose other than general illumination or similar high power application, that 1mA is enough to act as an indicator. Note also that the human eye is most sensitive to green, and least sensitive to red - but red leds have lower forward voltages and with an equal resistor will get more current.
- MISO In this case, the pin is driven by the other device. Some parts have pin drivers as strong as an AVR. Many do not, however. That, in turn, raises the possibility that the LED could keep the other device from being able to drive the pin high, and interfere with a signal (though the INLVL bit could be set for the pin to lower the threshold for the pin to treat an input as a 1). Slave devices that are compliant with the SPI spec will tolerate the pin being arbitrarily driven high or low as long as their SS pin is not driven low. So that makes PD5 the worst of the four.
- RX This has the same concern as MISO - only more so, because serial devices sometimes have a resistor in series with them. To put another mark against using an alternate RX pin to drive the Optiboot LED, while SPI devices expect to be on a bus, with other devices using the same MISO line... this is not true of a typical UART connection, where the two devices are wired only to each other. The devices will thus typically have a push-pull driver, and be able to drive the pin either high or low. So toggling the pin (or rather, attempting to) while another serial device was connected would have a good chance of damaging the other device, in addition to the impediment that said LED would pose to receiving a signal. These two issues are essentially opposites - one expects that the TX pin of the other device (which we'd connect to RX) to either have low impedance (so that if the two devices try to drive the pin in opposite directions, the "loser" might be damaged) or they are higher impedance, and a milliamp or few driving a LED would drag down the output enough to not be clearly detected. In the latter case, INLVL would help - TTL level would likely be good enough that the forward voltage of the LED made incoming signals intelligible. But this doesn't help with the potential for damage if someone were to carelessly use an Optiboot-bootloaded board while attempting to use other pair of pins for serial.
So, despite the initial fog of confusion that we were surrounded by, taken together, a clear picture emerges:
- The odd pins are nominally inputs both SPI and Serial, while the even pins are outputs. Since the load of an LED can be quite small and still be clearly seen even under bright light, relative the the strength of an AVR's pin drivers (but not necessarily a non-AVR device
*(there are many parts in the wild that have pin drivers that are only capable of sourcing or sinking a few milliamps, or which only have significant drive strength when sinking current, and can barely source more current than the AVR's pullup resistor does (typically the most striking examples of these parts are old parts that first saw the light of day when open collector BJTs were the norm**), we can't have the same expectation that the pins would work for serial or even SPI with those alternate functions. - So we have ruled out PD5 and PD7. And the question of PD4 vs PD6 was handled to minimize complexity.
- All else being equal (and in this case it pretty much is), we favor a simpler rule over a more complex one. "PD4 if UART1, else PD6" is simpler than "PD4 unless UART0 used and PORTMUX set to ALT3, in which case PD6"
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 somewhat inconsistent in their value, but some are quite good.
* AVR pin drivers are are about as beefy as it gets on a microcontroller, especially on the modern AVRs: 50mA "absolute max" rating, 20mA clamp diode current, and the AVR DA-series datasheet has an output current graph where the X axis goes from 0mA to 100mA (sink) and -0mA to -50 mA (source) (raises some questions about that chart vis-a-vis the 50mA "absolute max" no?) If the pins were any stronger, if another IC thought the AVR was in power down sleep mode, and cracked a rude joke to a third device over the I2C bus they all shared, the offended AVR could could tear it's pins off the circuit board, march over to the offending chip, and beat the silicon out of it. So it's probably good that they're not any stronger ;-)
** As you may have noticed, old parts are common in Arduino circles. More than anything else, I think the reason is that the hobby has a preponderance of retired engineers who have not been keeping up with the pace of recent progress. These need not be (and rarely are) old geezers with soldering irons. Hell, if they were a high achiever in the workplace and got promoted to management quickly, by the time they retired, their practical knowledge could already be 3 decades old. These people talk to other hobbyists on forums. In fact, the former managers, having spent the majority of their careers talking, may like the talking about building stuff better than the actual building stuff part. I don't know of any statistics on this, but I'll bet among "former electronics industry workers" who are involved with hobby electronics, there is a positive correlation between how far up the corporate ladder someone got while working, and the effort they go through to write tutorials and guides and other stuff trying to help "on-board" newbies to the hobby.
More pessimistically, I fear (though I wouldn't place a bet either way) that there is a negative correlation between that same workplace achievement during their career, and the usefulness and accuracy of such guides. There are a lot of really lousy Arduino guides, often written by people who supposedly spent their career in the industry as an engineer. That we're surrounded by electronics that mostly work suggests that the guide author who claims to have spent his career in industry while demonstrating he doesn't know how to design electronics did not spent most of that career doing design work and hadn't for decades. In which case, what else could he have been doing in the industry? He was a manager!
On the third hand, not all electronics were designed by competent people. I've taken apart a lot of electronics - and you ah, you see a very wide range of skill levels in evidence. Brilliant tricks, and godawful hacks. I've seen the simplest circuit boards imaginable listing Rev K or something like that. rows of SOT23 parts rotated 120 degrees cause they designed the board for the wrong pinout. I've seen computer motherboards with no less than a half dozen E. C. O's ("Engineering Change Order" - orders from engineering to production once the product is partly assembled to go fix the boards (which have already been loaded) - this usually manifests as thin wires routed around the surface of the board and soldered to pins on various parts). That was not a budget computer - it was worth it to E. C. O. the boards (a very expensive process, all manual) because the boards must have cost a fortune to make - it was incredibly thick, implying that it had a very large number of internal layers, and it was as big as the side of a house), and it was made in the early 2000's. Even if they hadn't soldered a few hundred dollars of components onto it by the time they realized the problem, the board itself may have been expensive enough to justify.