XMEGA Family is Losing in the Popularity Polls

Go To Last Post
139 posts / 0 new

Pages

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

I don't think we will see any more XMEGA parts now. It's a shame, an XMEGA with 1 meg flash like some of the PIC24 parts would be fantastic. Unfortunately there is no way Microchip will invest the money to make such a device.

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

Who-me wrote:
[8051]... and good eco-system....
an 8051 fyi :

  • PlatformIO added 8051 by the Small Device C Compiler with a few boards from Nuvoton (Taiwan and 5 offices in China) and stcmicro.com (China)
  • Silicon Labs has a zero price 8051 compiler by Keil

https://platformio.org/platforms/intel_mcs51/packages

https://www.silabs.com/products/mcu/8-bit/8-bit-microcontroller-technology#eight

 

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

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

jalbinson wrote:
...  but  if Microchip loose interest in the ATXMEGA range, ...
Today had datasheet updates for XMEGA A1U and E5.

Clarifications and several data updates except for XMEGA A1U ordering :

  • Removal of XMEGA64A1U from 105C
  • Addition of 105C XMEGA128A1U in 0.8mm pitch BGA

Product Change Notification - SYST-29NYLM786 - 30 Aug 2018 - Data Sheet - ATxmega128A1U/62A1U Data Sheet

http://www.microchip.com/mymicrochip/NotificationDetails.aspx?pcn=SYST-29NYLM786

...

 

Description of Change:  1) Updated the document to Microchip style. 2) New Microchip document number. 3) Previous version was Atmel document 8285 rev. I. 4) Updated “Ordering Information” on page 8. 5) Added ATxmega128A1U-CN and ATxmega128A1U-CNR @ 105°C. 6) Removed ATxmega64A1U @ 105°C. 7) Updated “ Clock and Oscillator Characteristics” on page 115 @ 105°C. 8) Added Factory calibration accuracy values for internal oscillator (32.768kHz, 2MHz and 32MHz). 9) Added condition for User calibration accuracy (32.768kHz, 2MHz and 32MHz) @ 64°C and @ 105°C.

 

...

Product Change Notification - SYST-29DSEM474 - 30 Aug 2018 - Data Sheet - ATxmega32E5/16E5/8E5 - Complete Datasheet

http://www.microchip.com/mymicrochip/NotificationDetails.aspx?pcn=SYST-29DSEM474

...

 

Description of Change: 1) Updated the document to Microchip style. New Microchip document number. Previous version was Atmel document 8153 rev. K. 2) Updated “8MHz Calibrated Internal Oscillator” on page 28 for the clarification of the frequency drift.

 

...

http://www.microchip.com/mymicrochip/Reports.aspx

 

Edit : PCN URL

 

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

Last Edited: Fri. Aug 31, 2018 - 02:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would be nice to see some of the PIC24 features added to XMEGA. 1 meg flash memory and 96k RAM sounds nice.

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

mojo-chan wrote:

Would be nice to see some of the PIC24 features added to XMEGA. 1 meg flash memory and 96k RAM sounds nice.

I would be pleased with 128K flash variants ("normal" range without pointer extensions) but with more ram, e.g. 48K, 56K (all within the data range without pointer extensions).

 

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

mojo-chan wrote:
I don't think we will see any more XMEGA parts now.
Where do you draw the line as to what actually constitutes an "Xmega". It seems like all of Microchips most recent releases (the so called "Xtiny") are all really Xmega chips in all but name - they certainly seem to have "Xmega peripherals" rather than the traditional "tiny/mega peripherals".

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

clawson wrote:

mojo-chan wrote:
I don't think we will see any more XMEGA parts now.
Where do you draw the line as to what actually constitutes an "Xmega". It seems like all of Microchips most recent releases (the so called "Xtiny") are all really Xmega chips in all but name - they certainly seem to have "Xmega peripherals" rather than the traditional "tiny/mega peripherals".

The Xtiny's are certainly not Xmega. Maybe that's why people call them "xtiny" and not "xmega". Nothing to do with the microchip "tiny" in the name. They are just a step-back from xmega (except the program space mapping to data space). I don't understand this step back, maybe we are all wrong and they are a step forward (from tiny/mega)... who knows...

I would like to see a unified avr family with the best of two worlds: a single (maximal) avr cpu core, interrupts from xmega, osc, clocks, pll from xmega, eeprom and flash mapping to data space, the best of the peripherals (mostly xmega's but room for improvements exists...)

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

clawson wrote:

mojo-chan wrote:
I don't think we will see any more XMEGA parts now.
Where do you draw the line as to what actually constitutes an "Xmega". It seems like all of Microchips most recent releases (the so called "Xtiny") are all really Xmega chips in all but name - they certainly seem to have "Xmega peripherals" rather than the traditional "tiny/mega peripherals".

 

That's true, and they are very nice parts. Much of my work requires the bigger parts though, more pins and memory than the tiny range.

 

Having said that an E5 or xtiny with USB would be great, I could do a lot with that. There are lots of applications where you want a host PC to control some relatively simple stuff via USB, so a little MCU with 8k flash/4k bootloader and USB would be ideal.

 

Sadly I don't have the volume to interest Atmel Microchip.

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

An application note was updated last month :

Microchip Technology

Application Notes

AN2777: XMEGA ADC Oversampling

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591705

09/10/2018

Description

The XMEGA controller offers an analog to digital converter with 12-bit resolution. In most cases 12-bit resolution is sufficient, but in some cases higher accuracy is desired. Special signal processing techniques can be used to improve the resolution

...

http://ww1.microchip.com/downloads/en/AppNotes/AN2777-XMEGA-ADC-Oversampling-00002777A.pdf

Author: Rupali Honrao, Microchip Technology Inc.

...

(page 6)

1.5 When Will ‘Oversampling and Decimation’ Work?

[Gaussian noise]

[artificial noise (dithering)]

...

(page 13)

6. Revision History

A

09/2018

• Microchip DS00002777A replaces AVR8498A.

• New template and Source Code Overview updated as per Atmel START example

...

 

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

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

i think you should'nt consider Xmega as hobby !

it's not !!

but unfortunately yes it's not popular.

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

Yesterday for XMEGA64A1U in 0.8mm pitch BGA (100L TFBGA (9mmx9mmx1.2mm)), a reel's quantity will be reduced from 2500 per reel to 2000 per reel.

Product Change Notification - LIAL-18GFKH992 - 11 Oct 2018 - CCB 3417 Final Notice: Implement Base Quantity Multiple (BQM) changes to selected Atmel Products.

https://www.microchip.com/mymicrochip/NotificationDetails.aspx?pcn=LIAL-18GFKH992

11 Oct 2018

...

CCB 3417 Final Notice: Implement Base Quantity Multiple (BQM) changes to selected Atmel Products.

...

 

Affected Catalog Part Numbers (CPN)

(page 2 of 2)

ATXMEGA64A1U-CURA0

 

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

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

All new or upgraded designs I makes get either a ATxmega32A4U-MH or a ATxmega64A3U-MH (and ...128A3U..) depending on needed I/O and SRAM and board space.

 

Possibly one problem with XMEGA is that the controllers have so many features that some designers are scared off ?

 

A great feature with XMEGA are that you can use a slow crystal (like 4 or 8 MHz) and use PLL to multiply speed up to controllers limit.  (Like using 8M crystal you can get 16M, 24M or 32M core speed just be firmware change)

More even peripherals, like timers, makes it faster to past code from existing projects (well debugged code :) ) into a projects and do a simple swap to a free timer (or other)

 

What could be better is 12 bit ADC that has more noise than ideal when used for more than 10 bits resolution. A better temp sensor might be useful, but not critical as controllers self heat do apply anyway.

Atmels description on all the features and on self programming (that you need to make a boot loader) could also been better.

 

That XMEGA range are not so popular make no sense in my view, I do not know about any 8-bit controller that is even close.

Last Edited: Tue. Oct 23, 2018 - 12:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MortenB wrote:
That XMEGA range are not so popular make no sense in my view, I do not know about any 8-bit controller that is even close.
The new Xtiny range ? ;-)

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

    Arduino avoided Xmega for years but quickly jumped on Mega4809 when most people did not figure out yet how it is working. Yet, the way Arduino introduces the Mega4809 is wrong in my view. At 45USD, I don't think is what most people want. Also, being such a complex board, it would be difficult to be cloned, so I expect that in one year or two, will end up on "discontinued" product list.

 

    What I would like to see, would be an Uno with a Mega4809. Maybe more pins on the headers to give access to more UARTs SPIs etc.

 

    So, XMega was and it is great.

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

clawson wrote:

MortenB wrote:
That XMEGA range are not so popular make no sense in my view, I do not know about any 8-bit controller that is even close.
The new Xtiny range ? ;-)

But Xtiny are not available anywhere, any good links for info ?

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

MortenB wrote:
But Xtiny are not available anywhere, any good links for info ?
Eh? I just picked one at random : ATtiny1617 and looked it up on Octopart:

 

https://octopart.com/search?gcli...

 

That certainly seems to suggest stock availability at various vendors:

 

 

EDIT: picked a few more like ATtiny212, ATtiny214, Attiny416 and Octopart shows stocks for all of them.

 

EDIT: just to be clear these are the "Xtiny" I am talking about:

 

 

The fact is that they are just called "Tiny" but these kind of chips owe a lot more to Xmega than Tiny/Mega in their design so they are more like "Xtiny" than old style, plain "Tiny" chips. They effectively have "Xmega peripherals".

 

This seems to be Microchip's main growth area for 8bit AVR just now as they recognise that as Cortex encroaches onto typical mega/xmega territory there's still a market for "loaded" Tiny chips.

Last Edited: Tue. Oct 23, 2018 - 02:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

This seems to be Microchip's main growth area for 8bit AVR just now as they recognise that as Cortex encroaches onto typical mega/xmega territory there's still a market for "loaded" Tiny chips.

 

Unfortunately this seems to be true. There are still lots of applications where ARM just can't compete with 8 bit but you still need the power of XMEGA or maybe PIC24. Sadly it's just not a big enough market to get the love it really deserves.

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

Ah-ha.   The tiny817, tiny1617, tiny3217 are available but only in QFN.    I don't mind hand-soldering a TQFP but am not brave enough for QFN.

 

At least the Xmega and Mega4809 are available in TQFP.

 

It is unfortunate that Arduino never produced an Xmega board.   That would have given a wide user base to some VERY capable chips.

 

David.

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

david.prentice wrote:
It is unfortunate that Arduino never produced an Xmega board. 
I thought it was announced that the next Arduino would use a 4809? Does that count?

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

XMEGA would be great for an Arduino style board. For example the multiple identical peripherals that can be addressed via pointers would be ideal for that kind of thing, and also suit ARM as well.

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

clawson wrote:

david.prentice wrote:
It is unfortunate that Arduino never produced an Xmega board. 
I thought it was announced that the next Arduino would use a 4809? Does that count?

 

- high frequency crystal oscillator missing

- PLL missing

- 32MHz speed missing

- USB missing (FTDI chip would not be needed, Nano, Mini variant would go even cheaper, higher transfer rate with a PC)

 

One of the reason I think is for the amount of work needed to add it to their IDE. See, it takes a long time to add the Mega4809.

A third party added the Mega328PB to one of their boards, but I don't see much talk about. If the board is not doable by the Chinese, I don't think it will go too far.

 

Edit:

However, Mega0 beats any other AVR in terms of price / RAM (4 - 8K) or price / FLASH (32 - 64k)

Last Edited: Tue. Oct 23, 2018 - 05:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely anyone with a will and a bit of a time on their hands could make up a "core" for any CPU architecture? So if there's enough interest to make any form of Xmega "Arduino" it could presumably be done fairly easy. (Xmega is almost bound to be a superset of Uno so can at least implement everything that offers).

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

david.prentice wrote:

It is unfortunate that Arduino never produced an Xmega board.   That would have given a wide user base to some VERY capable chips.

 

I think what really stopped that dead, was the unfortunate detail that XMEGA is a 3v3 Part.

Mega4809 is a wide Vcc part, so they can and do use that.

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

angelu wrote:

- high frequency crystal oscillator missing

- PLL missing

- 32MHz speed missing

- USB missing (FTDI chip would not be needed, Nano, Mini variant would go even cheaper, higher transfer rate with a PC)

 

USB may come, who knows ?

32MHz missing I think is result of wider Vcc process (plus 32MHz Xtal Osc is not so easy, making a PLL more mandatory)

PLL missing is likely a price decision, and partly due to flawed 'RC Osc is good enough' thinking. 

 

Remove of HF Xtal Osc is a rather larger mistake, as there are growing numbers of Oscillators now in Clipped Sine out. Lower Power and lower RFI are compelling advantages.

 Likely some product manager only saw that 'most users can tolerate RC specs', and did not see trends outside MCUs

 

I can't believe HF Xtal Osc has any significant die impact, but maybe it adds a few milliseconds of testing time ?

 

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

Who-me wrote:
I can't believe HF Xtal Osc has any significant die impact, but maybe it adds a few milliseconds of testing time ?

 

I don't get it either, it's just an inverter, and in fact the xtinies can invert every I/O pin, so they have plenty of inverters already. If you remember, a while back I made a crystal driver using the circuitry already available:

https://www.avrfreaks.net/forum/...

 

Of course, no one would use something like that in actual production, but the point is, why don't the chips have a proper crystal driver inside?

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

 

    From Mega0 datasheet:

    If you look at this graph, changing OSCCAL one count the frequency changes about 0.5%, or in other words, the resolution that you can achieve is a bit less than 8bits. Now, if a crystal oscillator has an accuracy of 50ppm, it means a resolution of a bit more than 16bits. A DFLL would come handy providing it could adjust the internal RC with a finer granularity. So if you want to measure some frequency, some RPM, or an accurate timing you can't. Or you need an external clock. If it happen that you have on the PCB some sensor of radio module that could provide you with a clock, you need to set the fuse accordingly. And you can't put that sensor / module to sleep because you may lose the clock, because you can't change the clock from software. And you can't run the micro from RC until you manage to configure that external clok and then switch to the external one. Some application will require the old and good Mega328. So much RAM and FLASH in this new toy and it fails basic features.

 

    In conclusion I add to my above list:

- DFLL missing

- clock selection via software missing

     Be happy

Last Edited: Wed. Oct 24, 2018 - 02:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great explanation here for someone like me, who is floating in the embedded ocean of darkness lol , Hands down ^^

work in progress...

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

angelu wrote:

In conclusion I add to my above list:

- clock selection via software missing

 

Are you sure about that last one? The mega0 manual says...

 

Quote:

9.3.2 Main Clock Selection and Prescaler

All internal oscillators can be used as the main clock source for CLK_MAIN. The main clock source is selectable from software, and can be safely changed during normal operation.

Built-in hardware protection prevents unsafe clock switching: Upon selection of an external clock source, a switch to the chosen clock source will only occur if edges are detected, indicating it is stable. Until a sufficient number of clock edges are detected, the switch will not occur and it will not be possible to change to another clock source again without executing a Reset.

 

#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

Brian Fairchild wrote:

angelu wrote:

In conclusion I add to my above list:

- clock selection via software missing

Are you sure about that last one? The mega0 manual says...

Quote:

9.3.2 Main Clock Selection and Prescaler

All internal oscillators can be used as the main clock source for CLK_MAIN. The main clock source is selectable from software, and can be safely changed during normal operation.

Built-in hardware protection prevents unsafe clock switching: Upon selection of an external clock source, a switch to the chosen clock source will only occur if edges are detected, indicating it is stable. Until a sufficient number of clock edges are detected, the switch will not occur and it will not be possible to change to another clock source again without executing a Reset.

 

Yes, I am sure I got it wrong. Edited my previous post.

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

Device packaging of the following XMEGA is moving from Korea to China ETA approximate Jun'19 :

  • XMEGA128B3 in VQFN (7x7x1mm body)

https://www.microchip.com/mymicrochip/NotificationDetails.aspx?pcn=LIAL-10SSYM861

 

Microchip Thailand will be an additional device packaging site for the following XMEGA in QFP-100 on 19-Jan'19 :

  • XMEGA128A1
  • XMEGA128A1U
  • XMEGA128B1
  • XMEGA64A1
  • XMEGA64A1U
  • XMEGA64B1

https://www.microchip.com/mymicrochip/NotificationDetails.aspx?pcn=GBNG-05QUVX037

 


https://www.microchip.com/mymicrochip/Reports.aspx?type=cpn&filter=ATXMEGA

 

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

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

Would be great if they could add USB to some of the Xtiny or the E range. Especially if it supported USB host... I can dream.

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

I'm pretty much a NooB when it comes to Xmega's.

I have not used them and I won't use them.

 

I'm sure they are quite capable processors, but I think they are trying to fill too small a niche.

From what I researched the Xmega's are quite comparable to the smaller ARM chips (of whatever vendor).

It seems that anything you can do with an Xmega, you can almost always do just as well with an ARM.

The other way around is not true. With ARM you can grow to 400MHz or more, Mega Bytes of Flash / RAM and hundreds of pins.

When an Xmega project grows out of it's seems you have to port it. That would be a lot easier if you started with ARM in the first place.

Is there a significant price difference between Xmega's and small ARM's?

There is also a consideration for the amount (& quality) of example code, libraries & projects.

I'm pretty sure ARM will win here also, but as almost all uC code is written in C / C++ nowadays, porting such a library from one uC family to another is doable, and if it is written well, sometimes even almost trivial.

 

I like the AVR's for small projects and 5V compatibility, but how big is the gap between 8-bit AVR and 32 bit ARM?

 

I think the world woud be better of if half ( 3/4 ?) of the uC families just went away.

Let the engineers focus on less silly details for obscure microcontroller families and make better portable and quality libraries for the remaining families.

This is not in the interest of uC vendors though. They want a fragmented market to sell lots of different small "special" uC's.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

Paulvdh wrote:
It seems that anything you can do with an Xmega, you can almost always do just as well with an ARM.

 

ARM is has some very significant differences. One of the main ones being that it's much slower and less predictable for interrupt latency.

 

ARM isn't as good for low power either. Sure, ARM devices have nice sleep modes, but when you actually need to run at low power... Also the ARM sleep modes tend to suck, e.g. most of the RAM contents is lost and a bunch of stuff gets reset, so your wake-up times are horrendous.

 

From a programming point of view ARM vendors seem very keen for you to use their usually quite crappy libraries too. Setting up the thing by yourself is often tricky and poorly documented.

 

On the other hand if you need very low cost, loads of memory and peripherals, or an RTOS then ARM is a good option. But 8 bit will be around for a long time yet, because ARM is something quite different really.

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

Paulvdh wrote:
I think the world woud be better of if half ( 3/4 ?) of the uC families just went away.
Monoculture seems like a good idea until a blight comes along.  Ask the Irish.

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Microchip Thailand will be an additional device packaging site for the following XMEGA in QFP-100 on 19-Jan'19 :

The scope of that PCN has increased to add more XMEGA in QFP-64.

Product Change Notification - GBNG-05QUVX037 - 04 Mar 2019 - CCB 3496 and 3496.001 Final Notice: Qualification of MMT as an additional assembly site for selected Atmel products of the 35.4K, 35.5K and 35.9K wafer technologies available in 64L TQFP (14x14x1.0mm) and 100L TQFP (14x14x1.0mm) packages.

...

04 Mar 2019

...

 

Affected CPNs :

[XMEGA begin near the top of page 5 though the end of that document on page 7]

https://www.microchip.com/mymicrochip/NotificationDetails.aspx?id=12316&affectedcpns=pdf

 

...

 

Estimated First Ship Date:
For 100L TQFP package: January 19, 2019 (date code: 1903)
For 64L TQFP package: March 30, 2019 (date code: 1913)

 

...

 

Revision History:
...

March 4, 2019: Re-issued final notification to update the subject and description because of the update in scope to include 64L TQFP package. Updated the affected CPN list in accordance with the update to the scope. Updated the pre and post change summary table MSL classification for MMT site from MSL 1 and 2 to MSL 3. Updated the pre and post change to add ANAP assembly site which is applicable for 64L TQFP package.

 

...

 


https://www.microchip.com/mymicrochip/Reports.aspx?type=cpn&filter=ATXMEGA

 

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

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

Microchip Packs Repository - Microchip XMEGAB

...

2.0.2 (2019-01-24)

Corrected fuse names. Succeeds Atmel.XMEGAB_DFP 1.1.55.

 

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

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

107 XMEGA in QFP will be moving from MSL 3 trays to MSL 1 trays.

QFP may be mostly MSL 3.

iow, remove an XMEGA from a blue tray (75C max), bake it if necessary, then place it onto a solder-pasted PCB.

 

Product Change Notification - KSRA-23LPHB699 - 02 Aug 2019 - CCB 3845 and 3845.001 Final Notice: Implement new packing material (non-bakeable tray) for selected products available in 100L and 64L TQFP (14x14x1mm) packages at MMT assembly site

...

 

Estimated First Ship Date: 
September 02, 2019 (date code: 1936)

 

...

MMT - Microchip Technology Thailand

IPC/JEDEC Moisture Sensitivity Levels

 

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

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

Assembly of XMEGA128B3 in VQFN (7*7*1mm, 0.65mm pitch) is moving from South Korea to China.

Product Change Notification - LIAL-10SSYM861 - 18 Oct 2019 - CCB 3631 Final Notice: Qualification of ASSH as a new assembly site for selected Atmel ATXMEGA products available in 64L VQFN (7x7x1mm) package.

...

 

Affected CPNs:

https://www.microchip.com/mymicrochip/NotificationDetails.aspx?id=13307&affectedcpns=pdf

 

...

 

Estimated First Ship Date:
November 18, 2019 (date code: 1947)

 

...

 

Revision History:
December 19, 2018: Issued initial notification.
October 18, 2019: Issued final notification. Attached the Qualification Report. Provided estimated first ship date to be on November 18, 2019.

 

...

ATxmega128B3 - 8-bit AVR Microcontrollers

 

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

Pages