What are the AVR28DA128 AVR32DA128 AVR48DA128 AVR64DA128 ??

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

While working on avr-libc3 I cam across the 8 bit AVR family AVRDx  with the core AVR8X

 

Part numbers: AVR28DA128 AVR32DA128 AVR48DA128 AVR64DA128

 

I can't find ANY data on these parts.  Although they smell like new xmega type devices.  They have Large numbers of IO and peripherals [5 Usarts, 2 TWI, 2 SPI, Many timers, etc], large (for an 8 bit device) memories [128K Flash and 16k Ram].

 

Anyone have any insight? Are they new unreleased parts, or old old parts I have never seen before?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

https://www.avrfreaks.net/forum/come-join-us-mplab-now-supports-avrs?page=5#comment-2744286

[after the first separator]

...

The new AVR devices are in beta form for all tools except AVR simulator peripherals, MPLAB XC8, MPLAB ICD 4 :

  • AVR64DA128
  • AVR48DA128
  • AVR32DA128
  • AVR28DA128

...

 

edit :

Follow-on to the popular mega1284?  No

 

edit2 :

https://packs.download.microchip.com/#collapse-Microchip-AVRDx-DFP-pdsc

 

edit3 :

Definitely an XMEGA.

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sun. Aug 11, 2019 - 02:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

 

edit3 :

Definitely an XMEGA.

 

 

Except XMEGAS have family="XMEGAA" (or B, C, D or E)  core="AVR8_XMEGA" these new devices are:

family="AVRDx" core="AVR8X"

 

So it seems like a new Core architecture.  Maybe a successor to XMEGA?  They also sport single pin UPDI Programming and Debugging like the mega AVR 0 (4809, etc) and new attinys (416 etc).

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How I became confused :

 

'specs-avr48da128'

...

*asm_arch:
	-mmcu=avrxmega4

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahh, well I am guessing its probably the same instruction set as the xmega4.  Maybe it IS a different core internally, but from a programming perspective its the same as a xmega4.

 

Anyway, interesting chips.  I will keep an eye out for data when it drops.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They also have a new peripheral "Zero Cross Detect".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not on the right computer to check this, but didn't / doesn't the Xmega A have a zero crossing detection built into its ADC?

That is one of the stated reasons for the 0V offset at the low end of the ADC, so one can see the signal go through the zero.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not familiar with xmega, just comparing with UPDI "xtiny" chips.

The differences I find are the presence of a RAMPZ register (I'm curious to see how extended flash is implemented) and the aforementioned Zero Cross peripheral.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see

'Microchip.AVRDx_DFP.pdsc.txt'

...

vccmin="1.8"
vccmax="5.5" 

...

"MAPPED_PROGMEM" [32KB]

...

XMEGA D : 1.6V .. 3.6V, 32MHz, no DMA, no USB, program and data spaces

AVR DA   : 1.8V .. 5.5V, 32MHz, no DMA, no USB, program and data spaces, 32KB of program space mapped to data space

 

AVR DA is an excellent response to LogicGreen mega328P clone (mostly clone)

https://www.electrodragon.com/w/Logicgreen#LGT8F08.2F88.2F328_.28AVR_Compatible.29

 


'ioavr48da128.h'

/* Frequency select select */
typedef enum CLKCTRL_FREQSEL_enum
{
    CLKCTRL_FREQSEL_1M_gc = (0x00<<2),  /* 1 MHz system clock */
    CLKCTRL_FREQSEL_2M_gc = (0x01<<2),  /* 2 MHz system clock */
    CLKCTRL_FREQSEL_3M_gc = (0x02<<2),  /* 3 MHz system clock */
    CLKCTRL_FREQSEL_4M_gc = (0x03<<2),  /* 4 MHz system clock (default) */
    CLKCTRL_FREQSEL_8M_gc = (0x05<<2),  /* 8 MHz system clock */
    CLKCTRL_FREQSEL_12M_gc = (0x06<<2),  /* 12 MHz system clock */
    CLKCTRL_FREQSEL_16M_gc = (0x07<<2),  /* 16 MHz system clock */
    CLKCTRL_FREQSEL_20M_gc = (0x08<<2),  /* 20 MHz system clock */
    CLKCTRL_FREQSEL_24M_gc = (0x09<<2),  /* 24 MHz system clock */
    CLKCTRL_FREQSEL_28M_gc = (0x0A<<2),  /* 28 MHz system clock */
    CLKCTRL_FREQSEL_32M_gc = (0x0B<<2),  /* 32 MHz system clock */
} CLKCTRL_FREQSEL_t;

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

USART appear to have a 16-bit baud rate register, BREAK, SYNC (auto-baud, generic or LIN)

/* Auto Baud Window select */
typedef enum USART_ABW_enum
{
    USART_ABW_WDW0_gc = (0x00<<6),  /* 18% tolerance */
    USART_ABW_WDW1_gc = (0x01<<6),  /* 15% tolerance */
    USART_ABW_WDW2_gc = (0x02<<6),  /* 21% tolerance */
    USART_ABW_WDW3_gc = (0x03<<6),  /* 25% tolerance */
} USART_ABW_t;

 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do the first number refer to in Part numbers: AVR28DA128 AVR32DA128 AVR48DA128 AVR64DA128   ?

Package pin count ?

The 128 seems 128k Flash ? - but it's a little unusual to have the package pin count up-front in a part number ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:
Package pin count ?
Yes

Who-me wrote:
The 128 seems 128k Flash ?
Yes, program space (likely flash though competitor's have some F-RAM)

Who-me wrote:
but it's a little unusual to have the package pin count up-front in a part number ?
Indeed though the first problem bound is usually I/O (pin count) (bounds : CPU, memory, I/O, power) (power - current, voltage or wide voltage range)

 


https://packs.download.microchip.com/#collapse-Microchip-AVRDx-DFP-pdsc

unzip atpack

edc directory

a .PIC file

search for (very bottom) :

  <edc:PinList edc:ppsflavor="atmel">

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is the new naming-scheme going forward: AVR<pin-count><family-letters><flash-size>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

je_ruud wrote:

This is the new naming-scheme going forward: AVR<pin-count><family-letters><flash-size>

 

Really ? That seems quite a strange decision, from a company that gave us :

PIC12

PIC16

PIC18

PIC24

PIC32

 

and no, those are not 12/16/18/24/32 pin parts ;)

 

ST have STM8, STM32,   SiLabs have EFM8, EFM32 , STC have STC8F, STC8H,...

Can anyone spot an industry pattern here ?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Trying to find the reason behind marketing decisions is rarely worth the effort...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess the tiny/mega/xmega nomenclature was getting too blurred and messy. At least this way we can actually learn more from the names.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One 10b DAC

ioavr48da128.h

/* DAC.DATA  bit masks and bit positions */
#define DAC_DATA_gm  0xFFC0  /* Data group mask. */
#define DAC_DATA_gp  6  /* Data group position. */
#define DAC_DATA0_bm  (1<<6)  /* Data bit 0 mask. */
#define DAC_DATA0_bp  6  /* Data bit 0 position. */
#define DAC_DATA1_bm  (1<<7)  /* Data bit 1 mask. */
#define DAC_DATA1_bp  7  /* Data bit 1 position. */
#define DAC_DATA2_bm  (1<<8)  /* Data bit 2 mask. */
#define DAC_DATA2_bp  8  /* Data bit 2 position. */
#define DAC_DATA3_bm  (1<<9)  /* Data bit 3 mask. */
#define DAC_DATA3_bp  9  /* Data bit 3 position. */
#define DAC_DATA4_bm  (1<<10)  /* Data bit 4 mask. */
#define DAC_DATA4_bp  10  /* Data bit 4 position. */
#define DAC_DATA5_bm  (1<<11)  /* Data bit 5 mask. */
#define DAC_DATA5_bp  11  /* Data bit 5 position. */
#define DAC_DATA6_bm  (1<<12)  /* Data bit 6 mask. */
#define DAC_DATA6_bp  12  /* Data bit 6 position. */
#define DAC_DATA7_bm  (1<<13)  /* Data bit 7 mask. */
#define DAC_DATA7_bp  13  /* Data bit 7 position. */
#define DAC_DATA8_bm  (1<<14)  /* Data bit 8 mask. */
#define DAC_DATA8_bp  14  /* Data bit 8 position. */
#define DAC_DATA9_bm  (1<<15)  /* Data bit 9 mask. */
#define DAC_DATA9_bp  15  /* Data bit 9 position. */

 

 

"Dare to be naïve." - Buckminster Fuller