WARNING This document is based largely on speculation and the very limited public information about these parts.
[DU14 Pin Mapping](DU14.png "Arduino Pin Mapping for AVR DU14")
Image not available - absent help we do not foresee being able to provide any sort of pinout diagram for this or future parts
Please help
| | AVR[16|32]DU14 | |----------------------------------|-----------------------| | Flash Memory | 16384 or 32768 | | Flash Memory (with USB Bootload) | TBD | | SRAM | 2048 or 4096 | | EEPROM | 256 | | User Row | 512 wtf? | | Boot Row (w/e tf that is) | 256? 64? | | Max. Frequency (rated, MHz) | 24 | | Clock Sources | INT, EXT, XTAL | | Packages Available | TSSOP, SOIC-N | | Total pins on package | 14 | | I/O Pins (not reset/UPDI/USB) | 7 | | Fully async pins | All | | UPDI as I/O Pin | Yes | | PWM capable I/O pins | 5 | | Max simultaneous PWM outputs | 4: 2:2 | | 16-bit Type A Timers - pins ea | 1: 2:1:2:0 | | 16-bit Type B Timers, (pins) | 2 | | 12-bit Type D pins | TCD0 was eaten by USB | | USART (pin mappings) | 2: 2/1 | | SPI (pin mappings) | 1: 1 | | TWI/I2C (pin mappings) | 1: 1 | | 10? 12? bit ADC input pins | 5 | | Of those, neg. diff. inputs | Unknown | | 10-bit DAC | None | | Analog Comparator (AC) | 1 | | Zero-Cross Detectors (ZCD) | 1 | | Custom Logic Blocks (LUTs) | 4 | | Event System channels (out pins) | 6 (6) | | On-chip opamps (OPAMP) | None | | MVIO, pins | No | | Flash Endurance | 1k | | LED_BUILTIN (and optiboot led) | PIN_PC3 |
Yeah buddy, this is the real deal. DU parts will exist - I know there's been some doubt about this. But no, they will most certainly exist. My man on the inside confirms that everything is still on track for release before the end of the year. He didn't specify which year, though, so he's left himself room to backpedal if needed. This source also expressed his opinion that the part was needed in their product line ASAP, as if that needed to be said.
What's sort of astonishing is just how much these parts sacrifice for native USB: They lose the TCD, 2 I/O pins on an already low pincount, possibly two bits of ADC resolution. le. The 14-pin parts are particularly starved for pins: They have only 7 pins available without using reset or UPDI for I/O. MVIO was taken our of user hands and put towards shifting the levels of the USB signals it would appear. With the constrained pincount, that most peripherals have only one pinset should come as no surprise. But native USB does have a transformative effect on the parts.
All pins on the DDs are supposedly fully async, like the DD, EA, and future EB. (Earlier parts had just pins 2 and 6 within each port as Fully Async)
Only two options survived...
| USART0 | TX | RX | XDIR | XCK |
|---|---|---|---|---|
| DEFAULT | PA0 | PA1 | ||
| ALT3 | PD4 | PD5 | PD6 | PD7 |
| PC3 | - |
Uh yeah not a wealth of options here either.
| USART1 | TX | RX | XDIR | XCK |
|---|---|---|---|---|
| PC3 | ||||
| ALT2 | PD6 | PD7 | - | - |
This cut SPI0 down to size! On the 14-pin parts, reduced to a single mux option!
| SPI0 | MOSI | MISO | SCK | SS |
|---|---|---|---|---|
| PA0 | PA1 | |||
| ALT4 | PD4 | PD5 | PD6 | PD7 |
| PC3 | ||||
| PC3 | PF7 |
Looks like no dual mode at all on these unless we get some sort of band-aid
| Mapping | swap | Master or Slave | Dual Mode Slave |
|---|---|---|---|
| DEFAULT | |||
| ALT3 | 3 | SDA/PA0 SCL/PA1 |
The 14 pin PWM mapping options are less than inspiring. You get only 2 of the 6 pins that a TCA could drive, though it appears we may get a second alt mux option for TCB, and these tables are based on the assumption that they do; this allows you to get a total of 4 simultaneous PWM outputs. One more can be directed to PD6 or PD7 using the CCL (and maybe event system) to use WO3 signal to drive a pin with TCA set to PORTA.
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; you would want to avoid setting this to 1, 4 or 6 - at least if you're hoping to see PWM; Those are valid on parts with more pins, but PORTE and PORTB only appear on parts with more than 32 pins, and PORTG only on 64 pin parts), or one of the named constants of the form: PORTMUX_TCA0_PORTx_gc where x is A, C, or D - but no matter what, you hardly get any pwm pins.
| TCA0 | WO0 | WO1 | WO2 | WO3 | WO4 | WO5 |
|---|---|---|---|---|---|---|
| PORTA | PA0 | PA1 | - | - | - | - |
| PORTC | - | - | - | PC3 | - | - |
| PORTD | - | - | - | - | PD4 | PD5 |
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 if (and only if) your code is not intended for use on any parts with more than 1 TCA. This is the only bitfield there, so you needn't worry about stomping on the other timer configuration.
For code that must run on parts with any number of pins, either set both at once with simple assignment, or if that's not appropriate, be sure to only change the one you're reconfiguring. :
uint8_t tcaroutea = PORTMUX.TCAROUTEA; // Registers are volatile variables, so we want to load it like this
tcaroutea &= ~PORTMUX_TCA0_gm; // mask off the bits we're changing change
tcaroutea |= PORTMUX_TCA0_PORTx_gc; // and then set them to their new value.
PORTMUX.TCAROUTEA = tcaroutea; // then write the temp variable back to the register.
// above construction will likely take 7 clocks and 6 words - lds, andi, ori sts.
// The naive PORTMUX.TCAROUTEA &= ~PORTMUX_TCA0_gm; PORTMUX.TCAROUTEA |= PORTMUX_TCA0_PORTx_gc; is much less efficient
// It compiles to lds andi sts lds ori sts: 12 clocks and 10 words, since it has to write out and reload the values.Woah - did we get another mux option, or was it simply an error in the product brief? Note that other future parts do NOT list a third mux option for TCB0 and TCB1.
| TCBn | Default | Alt1 | Alt2 |
|---|---|---|---|
| TCB0 | PD4 | ||
| TCB1 | PD5 |
Default mappings are used, since PF4/5 are shared with the preferred TCA pins, which take priority. These are NOT PORTMUX-aware. Only the bold pin can be used without modifying or creating a new variant file.
The type B timers are much better utility timers than PWM timers. TCB1 is the default millis timer and cannot be used for PWM in that mode. We're definitely timer-starved on these parts, with only 2 TCB, and with the TCD having been fed to the USB peripheral.
There is no TCD.
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.
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" are linked.
Datasheets and errata change. You can sign up to get emails about such changes through the Microchip PCN system; if you don't, be sure to always use the latest version of the datasheet and especially the errata
- AVR32DU14 - Product page not available
- AVR16DU14 - Product page not available
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. Still waiting on one about how to get the best out of the ADC - they seem allergic to making quantitative recommendations.