XMEGA Family is Losing in the Popularity Polls

Go To Last Post
112 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I was surfing around www.microchip.com looking for some application notes and I happened to click on the Parametric Search link.  The heading of the page suggests that only "New/Popular" devices are shown:

 

 

When I went to select a device in the XMEGA-C series, I couldn't find one in the "Product" column.  In fact, there are only two XMEGAs listed: the ATxmega16A4U and ATxmega32D4.  And because neither of these is "new" one is left to conclude they are the only two "popular[1]" XMEGA devices.  There aren't all that many MEGA and TINY devices either, but lots and lots of SAMs and, of course, lots of PICs.  I knew this was coming I guess, but didn't expect it so soon.

 

I am considering starting a a campaign to save the XMEGA here in The States.  Maybe I'll use "Make XMEGA Great Again!" for a campaign slogan..?

 

 

[1] Where "popular" means "Microchip would prefer you purchase these ones."

 

* Tightened up the thread title. Ross *

 

 

 

This topic has a solution.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

Last Edited: Wed. Feb 21, 2018 - 04:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you think Atmel got a bad deal??

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

Greg_Muth wrote:
[1] Where "popular" means "Microchip would prefer you purchase these ones."
I think the Parametric Search page is in dire need of a revamp and is surely a work in progress especially with regard to Atmel offerings.  Interesting though, all the new ATtinys (xtinys) are listed in that search.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

Greg_Muth wrote:
... there are only two XMEGAs listed: ...
That issue appeared 29-Jan :

https://www.avrfreaks.net/forum/future-xmega?page=3#comment-2382636

 

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

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

@Kartman wrote:

Do you think Atmel got a bad deal??

I've never looked at it in business terms, so I couldn't say. 

 

 

@larryvc wrote:

I think the Parametric Search page is in dire need of a revamp and is surely a work in progress especially with regard to Atmel offerings.

My thought as well until I saw all those SAMs.  They didn't waste any time getting those in there!

 

@gchapman,

 

blush  That's embarrassing   blush

 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

I think SAM is what they really wanted. The other stuff is much less interesting to them because they already have their own 8/16 bit lines and I'm sure will be putting all their resources into developing those rather than XMEGA.

 

It's a real shame because XMEGA is the nicest 8 bit architecture going at the moment. It surpasses the 16 bit PIC24 in most cases too.

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

Their concentration right now (8  bit AVR) seems to be "XTiny" in fact so Xmega may not be "Unpopular". It's just headed "down spec" a bit.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 3

I don't know if people are aware but Microchip have two parametric search tools on the website. I use this one as it's a bit more 'engineering' and a bit less 'marketing'...

 

https://www.microchip.com/maps/m...

#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. You can kinda select on XMEGA if you choose PDI as the debug interface, although the XTiny parts are included too.

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

mojo-chan wrote:

I think SAM is what they really wanted. The other stuff is much less interesting to them because they already have their own 8/16 bit lines and I'm sure will be putting all their resources into developing those rather than XMEGA.

 

It's a real shame because XMEGA is the nicest 8 bit architecture going at the moment. It surpasses the 16 bit PIC24 in most cases too.

Who knows, maybe they are a little bit embarrassed about their PICs and want to push the AVR instead...

My feeling about their feeling about the Xmega is that it's too good for an 8bitter. So being said, let's improve the tiny/mega line towards the xmega quality, but not too far. For better devices we have SAM lines and PIC32s.

 

 

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

rammon wrote:

Who knows, maybe they are a little bit embarrassed about their PICs and want to push the AVR instead...

 

Let's not even go there. The current PIC line-up is as good as the current AVR line-up and in some areas, especially interesting peripherals, better.

#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

The PIC architecture isn't as good as XMEGA though. The 8 bit stuff is just a horrible mess, with random bits scattered over random registers that have been added to over the decades. The 16 bit stuff is better but still not as nice as XMEGA.

 

Where XMEGA really shines though is in stuff like PDI and quality debuggers, which are infinitely better than what is available for PIC. You also get a free high quality compiler instead of them being dicks about charging you for their GCC hack.

 

I think rammon is right, Microchip's goal is to make all the Atmel stuff suck as much as their PIC stuff. Jack up the prices, slow down development and push them off to some obscure corner of the web site.

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

mojo-chan wrote:
I think SAM is what they really wanted.

I would agree - they really stuck out as the "sore thumb" with no ARM offerings.

 

The other stuff is much less interesting to them because they already have their own 8/16 bit lines

and their own proprietary 32-bit lines 

 

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

I've heard that their 32 bit MIPS stuff is good, but never tried it. I suppose the problem is that people want to learn ARM because that's a really good skill to have and doesn't tie you to one manufacturer. PIC32 is a bit niche.

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

rammon wrote:
maybe they are a little bit embarrassed about their PICs

Back in the day, the PIC used to be the go-to chip for hobbyist projects.

 

When there were electronics magazines, their microcontroller projects always seemed to be PIC.

 

When some "hobbyist" or garage tinkerer (before the terms "hacker" and "maker" were used in this context) thought he had an idea for a Better Mousetrap, it always seemed to start with a PIC.

 

But then along came Arduino...

 

 

I suspect Microchip wanted to get back in that game.

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

mojo-chan wrote:
I suppose the problem is that people want to learn ARM because that's a really good skill to have and doesn't tie you to one manufacturer.

Exactly.

 

And there's the whole "ecosystem" behind it.

 

PIC32 is a bit niche.

Like AVR32

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

awneil wrote:

rammon wrote:
maybe they are a little bit embarrassed about their PICs

Back in the day, the PIC used to be the go-to chip for hobbyist projects.

 

When there were electronics magazines, their microcontroller projects always seemed to be PIC.

 

When some "hobbyist" or garage tinkerer (before the terms "hacker" and "maker" were used in this context) thought he had an idea for a Better Mousetrap, it always seemed to start with a PIC.

 

But then along came Arduino...

 

 

I suspect Microchip wanted to get back in that game.

 

I come from a Z80/8051 world ('94-'95). In my circles the poor PICs were regarded as a weird brain damaged chips.

I started with AVR in '98. We needed badly at that time a simpler and smaller replacement for our big 80C552+EPROM+SRAM board (80C552 for its internal ADC).

My boss were talking at that time with a person from Cygnal (now Silabs) but they turned out to be just late at the party.

We started with an AT90S4434, soon replaced by an AT90S8535 finally replaced by an ATmega8535 yes

 

 

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

@Brian Fairchild wrote:

I use this one as it's a bit more 'engineering' and a bit less 'marketing'...

Nice find!  I've bookmarked that one for future use.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

IMO, the Xmega was a bit too little and too late.  It has all the disadvantages of an ARM or MIPS 32bit cpu (complex peripherals, 3V power, unfriendly packages) but lacks the advantages (multi-vendor core, linear address space, Really Fast Clock, Lots of memory.)hh

 

 

Back in the day, the PIC used to be the go-to chip for hobbyist projects.

 It was the chip you could actually BUY.  While the early Flash AVRs theoretically released before the Flash PICs,  Parallax (and others) were selling 16C84s, Windowed EPROM chips, and OTP PICs to hobbyists long before you could get your hands on Atmel chips.

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

westfw wrote:

 

Back in the day, the PIC used to be the go-to chip for hobbyist projects.

 It was the chip you could actually BUY.  While the early Flash AVRs theoretically released before the Flash PICs,  Parallax (and others) were selling 16C84s, Windowed EPROM chips, and OTP PICs to hobbyists long before you could get your hands on Atmel chips.

Before flash AVRs there were flash 8051 also by Atmel. I've used them extensively in '96-'97 (AVR is supposed to be born in '97 but I could only buy chips in '98). The famous 89C2051/89C51/89C52. Waaaay better than the poor 16F84. I just couldn't understand at that time why people wanted to use 16F84 when the 89C2051 (for example, for the low pin count variant) was available with no problem.

Well, I'm not speaking about hobbyist. I've always been a professional. But, professionally speaking, we got intern students at that time that wanted to use the 16F84 for projects like networked smart card readers (RS485, quite a complex protocol, the smart card port, a little user interface of some buttons and some leds, two relays, two inputs... with a single 8bit timer, really? And 75bytes of ram and only 2 return stack levels? - I don't rember the flash size but it was quite little). The device was done with an 89C52 which was about full with its 8K flash and 256bytes ram.

 

 

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

Not sure what the popularity bit is all about. Face it, XMega has never won a popularity contest in its whole life, and never will. Outstanding chip? YES! Popular? Nope!

 

Jim

 

 

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

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

I want to like XMega. Some of its peripherals are complex compared to other AVRs but they're actually extremely well designed (maybe not so much the ADC!). The clocking options, DMA controller, IO port flexibility, USB controller, etc, can all hold their own against 32-bit platforms. The problem is twofold; lack of SRAM and cost.

 

My wAVR product was breadboarded using an Xmega256A3U. It was clear early on that 16KB SRAM wasn't going to cut it. The SAM CPU I settled on is way faster, has 64KB SRAM and the same size Flash. It's less than half the price of the XMega and in a smaller package. No brainer.

 

XMega is trying to fill a niche which is already well catered for by ARM, even if ARM's peripherals are sometimes inferior.

 

Steve

 

Maverick Embedded Technologies Ltd. Home of wAVR and Maven.

wAVR: WiFi AVR ISP/PDI/uPDI Programmer.

Maven: WiFi ARM Cortex-M Debugger/Programmer

https://www.maverick-embedded.co...

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

I've used [Atmel] extensively in '96-'97 (AVR is supposed to be born in '97 but I could only buy chips in '98). ... Well, I'm not speaking about hobbyist. I've always been a professional.

Looking at the eMail archive, I found a message from myself, being pleasantly surprised that "BG Micro" (a hobbyist mail-order dealer) had added  AT90S2313, AT89C2051, and AT89C52 to their price list.  In late 2000.    (Hmm.  Memory lane.  The first mention I see of AVRs is mid 1997.  First mention of 89C2051 was 96.  Meanwhile, I can also find messages about the PC parallel port programmers you could build to program a PIC16C84, dating back to 1994 ("The PIC FAQ".)   Heh.  Microchip had a BBS whose contents were accessible via the Compuserve network; it's contents were duplicated across the fledgling "Internet.")

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

westfw wrote:

IMO, the Xmega was a bit too little and too late.  It has all the disadvantages of an ARM or MIPS 32bit cpu (complex peripherals, 3V power, unfriendly packages) but lacks the advantages (multi-vendor core, linear address space, Really Fast Clock, Lots of memory.)hh

 

The XMEGA peripherals aren't complex at all, in fact they are some of the easiest to use available IMHO. The peripherals are one of the best things about XMEGA.

 

Okay they don't do DIP, but the TQFP packages are easy enough to hand solder. Is that what you mean by unfriendly?

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

mojo-chan wrote:
The XMEGA peripherals aren't complex at all

That doesn't seem to be Jim's experience in his current first venture into XMega land ...

 

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

 

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

 

 

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

scdoubleu wrote:
ARM's (sic) peripherals

ARM just do the CPU core - not the peripherals.

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:

scdoubleu wrote:
ARM's (sic) peripherals

ARM just do the CPU core - not the peripherals.

 

Don't remember exactly what specific chips but the datasheets/user manuals specified what IP code exactly was implemented.

DMA is usually arm, but I'm sure I saw a SPI also, at least.

 

Here are some ARM peripherals:

 

Peripheral controllers

Arm System IP also supports various general-purpose peripheral controllers. These products augment the standard IP solutions for customers adopting Arm in various systems. The following is a list of peripheral controllers available: 

  • PL011 is a synthesizable Universal Asynchronous Receiver Transmitter (UART) serial port controller.

    Click to view the PL011 TRM.

  • PL022 is a synthesizable Single-wire Peripheral Interface (SPI) controller, master and slave.  The PL022 supports Motorola SPI, TI SSI, and Microwire.

    Click to view the PL022 TRM.

  • PL061 is a synthesizable General Purpose Input-Output (GPIO) controller.  The PL061 supports 8 bits with interrupt control.

    Click to view the PL061 TRM.

  • PL080 is a synthesizable DMA controller supporting one AHB master interface and eight DMA channels.

    Click to view the PL080 TRM.

  • PL081 is a synthesizable DMA controller supporting one AHB master interface and two DMA channels.

    Click to view the PL081 TRM.

  • PL111 is a synthesizable color LCD controller supporting an AHB master and slave interface and driving TFT and STN, single and dual panel displays.

    Click to view the PL111 TRM.

 

 

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

awneil wrote:

scdoubleu wrote:
ARM's (sic) peripherals

ARM just do the CPU core - not the peripherals.

Well yes, to be pedantic :)

 

What I meant of course was the range of peripherals on SoCs with an ARM core.

 

Steve

Maverick Embedded Technologies Ltd. Home of wAVR and Maven.

wAVR: WiFi AVR ISP/PDI/uPDI Programmer.

Maven: WiFi ARM Cortex-M Debugger/Programmer

https://www.maverick-embedded.co...

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

awneil wrote:

mojo-chan wrote:

The XMEGA peripherals aren't complex at all

 

That doesn't seem to be Jim's experience in his current first venture into XMega land ...

 

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

 

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

 

Meaningless. How can you compare it to any other part? XMEGA is less popular, especially with hobbyists. The MEGA/Tiny and PIC forums are full of noobs trying to get their Arduino knock-offs to work. We can't conclude anything from this.

 

Maybe it's just me but I find the XMEGA peripherals quite logical and straight forward. The manuals are good too.

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

Are you calling Jim a noob ... ?

 

surprise

 

 

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

I never used the xmegas, they seem to have good peripherals, but these are similar to the ones on SAM ARM MCUs. So there seems to be little point in using the xmegas instead or ARM, which are much more powerful computationally and cheaper.

I'm not saying there are no reasons to use xmega, people that do must have them. It's just that I can't find these reasons, never having used xmegas.

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

El Tangas wrote:
I never used the xmegas

neither have I

 

there seems to be little point in using the xmegas instead or ARM, which are much more powerful computationally and cheaper.

and see #16

 

I'm not saying there are no reasons to use xmega, people that do must have them.

Often, 8-bitters can win on power consumption ...

 

 

 

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:

Often, 8-bitters can win on power consumption ...

Well, that may be less often these days. I saw 90uA/MHz cortex-m devices which is quite impressive. The best I know is 45uA/MHz for RL78 devices (well, not 32bit, but not 8bit either... kind of 16bit).

For AVR devices all I got is some figures at 1MHz, 1.8V. Sorry, I want 3V or 3V3. Least, 2V7.

Found some PICs with 150uA/MHz or 180uA/MHz. Not competitive with 32bit cortex-m devices (which most of them are in the same ballpark).

 

These days I use 8bitters for:

- simplicity,

- low cost,

- 5V

on applications that they CAN do it of course.

 

5V is no longer for 8bit devices only, there are Kinetis E devices now and SAM C20/C21. I'm using Kinetis E in some applications (sorry, they were first on the market), but I still have a lot of applications with atmega at 5V, old or new. I've just done recently three boards design with atmega88pb. Just no need for a kinetis E in those boards, not to say that the mega88pb was half the price of the cheapest kinetis E (which are usually cheaper than SAM C20/C21).

 

 

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

rammon wrote:

These days I use 8bitters for:

- simplicity,

- low cost,

- 5V

on applications that they CAN do it of course.

 

 

Same here. But I have one additional reason which is not rational. I feel pity for an ARM doing a job that an 8 bit chip could docheeky

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

rammon wrote:
The best I know is 45uA/MHz for RL78 devices (well, not 32bit, but not 8bit either... kind of 16bit).

Ambiq Micro

Ambiq Micro

Apollo2 MCU

http://ambiqmicro.com/apollo-ultra-low-power-mcus/apollo2-mcu/

...

[arm Cortex-M4F]

...

  • <10 μA/MHz executing from flash at 3.3 V

...

due to

https://www.avrfreaks.net/forum/future-xmega#comment-1785471 by joeymorin

...

30µA/MHz.  Holy smokes.

...

in

Future of XMEGA

by mojo-chan

https://www.avrfreaks.net/forum/future-xmega

 

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

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

gchapman wrote:
Ambiq Micro 

Apollo2 MCU 

I've seen them mentioned before; their "secret sauce" is the patented "Subthreshold Power Optimized Technology (SPOTTM) Platform"

 

But where can you get the actual chips ... ?

 

EDIT

 

Aha - some distributors listed here: http://ambiqmicro.com/contact-us/ - including Digikey

 

 

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...
Last Edited: Thu. Feb 22, 2018 - 02:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

awneil wrote:

Are you calling Jim a noob ... ?

 

No, but I know why he is having trouble. Atmel START for XMEGA is half baked to say the least. He wants to treat XMEGA like ARM, where everything is done with a nice framework and you rarely hit the registers directly... XMEGA isn't like that, the Atmel libraries are junk, but it isn't hard to just read the datasheet and write your own code.

 

There is an increasing divide in the "embedded" world. You have the real no-OS 8 bit hardcore embedded stuff. Then you have embedded ARM systems running Linux or Windows or Android. And then in the middle you have ARM microcontrollers that the manufacturers really really want you to use their libraries to operate for some reason.

 

I'm not a fan of library code. Sometimes it makes sense, but often it's buggy and slow. The ASF/START is one of the worse examples, being bloated, badly documented and fiddly to use because it tries to present the same API on vastly different platforms. I'd suggest just looking up the relevant AVR* document and debugging their example code if the datasheet isn't obvious.

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

mojo-chan wrote:

No, but I know why he is having trouble. Atmel START for XMEGA is half baked to say the least. He wants to treat XMEGA like ARM, where everything is done with a nice framework and you rarely hit the registers directly... XMEGA isn't like that, the Atmel libraries are junk, but it isn't hard to just read the datasheet and write your own code.

 

There is an increasing divide in the "embedded" world. You have the real no-OS 8 bit hardcore embedded stuff. Then you have embedded ARM systems running Linux or Windows or Android. And then in the middle you have ARM microcontrollers that the manufacturers really really want you to use their libraries to operate for some reason.

 

I'm not a fan of library code. Sometimes it makes sense, but often it's buggy and slow. The ASF/START is one of the worse examples, being bloated, badly documented and fiddly to use because it tries to present the same API on vastly different platforms. I'd suggest just looking up the relevant AVR* document and debugging their example code if the datasheet isn't obvious.

 

STM32 libraries are the same.

Silabs libraries are the same (I don't know about EFM32, they bought it, but their's own SIM3xxx).

Same bloat everywhere.

 

So I don't know about your first sentence: "... like ARM, where everything is done with a nice framework and you rarely hit the registers directly..."

I hit the registers directly everytime. Because there's no thing like a "nice framework".

32bit ARM Cortex-M chips are hard to deal with only when you try to use the vendors libraries. When not, you'd be surprised how easy the things can be, if you pay attention to the user manual.

 

Only once I used a library, an usb library for some LPC device. I needed a composite dual CDC device. That was a big fail eventually, it kinda worked, with some problems (from time to time there was a big pause in the communication, about 0.5 seconds, which was just unacceptable) and I needed to redo the system with an external dual port usb-uart chip (CP2105).

 

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

Ambiq, of course. I forgot about it.

Didn't know in fact they came with real chips indecision

 

Don't know what to say, or how to say it... seems not very practical for every day projects...

 

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

mojo-chan wrote:

No, but I know why he is having trouble. Atmel START for XMEGA is half baked to say the least. He wants to treat XMEGA like ARM, where everything is done with a nice framework and you rarely hit the registers directly... XMEGA isn't like that, the Atmel libraries are junk, but it isn't hard to just read the datasheet and write your own code.

Re; the half baked part, I find that the ones that don't appreciate, understand, or use Start, are the ones that complain about it the most, they just don't know where to look to see what code was produced and what it has done to configure the chip, and IMO they give up too easily.  Oh, BTW Start is a "nice framework", I have had no problem using it for the XMEGA Projects I have done, USART and timer routines worked fine.  Mind you, and I have said this before, I use Start to get things up quickly, then I pull out the stuff I need and optimize the code to make it lean and mean.

 

The comment that Atmel libraries are junk, yeah they often contain a lot of cruft, unnecessary jumps to empty setup routines, etc., but I would not say they are junk.  They are what every manufacturer is providing though and this trend is not going away any time soon.

 

See my "flavor of the year" comment here​.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Fri. Feb 23, 2018 - 06:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rammon wrote:
Who knows, maybe they are a little bit embarrassed about their PICs and want to push the AVR instead...
Instead, it's complement.

There's been new product announcements for both halves of the 8-bit MCU house.

rammon wrote:
So being said, let's improve the tiny/mega line towards the xmega quality, ...
Quality of both is being improved though there's more actions on tinyAVR and megaAVR than XMEGA AVR.

XMEGA AVR at Microchip :

  • XMEGA A1U in BGA - additional assembly site
  • XMEGA E - Microchip Technology Thailand (MTAI) as an additional assembly site

 

After quality is availability.

XMEGA AVR at microchipDIRECT programming (a volume indication?)

  • XMEGA128A3U
  • XMEGA256A3BU
  • XMEGA128A4U
  • XMEGA32A4
  • XMEGA E5

rammon wrote:
... but not too far.
No ... Anyone for AVR16? wink

 


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

http://www.microchipdirect.com/AVR-SAM-Programming.html

 

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

Last Edited: Thu. Feb 22, 2018 - 05:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larryvc wrote:
I find that the ones that don't appreciate, understand, or use Start, are the ones that complain about it the most,

I've never used Start, but I would agree with that comment regarding ASF ...

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

gchapman wrote:

rammon wrote:
Who knows, maybe they are a little bit embarrassed about their PICs and want to push the AVR instead...
Instead, it's complement.

There's been new product announcements for both halves of the 8-bit MCU house.

I know. It was kind of joke.

 

gchapman wrote:

rammon wrote:
So being said, let's improve the tiny/mega line towards the xmega quality, ...
Quality of both is being improved though there's more actions on tinyAVR and megaAVR than XMEGA AVR.

XMEGA AVR at Microchip :

  • XMEGA A1U in BGA - additional assembly site
  • XMEGA E - Microchip Technology Thailand (MTAI) as an additional assembly site

 

After quality is availability.

XMEGA AVR at microchipDIRECT programming (a volume indication?)

  • XMEGA128A3U
  • XMEGA256A3BU
  • XMEGA128A4U
  • XMEGA32A4
  • XMEGA E5

I see design activity in the tiny/mega family, none in the xmega. Design activity: new chips, with new features, new peripherals, etc. Even in the core (that second interrupt priority)!

Maybe the xmega is the best you can do around an avr core smiley.

 

And when I said quality I was thinking of the quality of the design of the chip/family, not the quality of the fabrication process. Maybe the quality is not the right word about the design of the chip/family, I don't know which is the right word.

 

rammon wrote:
... but not too far.
No ... Anyone for AVR16? wink

 

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

http://www.microchipdirect.com/AVR-SAM-Programming.html

 

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

larryvc wrote:
They are what every manufacturer is providing though and this trend is not going away any time soon.
and third parties (frameworks, RTOS)

 

Simba Embedded Programming Platform.

https://github.com/eerimoq/simba

via https://platformio.org/platforms/atmelsam

svd2ada

An Ada binding generator from SVD descriptions for bare board ARM devices.

https://github.com/AdaCore/svd2ada

https://github.com/AdaCore/Ada_Drivers_Library#1-introduction

This repository contains Ada source code and complete sample GNAT projects for selected bare-board platforms supported by GNAT. Initially the repository contains software for ARM platforms from a specific vendor, but we intend this to be a location for both AdaCore and the community in general to contribute support for additional processors, platforms, and vendors.

 

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

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

@mojo-chan wrote:

The peripherals are one of the best things about XMEGA.

+1  yes.  The first AVR I programmed was an XMEGA.  Intelligently laid-out registers, giving the ability to define peripherals as structs whose addresses could be passed as pointers to functions, and header files that provided meaningful names to bitfields (e.g. "ADC_CH_GAIN_16X_gc, DMA_CH_TRIGSRC_USARTC0_RXC_gc").  When I stepped downward/backward to the MEGA1284P, I was sadly disappointed.

 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

@ka7ehk wrote:

Not sure what the popularity bit is all about.

 

Jim, the "popular" comes from the page title:

 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

Didn't realise I was mentioned here so often, so I feel the need to clear a few things up....

 

awneil wrote:

mojo-chan wrote:
The XMEGA peripherals aren't complex at all

That doesn't seem to be Jim's experience in his current first venture into XMega land ...

 

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

 

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

 

 

 

From reading the datasheets and the manual, the peripherals are only a little more complicated than the AVR...the clock stuff is certainly more complicated.  I am not going near the event or DMA stuff yet as I am still trying to get teh USARTC0 going, but I am keeping that in the other threads...not here.

 

mojo-chan wrote:
Meaningless. How can you compare it to any other part? XMEGA is less popular, especially with hobbyists. The MEGA/Tiny and PIC forums are full of noobs trying to get their Arduino knock-offs to work. We can't conclude anything from this.

I will ALWAYS be a hobbyist as long as I am experimenting with new things that I do not get paid for.  But I do/(used to) make a living in electronics and embedded designs.  We can certainly can extract some conclusions from the hobbyist/noobs in the Mega/Tiny/Arduino forums because people buy/use things based on the experience.  If the experience sucks, then the interest/sales will suffer accordingly.  The forums are also full of experienced professionals that also trying to get their designs to work as well and are asking for assistance, or a second opinion.

 

awneil wrote:

Are you calling Jim a noob ... ?

 

surprise

 

mojo-chan wrote:
No, but I know why he is having trouble.

First off I WILL admit I am a noob....at XMEGAS.  As I mentioned in one of the thread, I am going to have to update a design thats using a Mega48 at the moment, and the SAM is too far away from my abilities to re-do the design reliably, and the XMEGS has the one ability I need, so hence it's the one I want to use.  The experience has not been pleasant I admit, but I am making progress.

 

mojo-chan wrote:
He wants to treat XMEGA like ARM, where everything is done with a nice framework and you rarely hit the registers directly...

W R O N G!!!  I want to first understand how the device works by the process of start small and work my way up.  I got an LED to blink, then I added the timer and a small counter to wiggle all the pins of PORTA.  All by using a tool that the manufacturer supplied that is/was supposed to work and it did as I was able to see the expected result, and then go in and look at what the tool did to better understand the programming by looking at WORKING code, rather than throw something together, it not work, and start a 50+post thread trying to patch it together and everyone getting pissy at each other.  As I said, things were going well, and then I added the USART and hit a wall.  I at least know that what work I did prior is functional, so I now know where I have to concentrate on to get past this bump in the road.

 

Now just a little sidebar...I am not 100% fan of START as I barked pretty loud in another thread regarding the amount of code it generated to do a simple port setup for a TinyAVR compared to the three or so lines I wrote to do the same thing.  But as I just said, for this "NOOB" learning a new chip, I have no problem using a tool thats available...as long as it workswink

 

mojo-chan wrote:
Maybe it's just me

Maybe....smiley

 

ka7ehk wrote:
Outstanding chip? YES! Popular? Nope!

AGREED!  I think it has to do with the fact that its NOT an AVR, and it's NOT and ARM.  It has a lot of the look and feel of an ARM, but its not and arm, and at the same time it has a lot of the simplicity of an AVR, but it's not an AVR.

No one knows where it fits in exactly...kinda like a platypus. LOL.

 

East Coast Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?  - Lee "theusch"

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

jgmdesign wrote:
..kinda like a platypus.

or an AVR32 ... ?

 

cheeky

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

jgmdesign wrote:
platypus

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

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

@jgmdesign wrote:

No one knows where it fits in exactly...kinda like a platypus. LOL.

Reminds me  of the disclaimer at the beginning of Dogma.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

Pages