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?
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.
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).
How I became confused :
'specs-avr48da128'
...
*asm_arch: -mmcu=avrxmega4...
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.
They also have a new peripheral "Zero Cross Detect".
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
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.
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;
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;
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 ?
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 ?
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">
This is the new naming-scheme going forward: AVR<pin-count><family-letters><flash-size>
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 ?
Trying to find the reason behind marketing decisions is rarely worth the effort...
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.
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. */
Part numbers: AVR28DA128 AVR32DA128 AVR48DA128 AVR64DA128
AVR128DA32 - 8-bit Microcontrollers
AVR128DA48 - 8-bit Microcontrollers
AVR128DA64 - 8-bit Microcontrollers
AVR<pin-count><family-letters><flash-size>
Seems bizarre to make pin-count the "most significant" part !
Trying to find the reason behind marketing decisions is rarely worth the effort
Sad, but true.
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 ;)
Right you are. Marketing decide to swap it, so the device naming is now:
AVR<flash-size><family-letters><pin-count>
http://packs.download.atmel.com/#collapse-Atmel-AVR-Dx-DFP-pdsc
...
1.0.16 (2019-11-07)
Initial release.
...
GitHub - MicrochipTech/Bootloaders_for_AVR-DA_Family
Loader's computer language is Python (scripts directory)
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
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.
It's possible to create Atmel Start projects for these chips, browsing the options gives a good idea of their capabilities.
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
...
Device Support | MPLAB X IDE (v5.30)
[pages 48 and 49]
[AVR DA-series and AVR DB-series]
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.
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.
Hmmm, only just got around to taking a closer looks at these. A stroll through the device packs is very interesting.
https://packs.download.microchip.com/#collapse-Microchip-AVR-Dx-DFP-pdsc
...
1.0.18 (2020-01-03)
Initial release.
...
AVR-DA Product Family Sell Sheet
via
[27-Jan-2020]
edit :
Ideally, that typo is due to the rush to release (announcement to major media)
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...)
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?
Is it alien tech?
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.
Yes and thanks for the archived pack.
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...).
GitHub - MicrochipTech/avr128da48-adc-accumulation-example
GitHub - MicrochipTech/avr128da48-adc-differential-example
GitHub - MicrochipTech/avr128da48-adc-evsys-example
GitHub - MicrochipTech/avr128da48-gpio-debouncing-example
GitHub - MicrochipTech/avr128da48-i2c-send-receive-example
GitHub - MicrochipTech/avr128da48-led-blink-delay-example
GitHub - MicrochipTech/avr128da48-led-blink-interrupt-example
GitHub - MicrochipTech/avr128da48-led-blink-pwm-example
GitHub - MicrochipTech/avr128da48-led-blink-sleep-example
GitHub - MicrochipTech/avr128da48-led-dimming-pwm-example
GitHub - MicrochipTech/avr128da48-led-toggle-example
GitHub - MicrochipTech/avr128da48-rtc-oled-example
GitHub - MicrochipTech/avr128da48-usart-example
GitHub - MicrochipTech/avr128da48-using-12-bit-adc
Using 12-Bit ADC for Conversions, Accumulation, and Triggering Events
edit : strikethru, ADC technical brief
Nice, lots of example software. Now all we need are the chips to try it on!
Wow, package pinouts, they are looking goofy on my browser, better start tonight before they get out the Neuralizer.
