What are the AVR28DA128 AVR32DA128 AVR48DA128 AVR64DA128 ??

Go To Last Post
53 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: 1

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

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

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

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


Oo-er more 16K RAM AVRs !

 

Shame about:

 

 

though :-(

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

je_ruud wrote:
AVR<pin-count><family-letters><flash-size>

Seems bizarre to make pin-count the "most significant" part !

 

surprise

 

but then je_ruud wrote:
Trying to find the reason behind marketing decisions is rarely worth the effort

Sad, but true.

 

frown

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

je_ruud wrote:
AVR<pin-count><family-letters><flash-size>

Seems bizarre to make pin-count the "most significant" part !

 

Agreed, but the above links seem to suggest Microchip had second thoughts and it now is 

 

AVR<flash-size><family-letters>​​​​​​​<pin-count>

 

Maybe someone smarter pointed out to marketing, that AVR32 was already taken, and no one is expecting AVR32 to be a 32 pin 8 bit AVR  ?

 

Of course, they still need to now avoid 32k Flash parts ;)

​​​​​​​

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

Right you are. Marketing decide to swap it, so the device naming is now:

  AVR<flash-size><family-letters>​​​​​​​<pin-count>

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

smiley

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

http://packs.download.atmel.com/#collapse-Atmel-AVR-Dx-DFP-pdsc

...

1.0.16 (2019-11-07)

Initial release.

...

 

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

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

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

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

GitHub - MicrochipTech/Bootloaders_for_AVR-DA_Family

Loader's computer language is Python (scripts directory)

 

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

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

That is interesting the atpack (Atmel.AVR-Dx_DFP.1.0.16.atpack\gcc\dev\avr128da64\device-specs\) has

 

*self_spec:
    %<mmcu=* -mmcu=avrxmega4 %<mshort-calls %<msp8

 

which seems like it might work on my old 18.04 Ubuntu packaged tool chain that is presently complaining about my m4809 project (I'm working on other stuff though so don't worry about this issue).

 

$ make
avr-gcc -Os -g -std=gnu99 -Wall -ffunction-sections -fdata-sections  -DF_CPU=16000000UL   -DBAUD=38400UL -I.  -mmcu=atmega4809 -B ../lib/Atmel.ATmega_DFP.1.4.331.atpack/gcc/dev/atmega4809/ -I ../lib/Atmel.ATmega_DFP.1.4.331.atpack/include/ -c -o main.o main.c
main.c:1:0: error: unknown core architecture ‘avrxmega3’ specified with ‘-mmcu=’
 /* Blink LED
 ^
main.c:1:0: note: supported core architectures: avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega2 avrxmega4 avrxmega5 avrxmega6 avrxmega7 avrtiny avr1
<builtin>: recipe for target 'main.o' failed
make: *** [main.o] Error 1

 

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

avr128da64 @ $1.88...

 

https://www.futureelectronics.com/p/avr128da64-e-mr-C215076749

 

and my AS7 just got updates for the parts, I think this is about to release.

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

It's possible to create Atmel Start projects for these chips, browsing the options gives a good idea of their capabilities.

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

Atmel START Release Notes - November 30th, 2019 release

[bottom]

AVR Content

New devices

  • AVRDA Device Family:

    AVR128DA28, AVR128DA32, AVR128DA48, AVR128DA64

New Board

  • AVR128DA48 Curiosity Nano

...

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

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

Device Support | MPLAB X IDE (v5.30)

[pages 48 and 49]

[AVR DA-series and AVR DB-series]

 

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

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

Using ZCD to Implement Special Functions

Author: Gheorghe Turcan, Microchip Technology Inc.

The Microchip AVR-DA family of microcontrollers features up to three Zero-Cross Detectors (ZCD) with flexible input selection, requiring only one external component, and configurable output (interrupts on rising/falling or both edges, event generation, and output inversion).

...

apparently added to documentation today.

 

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

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

gchapman wrote:
Author: Gheorghe Turcan, Microchip Technology Inc.

Hey, this guy has authored some pretty interesting appnotes. I sense Microchip's analog expertise in him, so it seems the AVR-DA are already a product of Atmel+Microchip know-how. I'm looking forward to these and more products.

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

Hmmm, only just got around to taking a closer looks at these. A stroll through the device packs is very interesting.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

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

...

1.0.18 (2020-01-03)

Initial release.

...

 

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

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

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

Last Edited: Wed. Feb 19, 2020 - 01:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR-DA Product Family Sell Sheet

via

Product Brochures

[27-Jan-2020]

 

edit :

  • AVR DA-series will be in Microchip's functional safety MCU
  • 'Atmel' removed other than in one URL (Atmel START)
  • AVR128DA48 Curiosity Nano
  • SPDIP AVR128DA28; likewise SOIC

 

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

Last Edited: Sat. Feb 1, 2020 - 06:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

opps

 

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

Ideally, that typo is due to the rush to release (announcement to major media)

 

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

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

also atpack update

 

Atmel AVR-Dx Series Device Support (1.0.21)

 

update: oops BUILDNUMBER leaking in atpack package.content file (e.g., <release version="1.0.BUILDNUMBER">Added PTC information...)

 

Last Edited: Sat. Feb 1, 2020 - 07:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


ron_sutherland wrote:
Added PTC information

 

Yay... PTC events, when the PTC operation itself remains a secret. Really, I don't get this policy... What's the big deal about revealing how it operates? Is it alien tech?

 

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

laugh

El Tangas wrote:
Is it alien tech?
PB megaAVR tech though I don't recall

AVR-DA Product Family Sell Sheet

[mid-page 1, top of right column]

  • [PTC] Boost Mode ...

PTC Driven Shield is a part of ATTINY817 Water Tolerance demo kit (tinyAVR 1-series)

A capacitance sensor can be a part of a distance sensor though that can also be by inductance; PTC may have more than the obvious use cases.

 

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

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

PTC has to do with capacitive touch sensing, right?

 

https://github.com/epccs/AVR-Dx_...

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

Yes and thanks for the archived pack.

 

 

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

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

ZCD is not in any other AVR? Has anyone used this sort of hardware (e.g., perhaps on a PIC), I think it sounds correct for a variable reluctance sensor (e.g., flow meter, crankshaft...).

 

https://www.microchip.com/design...

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

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

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

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

Last Edited: Wed. Feb 19, 2020 - 01:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

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

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

Nice, lots of example software. Now all we need are the chips to try it on!

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

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

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

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

Last Edited: Fri. Feb 14, 2020 - 01:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Wow, package pinouts, they are looking goofy on my browser, better start tonight before they get out the Neuralizer.