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.
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
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.
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).
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".
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...)
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.
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
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.
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.
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.
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.
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.
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)
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).
- 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 ?
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:
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.
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
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.
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.
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.
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.
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.
- Log in or register to post comments
Top
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
- Log in or register to post comments
TopClarifications and several data updates except for XMEGA A1U ordering :
http://www.microchip.com/mymicrochip/Reports.aspx
Edit : PCN URL
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopWould be nice to see some of the PIC24 features added to XMEGA. 1 meg flash memory and 96k RAM sounds nice.
- Log in or register to post comments
Top- Log in or register to post comments
Top- Log in or register to post comments
TopThe 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...)
- Log in or register to post comments
TopThat'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
AtmelMicrochip.- Log in or register to post comments
TopAn application note was updated last month :
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Topi think you should'nt consider Xmega as hobby !
it's not !!
but unfortunately yes it's not popular.
- Log in or register to post comments
TopYesterday 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.
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopAll 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.
- Log in or register to post comments
Top- Log in or register to post comments
TopArduino 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.
- Log in or register to post comments
TopBut Xtiny are not available anywhere, any good links for info ?
- Log in or register to post comments
Tophttps://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.
- Log in or register to post comments
TopUnfortunately 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.
- Log in or register to post comments
TopAh-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.
- Log in or register to post comments
Top- Log in or register to post comments
TopXMEGA 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.
- Log in or register to post comments
Top- 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)
- Log in or register to post comments
TopSurely 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).
- Log in or register to post comments
TopI 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.
- Log in or register to post comments
TopUSB 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 ?
- Log in or register to post comments
TopI 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?
- Log in or register to post comments
TopFrom 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:
Be happy
- Log in or register to post comments
TopGreat explanation here for someone like me, who is floating in the embedded ocean of darkness lol , Hands down ^^
work in progress...
- Log in or register to post comments
TopAre you sure about that last one? The mega0 manual says...
#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
- Log in or register to post comments
TopYes, I am sure I got it wrong. Edited my previous post.
- Log in or register to post comments
TopDevice packaging of the following XMEGA is moving from Korea to China ETA approximate Jun'19 :
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 :
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
- Log in or register to post comments
TopWould 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.
- Log in or register to post comments
TopI'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
- Log in or register to post comments
TopARM 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.
- Log in or register to post comments
Top"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]
- Log in or register to post comments
TopThe scope of that PCN has increased to add more XMEGA in QFP-64.
https://www.microchip.com/mymicrochip/Reports.aspx?type=cpn&filter=ATXMEGA
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Top107 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.
MMT - Microchip Technology Thailand
IPC/JEDEC Moisture Sensitivity Levels
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopPages