WARNING This document is based largely on speculation and the very limited public information about these parts.
[DU28 Pin Mapping](DU28.png "Arduino Pin Mapping for AVR DU328")
Image not available - absent help we do not forsee being able to provide any sort of pinout diagram for this or future parts
| | AVR[16|32|64]DU28 | |----------------------------------|-----------------------| | Flash Memory | 16384, 32768 or 65536 | | Flash Memory (with Optiboot) | 15872, 32256 or 65024 | | Flash Memory (with USB Bootload) | TBD | | SRAM | 2048, 4096, or 8192. | | EEPROM | 256 | | User Row | 512 wtf? | | Boot Row (w/e tf that is) | 256 | | Max. Frequency (rated, MHz) | 24 | | Clock Sources | INT, EXT, XTAL | | Packages Available | SOIC-W, TSSOP, VQFN | | Total pins on package | 28 | | I/O Pins (not reset/UPDI/USB) | 19 | | Fully async pins | All | | UPDI as I/O Pin | Yes | | PWM capable I/O pins | 23 | | Max simultaneous PWM outputs | 8: 6:2 | | 16-bit Type A Timers - pins ea | 1: 6:1:6:6 | | 16-bit Type B Timers, (pins) | 2: 6 (3 option per!?) | | 12-bit Type D pins | TCD0 was eaten by USB | | USART (pin mappings) | 2: 4/1 | | SPI (pin mappings) | 1: 5 | | TWI/I2C (pin mappings) | 1: 3 | | 12-bit ADC input pins | 18/22 | | Of those, neg. diff. inputs | all | | 10-bit DAC | 1 | | Analog Comparator (AC) | 1 | | Zero-Cross Detectors (ZCD) | 1 | | Custom Logic Blocks (LUTs) | 4 | | Event System channels (out pins) | 6 (7) | | On-chip opamps (OPAMP) | None | | MVIO, pins | Yes, 4 | | Flash Endurance | 1k | | LED_BUILTIN (and optiboot led) | PIN_PA7 |
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. And that the low pincount parts aren't being made in 64k versions :-/
All pins on the DDs are supposedly fully async, instead of just pins 2 and 6 within each port, like the DD, EA, and future EB.
(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 | TX | RX | XDIR | XCK |
|---|---|---|---|---|
| DEFAULT | PA0 | PA1 | PA2 | PA3 |
| ALT1 | PA4 | PA5 | PA6 | PA7 |
| ALT2 | PA2 | PA3 | - | - |
| ALT3 | PD4 | PD5 | PD6 | PD7 |
| PC3 | - |
| USART1 | TX | RX | XDIR | XCK |
|---|---|---|---|---|
| PC3 | ||||
| ALT2 | PD6 | PD7 | - | - |
Yowch, SPI0 took it in the shorts here...
| SPI0 | MOSI | MISO | SCK | SS |
|---|---|---|---|---|
| DEFAULT | PA4 | PA5 | PA6 | PA7 |
| PA0 | PA1 | |||
| ALT4 | PD4 | PD5 | PD6 | PD7 |
| PC3 | ||||
| PC3 | PF7 |
This is what seems to be implied by precedent. However, it is likely that they've got a fix in mind, since they list dual mode as a feature, and... obviously it's not much of a feature with that mux chart. My guess from the brief is that we will get two mux options, one with PA0, PA1 as master and PA2, PA3 as slave, and the other with PA2, PA3 as master and PA0, PA1 as slave
| Mapping | swap | Master or Slave | Dual Mode Slave |
|---|---|---|---|
| DEFAULT | 0 | SDA/PA2 SCL/PA3 | |
| ALT3 | 3 | SDA/PA0 SCL/PA1 |
The 32-pin package finally gives you a bit of breathing room with portC mostly gone.
- TCA0 can get it's full suite of pins PORTA, PORTD or PORTF. But ports D and A have extremely tight competition for pins, making the comparatively underused expanse of PORTF the favored option. . With other peripherals occupying pins on PORTA, we use PORTF by default.
- TCD0 again makes sense on DEFAULT or ALT4 (ALT2 not being used unless TCA is moved elsewhere).
- All TCBs can PWM - though the alt pins overlap with those of TCA0, and one is usually used for millis; if a TCB is used for millis timekeeping, it can't be used for PWM.
- This means by default, PF0-5, and PA2 will be available for PWM. (PA3 would be, except that timer will be used by millis).
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, D or F.
| TCA0 | WO0 | WO1 | WO2 | WO3 | WO4 | WO5 |
|---|---|---|---|---|---|---|
| PORTA | PA0 | PA1 | PA2 | PA3 | PA4 | PA5 |
| PORTC | - | - | - | PC3 | - | - |
| PORTD | PD0 | 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. 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 | PA2 | PD4 | |
| TCB1 | PA3 | 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
- AVR64DU28 - Product page not available
- AVR32DU28 - Product page not available
- AVR16DU28 - 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.