Skip to content

Latest commit

 

History

History
185 lines (150 loc) · 16.9 KB

DB48.md

File metadata and controls

185 lines (150 loc) · 16.9 KB

AVR128DB48/AVR64DB48/AVR32DB48

Pin Mapping / Pinout

DB48 Pin Mapping

Features and Peripherals

- AVR32DB48 AVR64DB48 AVR128DB48
Flash Memory 32768 65536 131072
Flash Memory (With Optiboot) 32256 65024 130560
SRAM 4096 8192 16384
EEPROM 512 512 512
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 TQFP, VQFN TQFP, VQFN TQFP, VQFN
Total pins on package 48 48 48
I/O Pins (not reset/UPDI) 40 40 40
Fully async pins 9 9 9
UPDI as I/O Pin No No No
PWM capable I/O pins 36 38 36 38 36 38
Max simultaneous PWM outputs 18: 12+2+4 18: 12+2+4 18: 12+2+4
16-bit Type A Timers - pins ea 2: 34, 9 2: 34, 9 2: 34, 9
16-bit Type B Timers, (pins) 4: 8 4: 8 4: 8
12-bit Type D pins 4 10 4 10 4 10
USART (pin mappings) 5: 2/2/2/2/1 5: 2/2/2/2/1 5: 2/2/2/2/1
SPI (pin mappings) 2: 2/2 2: 2/2 2: 2/2
TWI/I2C (pin mappings) 2: 2/2 2: 2/2 2: 2/2
12-bit ADC input pins 18 18 18
Of those, neg. diff. inputs 12 12 12
10-bit DAC 1 1 1
Analog Comparator (AC) 3 3 3
Zero-Cross Detectors (ZCD) 2 2 2
Custom Logic Blocks (LUTs) 6 6 6
Event System channels (out pins) 10: 7 10: 7 10: 7
On-chip opamps (OPAMP) 3 3 3
MVIO, pins Yes, 8 pins Yes, 8 pins Yes, 8 pins
Flash Endurance 1k 10k 1k 10k 1k 10k
LED_BUILTIN (and optiboot led) PIN_PA7 PIN_PA7 PIN_PA7

* 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.

DB48 - the improved 48-pin Dx-series part

Take a DA64. Remove the PTC which we can't use from within Arduino, and a few minor errata. Add MVIO, support for an external crystal, a trio of OPAMPs and you've got the DB48. 48-pins gets same peripherals as the 32-pin parts, plus 2 USARTs, a ZCD, the third and final OPAMP and a TCB, plus an extra pinset for each SPI and TWI port. This has the second highest peripheral densitiy in the Dx-series - rivaled only by the DD14 (and that is debatable). The improvement is only made more noticeable by the fact that these also get their PD0 pin back.

Fully async pins

Pins 2 and 6 within each port 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. The rest are "partially async" and can only respond to "low level" or "change" if there is no system clock running (all interrupt triggers will work if the I/O clock is running due to an RUNSTBY that requests it or because you are only in idle sleep mode).

USART mux options

All TX RX XDIR XCK
DEFAULT Px0 Px1 Px2 Px3
ALT1 Px4 Px5 Px6 Px7
NONE - - - -

Px refers to a port:

USART PORT
0 PORTA
1 PORTC
2 PORTF
3 PORTB
4 PORTE

USART4 hence has no alternate pin mapping, as it has only PE0-3

SPI mux options

SPI Swap name MOSI MISO SCK SS
SPI0 DEFAULT SPI0_SWAP0 PA4 PA5 PA6 PA7
SPI0 ALT1 SPI0_SWAP1 PE0 PE1 PE2 PE3
SPI1 DEFAULT SPI1_SWAP0 PC0 PC1 PC2 PC3
SPI1 ALT1 SPI1_SWAP1 PC4 PC5 PC6 PC7

The SPI library only makes one SPIClass object available (see The SPI.h library documentation for details).

TWI0 mux options

Mapping swap Master or Slave Dual Mode Slave
DEFAULT 0 SDA/PA2 SCL/PA3 SDA/PC2 SCL/PC3
ALT1 1 SDA/PA2 SCL/PA3 SDA/PC6 SCL/PC6
ALT2 2 SDA/PC2 SCL/PC3 SDA/PC7 SCL/PC7

TWI1 mux options

Mapping swap Master or Slave Dual Mode Slave
DEFAULT 0 SDA/PF2 SCL/PF3 SDA/PB2 SCL/PB3
ALT1 1 SDA/PF2 SCL/PF3 Not avail.
ALT2 2 SDA/PB2 SCL/PB3 Not avail.

Note that this means that you want Wire1.swap(0 or 2), never Wire1.swap(1) on 48-pin parts

PWM Pins

48-pins is an exciting breakpoint for PWM: You get another half dozen PWM pins from the second TCA1!

  • TCA0 is by default set to PORTC. This is a decision I would have made differently had I owned a crystal ball during the design process; but by the time the DBs had arrived with MVIO on PORTC (hence a poor pick for default pins for PWM), the core had been released and we don't like to break backwards compatibility. It's not much of an issue now that you can trivially switch the ports at runtime. Were I doing this now, I'd have likely defaulted PF, since PF is not the MVIO port.
  • TCA1 is by default set to PORTB, the only port on which it can have 6 pins on 48-pin DA's
  • TCD0 is left at the default pins on PORTA, because they are the only ones that work on DA and DB parts due to the errata
  • The 4 type B timers are set for PF4, PF5, PC0 and PC1, and this cannot be changed at runtime. Note that the millis timer cannot be used to generate PWM. TCB2 is the default millis timer, though this can be changed from the tools menu.
  • This gives 6 + 6 + 2 + 4 = 18 PWM channels simultaneously outputting PWM, 45% of the total on the part! 34/40 pins (85%) can output PWM from TCA0, and 9 (22.5%) from TCA1, with 8 (20%) having two TCA options.

TCA mux options

The Type A timers (TCA0 and TCA1) 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, and TCA1 to PORTB. Using this feature is easy - but not quite as trivial as other parts, since there are two bitfields. You simply write to the portmux register PORTMUX.TCAROUTEA = (TCA1 pinset) | (TCA0 pinset) and then analogWrite() normally. TCA0 pinset is the port number (0-5 for ports A-F), TCA1 pinsets are from the table below, with numeric values of 0x00 and 0x08 (0-1 << 3; It is recommended to use the named constants however, as shown in the example). The DB48 parts have only two mux options.

TCA0 WO0 WO1 WO2 WO3 WO4 WO5
PORTA PA0 PA1 PA2 PA3 PA4 PA5
PORTB PB0 PB1 PB2 PB3 PB4 PB5
PORTC PC0 PC1 PC2 PC3 PC4 PC5
PORTD PD0 PD1 PD2 PD3 PD4 PD5
PORTE PE0 PE1 PE2 PE3 - -
PORTF PF0 PF1 PF2 PF3 PF4 PF5
TCA1 WO0 WO1 WO2 WO3 WO4 WO5
PORTB PB0 PB1 PB2 PB3 PB4 PB5
PORTC PC4 PC5 PC6 - - -
// Simple Assignment:
PORTMUX.TCAROUTEA = PORTMUX_TCA0_PORTF_gc | PORTMUX_TCA1_PORTB_gc; // PWM on PORTF and PORTB pins 0-5

// one-liner, set TCA0 PORTD (not as readily generalizable):
PORTMUX.TCAROUTEA = (PORTMUX.TCAROUTEA & PORTMUX_TCA1_gm) | PORTMUX_TCA0_PORTD_gc; // Move TCA0 PWM to PORTD but don't change TCA1 PWM
// The first option is slightly faster, as it isn't a read-modify-write. You almost always want TCA1 mux to be set to PORTB.
// Note that PORTMUX_TCA0_PORTA_gc and PORTMUX_TCA1_PORTB_gc have a numeric value of 0. So for the common case, you can use simple assignment to set
// PORTMUX.TCAROUTEA to PA, PB, PC, PD, PE, or PF

// Maximally generalizable method (for any multi-bit bitfield w/in a a register):
uint8_t tcaroutea = PORTMUX.TCAROUTEA;  // Registers are volatile variables, so load it to temporary variable to change it in multiple steps
tcaroutea &= ~PORTMUX_TCA0_gm;          // mask off the bits we will change. This method (copy to local var, &= ~THIS_BITFIELD_gm, |= THIS_GROUPCODE_gc ) generalizes better
tcaroutea |= PORTMUX_TCA0_PORTx_gc;     // and then set them to their new value.
PORTMUX.TCAROUTEA = tcaroutea; //since the  then write the temp variable back to the register.

// The above constructions will both give 7 clocks and 6 words and the compiler output identical - lds, andi, ori, sts (while the simple assignment would optimize down to only 3 words, 3 clocks (ldi, sts)).

// In contrast, the naive method:
PORTMUX.TCAROUTEA &= ~PORTMUX_TCA0_gm;
PORTMUX.TCAROUTEA |= PORTMUX_TCA0_PORTx_gc;
// takes 12 clocks/10 words - t has to load the value, modify, and store it, and then reload it, make the second modification, and store it again.

TCB mux options

TCBn Default Alt
TCB0 PA2 PF4
TCB1 PA3 PF5
TCB2 PC0 PB4
TCB3 PB5 PC1

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. TCB2 is the default millis timer and cannot be used for PWM in that mode.

TCD0 mux options

TCD0 WOA WOB WOC WOD
DEFAULT PA4 PA5 PA6 PA7
ALT1 PB4 PB5 - -
ALT2 PF0 PF1 PF2 PF3

The Type D timer, TCD0, has 2 output channels (WOA and WOB) and 4 output pins (WOA, WOB, WOC, and WOD). The hardware permits WOC and WOD to each output either WOA or WOB, but this added too much complexity to analogWrite; WOA and WOC output WOA, and WOD and WOB output WOB. Calling analogWrite() on either pin will enable it, calling digitalWrite() on that pin will turn the PWM off. Calling analogWrite() on WOC while already outputting on the WOA pin will result in both pins outputting the new duty cycle. Call digital write on first pin if this is not what you want. The datasheet describes TCD0 output on PA4-7, PB4-7, PF0-3, and PG4-7. What the datasheet giveth, the errata taketh away: the alternate pin options are hopelessly broken currently, only PA4-7 work.

LED_BUILTIN

Following precedent set by MegaCoreX, we declare that pin 7 - PIN_PA7 shall be the pin that the core "expects" to be connected to an LED. LED_BUILTIN is defined as that pin, and the bootloader will set that pin as output and try to blink the LED. Note that if the bootloader is not used, and your sketch does not reference LED_BUILTIN this pin is not otherwise treated any differently. This can be overridden if a custom board definition is created by passing -DLED_BUILTIN = (some other pin) in the build.extra_flags field.

Reset pin can be input

Reset (PF6) can be set to work as an input (but never an output). The UPDI pin cannot be configured as an I/O pin.

ADC pins in differential mode

Only pins on PORTD and PORTE can be used as the negative side of a differential analog reading (analogReadDiff(), see Analog Reference). Pins on PORTF can be used as positive or single ended ADC inputs only.

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".

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

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 "silicon errata and datasheet clarification" is an extremely important document, particularly for parts like the DA with lots of errata. This document details lists and gives a terse description of ways in which they know that the hardware they are shipping does not behave as the datasheet describes. Both phrases are euphemisms. "Silicon Errata" are bugs in the hardware, which the manufacturer admits and agrees are incorrect behavior, and comes with a rarely fulfulled promise of a silicon revision to correct them. A "workaround" which may or may not be useful may by listed, or they may say "None". The workaround line may or may not be an accurate mirror on reality. For example, a "This feature does not work" erratum might have "Workaround: Do not use this feature" (not much of a workaround). But - for once - this goes both ways. An erratum listed as having no workaround occasionally in fact has a workaround. On he DA and DB, whichever pin the ADC is pointed at has it's digital input buffer disabled. All you need to to to work around that is set the ADC mux to point to something that's not a pin except when using it (that's what we do). I suspect a tunnel vision effect is in evidence here - in that example, I suspect that the problem was noticed in the context of trying to read the digital value of the pin while analog measurement was ongoing, so engineering was not thinking "Why the hell would anyone do that?!" but "Gee, yeah, there's no way you could do that", and nobody realized that there's a far more common case: the ADC is enabled, but not in use, and you may be doing other things with the pin.

That's the silicon errata part. Now the "datasheet clarification"? They are also usually silicon bugs (though a few are literal clarifications, or "clarifications" as in "we updated that, but forgot to tell documentation") - the Dx-series TCA Edge bit seems to have been such a case. The key difference between a silicon bug treated as an erratum and one treated with a datasheet clarifications is that an erratum indicates that the intended fix involves changing the die, while Datasheet Clarification involves changing the datasheet to say that the current behavior is correct. Datasheet clarifications sometimes downgrade specs significantly (like flash endurance under pessimal conditions, for example). And Datasheet Clarifications disappear from the errata when incorporated into the datasheet, so making certain to have matching versions of the datasheet and errata is essential.

The "Technical Briefs" are somewhat inconsistent in their value, but some are quite good.