What are the AVR28DA128 AVR32DA128 AVR48DA128 AVR64DA128 ??

Go To Last Post
77 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

Last Edited: Thu. Mar 12, 2020 - 06:56 PM
  • 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.

 

  • 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

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

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

Microchip direct appear to have some parts in stock. There is some confusion over the MOQ but, as a test, I've just ordered 25 pcs of the 128DA48. I'll see if the order gets accepted. If they arrive I'll be happy to bung a few out to fellow freaks in the UK and Europe.

#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

Thanks!

 

https://www.microchipdirect.com/product/search/all/AVR128DA48

very low MOQ for QFN; QFP is MOQ one tray.

Haven't read the datasheet to see if QFN has wettable flanks (drag soldering is akin to wave soldering)

AVR128DA48 - 8-bit Microcontrollers

 

edit : Microchip - Samples Web Site (AVR128DA48)

 

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

Last Edited: Sat. Mar 21, 2020 - 06:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That moq on the qfp parts confused me. I chanced it and placed an order for 25pcs and the system accepted it. At the moment it looks like I might get them.

#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

QTouch® Modular Library Peripheral Touch Controller User's Guide

Appendices A and K for revision history and link to the library documentation

 

Touch Sensing | Release Notes - Developer Help

 

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

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

It certainly looks like the chip family I would have loved to have had 5 years ago...

Now, it's competing with those 120MHz CM4 chips...

 

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

No DMA?  Bummer.

Letting the smoke out since 1978

 

 

 

 

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

AVR DA-series may be seen as a follow-on to XMEGA D which doesn't have DMA.

IIRC, MPLAB X v5.35 has precursor for more AVR Dx-series.

edit : MPLAB X IDE | Microchip Technology

 

 

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

Last Edited: Tue. Mar 24, 2020 - 04:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TB3233 Using ZCD to Implement Special Functions

...

B 03/2020 Updated repository links

...

 

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

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

Brian Fairchild wrote:
That moq on the qfp parts confused me. I chanced it and placed an order for 25pcs and the system accepted it. At the moment it looks like I might get them.

 

I've just had notification that 25pcs of AVR128DA48 are on their way to me!

#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: 1

***Datasheets are now on the Microchip Website***

 

http://ww1.microchip.com/downloa...

 

 

#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

***DIP parts now available on Microchip Direct***

#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

I ordered a few of the DIP ones, taking advantage of the free shipping offer this month.

Something to play around while the quarantine continues...

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

This DA family is impressive,

 

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

Wow, those pin currents and the clamp currents are much higher than the "old" chips.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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


They've escaped from the factory and landed on my bench...

 

#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: 1

AVR128DA32 arrived to me today.

It attaches without modification to the breakout for mega4808.

 

 

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

Just installed the new packs. So this is "xmega4", hum? Yeah, the architecture is different, of course 128Kb can't fit in the 64Kb linear address space. They use some kind of memory paging, or else it's back to progmem...

Time to do some experiments while waiting for the actual chips.

 

edit: and yes, as I feared constant strings are being processed like on classic AVRs, by being copied to SRAM first. So PROGMEM is back...

Last Edited: Thu. Mar 26, 2020 - 04:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So PROGMEM is back...

Looking at the data sheet, it seems that you should be able to get away with up to 32K of flash mapped into the data address space.

I'm not sure you can convince the compiler that you've set that up, though.  (Linker scripts?  Can you just move the .rodata section to the 32k of high flash and have the linker complain if it overflows?)

 

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

westfw wrote:
Linker scripts?  Can you just move the .rodata section to the 32k of high flash and have the linker complain if it overflows?

 

Well, the xmega3 have this

 

  .rodata  ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__    :
  {
    *(.rodata)
     *(.rodata*)
    *(.gnu.linkonce.r*)
  } AT> text

 

I'm guessing the AT> text means that .rodata is in the text memory region, whose size is known to the linker, so it should complain.

 

I really don't know what I'm doing, but maybe something like this for the xmega4?

  .rodata  0x8000 : AT __TEXT_REGION_LENGTH__ - 0x8000
  {
    *(.rodata)
     *(.rodata*)
    *(.gnu.linkonce.r*)
  } AT> text

 

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

I may be misunderstanding your problem.

 

I have used the last 64KB of program memory as data on xmega128A1U.
There was no problem using far pointer and pgm_read_byte_far, is that frustrating?

 

#include <avr/io.h>
#include <avr/pgmspace.h>

uint_farptr_t pgm_ptr = 0x10000;
volatile uint8_t bar;

int main(void){
    bar = pgm_read_byte_far(pgm_ptr);
    asm("nop");
    while (1);
}

 

 

Edit:--------------------------------

Oh, I just noticed.
Declared in __flash and wanted to read from the RAM address without using pgm_read_byte_far.
I have no idea.

Last Edited: Fri. Mar 27, 2020 - 08:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kabasan wrote:
I may be misunderstanding your problem.

 

As you know, on classic AVR we have 2 choices for using constant data:

  • let the compiler do it's thing, and we will be wasting SRAM, because all constant data is copied there
  • Use the facilities of pgmspace.h; this way you save SRAM, but now you need to use PROGMEM and cumbersome pgm_whatever to access the data

 

The flat address space of the AVR-0/1 had solved that problem, we could use standard C for constant data and not waste RAM. But now with the DA series the problem is back, so I'm just complaining a bit, I like to complain from time to time indecision

 

edit: and also complaining because they decided to recycle xmega4 scripts for the DA instead of going to the trouble of writing new ones that could make use of the linear mapped flash area.

Last Edited: Fri. Mar 27, 2020 - 09:56 AM