XMEGA Family is Losing in the Popularity Polls

Go To Last Post
138 posts / 0 new
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: 1

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

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"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"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix 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!

 

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

awneil wrote:

jgmdesign wrote:
..kinda like a platypus.

or an AVR32 ... ?

 

cheeky

Good point

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"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"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

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

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

Gotta say I love the Xmegas, and I'm 90% hobbyist.

 

I looked at a couple of the new XTinies for a project and decided to just use an XmegaE5.

 

JC

 

 

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

When I started to use the Xmega and I wanted to understand the inside of it I used ASM, up close and personal, the timers were a big pain, not to mention the ADC.

 

Atmel support tried to "help" with ASF like code that buried everything even deeper, well sort of worked but I didn't know why.

 

So I have around 2,000 boards in the field now and, you guessed it, coded in ASM, about 8K of code. A lot of the stuff I had already for the AVR and it remained untouched ie it was "portable" devil

 

Apart form the way the peripherals are accessed and set up it's like using and AVR compared to say using an ARM.

 

+++++ Xmegas a lot more popular than ARM here.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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

Soldering is a big part of it, but also "breadboard/protoboard comapibility."  With DIP parts, you could believe that you could build a project without needing a PCB (breadboard, stripboard, perfboard, etc), or with a homemade little-effort PCB.  With TFQPs those options are essentially gone.  (Of course, the price of having high quality PCBs made has gone way down as well.)

 

 

5V is no longer for 8bit devices only, there are Kinetis E devices now and SAM C20/C21.

The Cypress PSoC ARMs are also 5V capable.

 

 

[XMega has] 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").

That's more of a style issue with the way the Atmel-provided .h files were created.  You could create similar definitions for most of the normal AVR peripherals.  It's sort-of a "C vs ASM" leaning, and I think I've seen mostly-ASM AVR programmers confused by the structure-based scheme ("when do you use "." and when do you use "->"?" and similar.)  It's especially "amusing" since the structure-like definitions can lead to smaller code (occasionally.)

 

 

I will ALWAYS be a hobbyist as long as I am experimenting with new things that I do not get paid for.

Indeed!  I've decided that "Professionals" are frequently indistinguishable from "Hobbyists" when it comes to that initial "evaluation" of new architectures and chips.  The number of occasions where a "pro" is given the time to PICK a new chip, based on all new research, are few; usually it's "we're using this chip that the Senior Engineer picked" or "this chip is supposed to be compatible with our existing code, but it's faster, so we should use it unless you see any major problems" or even "their engineers say it will be really great!"  (Oh, that lovely PA Semi MIPS chip we were going to use! :-()   A vendor can get more penetration by offering "play" systems at "play" prices that engineers (and hobbyists) can use without needing to be "sponsored."  (IMHO)

 

I like to wonder how things would have turned out if the "Arduino Mega" had used an XMega chip instead of the meag2560.   It would have been faster, with the more advanced peripherals, as well as having more memory and more pins.  Alas, I think the XMega was announced "too late" for this to happen, and it SHIPPED "much too late."  (sigh.)

 

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

Okay, I tried Atmel Start again. Tried to set up a basic USB vendor specific device and got this message:

 

 

So it hasn't even reached parity with the old ASF yet.

 

And the ASF is not great either. For example, you can't have DFU runtime with any other type of USB. And the whole stack is bloated as hell so forget fitting it into a 4k bootloader.

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

larryvc wrote:
Oh, BTW Start is a "nice framework"
Can you create a project to just toggle one GPIO line - how many lines of C, how many opcodes? If you now dig out the datasheet and write a "bare metal" version in C then how many lines of C is that and how many opcodes?

 

A lot of these libraries suffer from trying to be all things to all people. If they concentrated on "normal use cases" and what 95% of the users actually want/do they could probably be much more like the code us engineers might right. I can't help thinking of Peter Fleury libraries and what makes them so popular - they target exactly what it is the majority want to do.

 

I know this if a bit of an extreme example but take a USART. Who in their right mind ever used the "S" bit? Yet the vendor library probably caters for it and possibly complicates the bit we all use in the process.

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

clawson wrote:

larryvc wrote:
Oh, BTW Start is a "nice framework"
Can you create a project to just toggle one GPIO line - how many lines of C, how many opcodes? If you now dig out the datasheet and write a "bare metal" version in C then how many lines of C is that and how many opcodes?

 

A lot of these libraries suffer from trying to be all things to all people. If they concentrated on "normal use cases" and what 95% of the users actually want/do they could probably be much more like the code us engineers might right. I can't help thinking of Peter Fleury libraries and what makes them so popular - they target exactly what it is the majority want to do.

 

I know this if a bit of an extreme example but take a USART. Who in their right mind ever used the "S" bit? Yet the vendor library probably caters for it and possibly complicates the bit we all use in the process.

 

I agree completely. One of my recent example is a STM32 nucleo board that I want to use as a programming dongle for another architecture. I started with a simple led toggle at the default clock option. Then, the first important thing was to rise the clock to its max, 80MHz. This was exactly 10 lines of C code (without comments) at the register level (CMSIS). Switching clock sources, setting PLL, enable PLL, set the flash wait states, that stuff. Their library file only for the clock stuff is thousend of lines, lots of functions, with names that take half the line by themselves only.

Still, there are people that only complain about the lack of documentation for such a library. They don't realize that this won't happen, ever.

 

What a vendor should do, is to provide good examples, for the usual use cases. At the register level and properly commented in the same style as the user manual.

Having this, programmers can understand how and what to do to get their job done. With no bloat and no fat. And encouraged to read the datasheet and the user manual.

 

I can ask you (in general) the question: would you use a microcontroller with no user manual, no register level, only libraries documented by doxygen?

 

 

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

clawson wrote:

larryvc wrote:
Oh, BTW Start is a "nice framework"
Can you create a project to just toggle one GPIO line...

To be fair, this is taken out of context.  Did you read the whole post, especially the lean and mean part, did you follow the link.  We discussed Start before Cliff ;-)

 

On the whole, I do agree with your comments.

"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:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Back in the day...

 

The GW-Basic (PC),  and Basic Stamp, (micro), both had instruction books.

Each instruction had a description of what it did, and a short example.

Easy.

 

JC  

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

I still use the XMega, and in fact am using it in 3 current projects right now.

 

One project is going into a prop hub extender on a single engine aircraft (for actual flight), and the other is inside a user console of a custom made CNC machine.

The third project is a fun one, overclocking the XMega-384 to 68MHz to give a 6502 processor a new VGA output.

 

I think the XMega is the best damn 8-bit uC ever made.

You can overclock all of them up to 64MHz safely, and often reach 72MHz.

At 68Hz, I am getting 34MHz IO bandwidth, which blows all PICs (32bit included), and most ARMs totally away.

The only thing on my bench that beats XMega IO speed is an FPGA.

 

I hope the XMega stays around for a while!

 

Brad

 

I Like to Build Stuff : http://www.AtomicZombie.com

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

I like the XMEGA on paper, but I am starting to wonder a little based on some past threads on the thing, and the miserable experience I am having by trusting a certain utility I elected to use to configure the device.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"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"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

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

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

Sounds like your problem is more with the utility than with the chip itself ...

 

Seems that Start is giving you more of a Stop; it's a futility - not a utility ... ?

 

frown

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

I think the XMega is the best damn 8-bit uC ever made.

You can overclock all of them up to 64MHz safely, and often reach 72MHz.

At 68Hz, I am getting 34MHz IO bandwidth, which blows all PICs (32bit included), and most ARMs totally away.

The only thing on my bench that beats XMega IO speed is an FPGA.

 

The other great thing about the XMEGA architecture is how clean it makes your code. Peripherals are neatly self-contained and duplicated, and seem to be designed in such a way that you can write self-contained modules which don't conflict with each other.

 

On 8 bit PICs you have stupid things like shared interrupt vectors. The 16 bit range is a bit better in that respect, but the peripherals are still a bit of a mess in terms of what registers they use and your ability to write clean code for them.

 

A really interesting example of how Microchip just doesn't "get it" is their PIC24 USB stack. Maybe it's better now, but I have to maintain a product that uses it via polling in the main loop. Because of this the USB interface is extremely unreliable. Timing is all over the place because critical bits of it don't run in interrupts. And when you look at Microchip's example code it's clear they have no idea about careful separation and isolation of interrupt and normal code.

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

jgmdesign wrote:

I like the XMEGA on paper, but I am starting to wonder a little based on some past threads on the thing, and the miserable experience I am having by trusting a certain utility I elected to use to configure the device.

 

Jim

 

I have three projects with xmega, quite complex projects. When I started with xmega, the first thing was to carefully read the user manual. At least what I was interested in, GPIO, clocks, UARTS, ADC. At that time I even don't think START existed. I had no problem at all to get it working.

 

Your experience can confirm one of my feeling: the START like things (ST CubeMX, Microchip I don't know the name, etc.) probably put customers off. Atmel START is really bad in fact it seems. CubeMX and the Silabs equivalent are a lot better. CubeMX generates quite correct code, but based on their libraries. That really leaves you in the dark after the initialization code. At least the Silabs 8051 code generator generates code based on direct register access... It is the most honest code generator probably. It generates some writes to some registers and only that. Not claiming it's anything else. When you look at the generated code, you think: yes, what a simple code. I would have done that myself easily if I would have read the user manual.

 

 

 

 

 

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

I think the code libraries are mostly there to convince managers to use those parts. They believe all the stuff about being able to quickly get projects working, think they can get some budget contractor cowboy in to knock something up in three months because the manufacturer already did most of the work.

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

rammon wrote:
At least the Silabs 8051 code generator generates code based on direct register access...
But that is exactly what Start does!  More evidence that those that complain the most about Start understand the least about Start!

int8_t SPI_0_init()
{

	// SPIC.CTRLB = SPI_BUFMODE_OFF_gc /* SPI Unbuffered Mode */
	//		 | 0 << SPI_SSD_bp; /* Slave Select Disable: disabled */

	SPIC.INTCTRL = 1 << SPI_RXCIE_bp   /* Receive Complete Interrupt Enable (In Buffer Modes Only).: enabled */
	               | 0 << SPI_TXCIE_bp /* Transmit Complete Interrupt Enable (In Buffer Modes Only).: disabled */
	               | 0 << SPI_DREIE_bp /* Data Register Empty Interrupt Enable (In Buffer Modes Only).: disabled */
	               | 0 << SPI_SSIE_bp  /* Slave Select Trigger Interrupt Enable (In Buffer Modes Only).: disabled */
	               | SPI_INTLVL_LO_gc; /* Low Level */

	SPIC.CTRL = 0 << SPI_CLK2X_bp        /* Enable Double Speed: disabled */
	            | 1 << SPI_ENABLE_bp     /* Enable Module: enabled */
	            | 0 << SPI_DORD_bp       /* Data Order Setting: disabled */
	            | 1 << SPI_MASTER_bp     /* Select Master/Slave Operation: 1 */
	            | SPI_MODE_0_gc          /* SPI Mode 0, base clock at "0", sampling on leading edge (rising) & set-up on
	                                        trailling edge (falling). */
	            | SPI_PRESCALER_DIV4_gc; /* If CLK2X=1 CLKper/2, else (CLK2X=0) CLKper/4. */

	return 0;
}

 

I am not defending Start outright though, it has many interface bugs, and as noticed chooses pins poorly.  But let's get down to it, any programmer worth a grain of salt should be able to look at the generated code and spot what is off right away.  The most important lesson here is that you must read the datasheet, Start is not a substitute for it.

 

On the upside, they have been cleaning out more of the unnecessary cruft and reported flaws are being addressed.  Get used to Start as being a work in progress, it isn't going away any time soon.  If you don't like it, write your own bare metal code.

 

rammon, I do agree with your comments about the XMEGA being easy and well designed.

 

Brad, always nice to see you check in.  If you say the XMEGAs are awesome, then they must be!

"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: Sat. Feb 24, 2018 - 10:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

At 68Hz, I am getting 34MHz IO bandwidth, which blows all PICs (32bit included), and most ARMs totally away.

The only thing on my bench that beats XMega IO speed is an FPGA.

 

Here is a 40MHz signal out from a pin of an PIC32MX running at 80MHZ (not overclocked).

 

    And by the way, do you overclock your XMega for the propeller project ?

 

    I too thing that the XMega is the best 8 bitter on the market right now, but it cannot stand a 32 bit processor in general.

When I started to mess with microcontrollers, I weighted PIC vs Megas. I chose Atmel just because it was faster and I was able to build my own programmer based on the PonyProg software. At that time I could not afford an Atmel programmer. And since then I think I made the right decision. Later I kinda switched to XMega, and what I mean by saying that is that I would not go back to Mega again since XMega is here, unless it is about a very small project. Recently I started working with PIC32 and I amazed about it. Again, now I have the feeling that I would not go back to 8bit unless it is about a quick prototype or something very small project where a tiny would fit the bill.

    I do think that Microchip made a very good decision to go with MIPS instead ARM.

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

Sorry for the OT, but I notice you have a Kingst logic analyser. Are they ok? Would you recommend their products?

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

angelu wrote:

AtomicZombie wrote:

At 68Hz, I am getting 34MHz IO bandwidth, which blows all PICs (32bit included), and most ARMs totally away.

The only thing on my bench that beats XMega IO speed is an FPGA.

 

Here is a 40MHz signal out from a pin of an PIC32MX running at 80MHZ (not overclocked).

 

    And by the way, do you overclock your XMega for the propeller project ?

 

    I too thing that the XMega is the best 8 bitter on the market right now, but it cannot stand a 32 bit processor in general.

When I started to mess with microcontrollers, I weighted PIC vs Megas. I chose Atmel just because it was faster and I was able to build my own programmer based on the PonyProg software. At that time I could not afford an Atmel programmer. And since then I think I made the right decision. Later I kinda switched to XMega, and what I mean by saying that is that I would not go back to Mega again since XMega is here, unless it is about a very small project. Recently I started working with PIC32 and I amazed about it. Again, now I have the feeling that I would not go back to 8bit unless it is about a quick prototype or something very small project where a tiny would fit the bill.

    I do think that Microchip made a very good decision to go with MIPS instead ARM.

 

Hi,

How can you do 40MHz at 40% duty cycle from 80MHz clock? Just curious.

I'm with you about not going back to 8bit from 32. But I have designs that are 5V only. A 32bitter at 3V3 would complicate the design unnecesarly. Also, some of my boards are so simple that I almost feel sorry for a 32bit to put it there (as someone here said previously :)

 

I'm glad to hear that the PIC32 is great. I never used any, and probably I will continue to do that... Only that they came lately with a very very interesting chip, with a graphical coprocessor inside and 32MB DRAM! This really would fit on one of my designs, replacing an Cortex-M4 (LPC4088) and an external 32MB SDRAM.... For a new project of the same kind,it would be very tough to decide frown

 

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

larryvc wrote:

rammon wrote:

At least the Silabs 8051 code generator generates code based on direct register access...

 

But that is exactly what Start does!  More evidence that those that complain the most about Start understand the least about Start!

- for me it is a pleasant surprise it does register level access.

- I didn't use START, I concluded it is buggy from the posts here on avrfreaks. But I do use CubeMX and silabs studio, and I put the START in the same category. I won't say I don't (or can't) understand START.

 

larryvc wrote:

I am not defending Start outright though, it has many interface bugs, and as noticed chooses pins poorly.  But let's get down to it, any programmer worth a grain of salt should be able to look at the generated code and spot what is off right away.  The most important lesson here is that you must read the datasheet, Start is not a substitute for it.

 

On the upside, they have been cleaning out more of the unnecessary cruft and reported flaws are being addressed.  Get used to Start as being a work in progress, it isn't going away any time soon.  If you don't like it, write your own bare metal code.

Microchip should understand that such a tool sould be as rock solid as possible. They should make it like that asap. Because otherwise it can be a show stopper instead of a good helper. See Jim experience.

 

I will use such a tool myself for the following functionality:

- pin functions assignment. When you have chips with lot of pins and/or lot of alternate functions per pin, a nice graphical screen with the chip and the possibility to play with all the functions of the pins, and to see that graphically, is a pleasure. And very helpfull. A user manual cannot provide that.

- clock tree assignment (I now this from cubemx, but any complex chip with lot of clocks should have that). Complex chips tend to have complex clock tree. Seeing it on a single page and being able to play with it, change the clocks here and see all the implications here and there, it's very convenient.

 

But once you played with these graphicall interfaces and fixed the things in stone, the initialization code is simpler to write at the register level, now based on the user manual (you may understand the user manual even better after playing a while with the graphical interfaces!).

 

Speaking about code generation: I found it a bit frustrating because, after you have it generated for the initializations, you are left alone. I feel a bit dissapointed because I cannot generate more of my application functionality from the GUI (even I knew from the start that this is the case). And the net result is that you still have to read the user manual and to write your code, yourself.

 

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

Regarding the 40Mhz frequency from the PIC32. The Logic Analyser samples @ 200M/s i.e.5ns.
A 40MHz square wave has 25ns period i.e. half-period of 12.5ns. You will always see 15ns + 10ns unless you sample with an exact fraction of 12.5ns
Does a PIC32 really handle GPIO in one cycle? Or was this a timer output?
The XMEGA does do CBI, SBI in one cycle. And it works reliably when overclocked.
All AVRs can do IN, OUT in one cycle.
.
I think it is an excellent strategy for Manufacturers to provide some form of Code generator. Just to get someone started with their evaluation boards. It is wise to make the same demos work on every board. I do find it fairly convoluted.
.
I became quite familiar with the old Atmel app notes. Simple to follow but not always easy to port to different Atmel devices.
.
Any form of demo software must work 100%. If it does not, the Manufacturer's reputation suffers.
.
David.

Last Edited: Sun. Feb 25, 2018 - 08:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is the PIC output just a PWM channel? Or a long series of GPIO toggle op-codes?

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

david.prentice wrote:
Regarding the 40Mhz frequency from the PIC32. The Logic Analyser samples @ 200M/s i.e.5ns. A 40MHz square wave has 25ns period i.e. half-period of 12.5ns. You will always see 15ns + 10ns unless you sample with an exact fraction of 12.5ns

That clears the mistery.

david.prentice wrote:
Does a PIC32 really handle GPIO in one cycle? Or was this a timer output? The XMEGA does do CBI, SBI in one cycle. And it works reliably when overclocked. All AVRs can do IN, OUT in one cycle.

Even if it does, you can generate this output only inlining the instructions one after the other, for ... how many?

A better, and real life example would be how fast you can bitbang a simple SPI, read, write or even read/write.  Here, even if you inline eight spi bit cycles, you still need to serialize/deserialize the data. Another problem with these "monsters" is that they have pipelines, some of them quite deep pipelines. And running from flash you face the wait states problems...

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

With any micro you need to make best use of the hardware peripherals. e.g. USART_MSPI, DMA if possible.
I was just pointing out that the Xmega does this extremely well. Some instructions are faster e.g. SBI. All GPIO can work efficiently with VPORTs.
Yes, a small amount of inlining can make a dramatic difference to an "inner loop". Especially when the active body has few cycles relative to the loop control.
.
I can control TFT displays better with Xmega GPIO than Cortex-M0. However computation is more powerful with a 32-bit ARM.
.
It is unfortunate that the Xmega never appeared as an Arduino. It could have gained hobbyist support. And within an instant, cheap clone boards.
.
David.

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

david.prentice wrote:
Does a PIC32 really handle GPIO in one cycle? Or was this a timer output?

 

According to the datasheet,the ports have set, clear and toggle registers called CLR(clear), SET (set) and INV (invert), that's how a 1 cycle toggle is achieved.

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

next page in PIC32MZ EF :

12.1.3 I/O PORT WRITE/READ TIMING

One instruction cycle is required between a port direction change or port write operation and a read operation of the same port. Typically this instruction would be an NOP.

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

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

Well, but you don't need to do a read, right? Just writes.

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

That's just the input synchroniser, same as AVR.

"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

mojo-chan wrote:

Is the PIC output just a PWM channel? Or a long series of GPIO toggle op-codes?

 

A long series of GPIO toggle op-codes. I think AtomicZombie implies the same thing when getting 34MHz output signal from an Xmega at 68MHz.

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

I like the event and DMA systems on the XMEGA.

 

One trick I often do is to use a timer to detect the end of a transmission. An event resets the timer whenever the RX pin changes, and the timer is set to do a compare match after say 1.5 characters of no change.

 

I was reading a serial bus (Dreamcast game console) where it used two wires that alternate between data and clock. First A is clock and B is data, then after one clock the swap so A is data and B is clock. Bit rate is 2MHz so at 32MHz you only have 16 cycles per bit, but it's actually a lot worse than that because the duty cycle isn't 50%. In fact it varies from device to device.

 

But on XMEGA it's easy. Use an event triggered on a falling edge to trigger a DMA read of the port. Have two of these set up, one for line A and one for line B. Use the timer trick to detect end of transmission, rather than trying to decode and calculated the expected number of words in realtime. Then you just sit there until the timer interrupt triggers and decode the captures port readings at your leisure.

 

It's this kind of thing that makes XMEGA awesome. Other MCUs have events, they have DMA, they have timers obviously... But the flexibility and ease of use you get from XMEGA is rare.

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

awneil wrote:

Sounds like your problem is more with the utility than with the chip itself ...

 

Seems that Start is giving you more of a Stop; it's a futility - not a utility ... ?

 

frown

Absolutely.  Larryvc is defending it, and he is right in many respects, but in this age of manufacturers pushing their code generation tools as being superior to others I took START for a spin as I am a noob of sorts to the XMEGA...and the START experience is a STOPPER. Just my opinion.

 

larryvc wrote:
But let's get down to it, any programmer worth a grain of salt should be able to look at the generated code and spot what is off right away.  The most important lesson here is that you must read the datasheet, Start is not a substitute for it.

No argument from me on this.  My reasoning for using START was because of how complex the clock scheme is from what I had been reading in the XMEGA forum so my intent was to see what the utility does and dissect it.  Then I remembered my Codevision License does XMEGAS and took it for a spin.  As I posted in my other thread it kicked a&& on my initial test, but failed with the same issue when I add SPI to the project.  Working on that now to see what happened, and will report accordingly.

 

rammon wrote:
Microchip should understand that such a tool sould be as rock solid as possible. They should make it like that asap. Because otherwise it can be a show stopper instead of a good helper. See Jim experience.   I will use such a tool myself for the following functionality: - pin functions assignment. When you have chips with lot of pins and/or lot of alternate functions per pin, a nice graphical screen with the chip and the possibility to play with all the functions of the pins, and to see that graphically, is a pleasure. And very helpfull. A user manual cannot provide that. - clock tree assignment (I now this from cubemx, but any complex chip with lot of clocks should have that). Complex chips tend to have complex clock tree. Seeing it on a single page and being able to play with it, change the clocks here and see all the implications here and there, it's very convenient.   But once you played with these graphicall interfaces and fixed the things in stone, the initialization code is simpler to write at the register level, now based on the user manual (you may understand the user manual even better after playing a while with the graphical interfaces!).

Cannot agree more with this.

 

I stand by my opinion that I like the XMEGA...on paper.  I will probably like it even more once I get past the speedbumps I am hitting.  But my mood is telling me to send START back to the shop for a rebuild, and concentrate on using Codevision for things...Stay tuned for the outcome.  AS I also mentioned somewhere popularity is based on the user experience in this day and age.  My experience with START has not been pleasant.  I wonder what would happen if I try the configuration through ASF within Studio and see what happens.  As many know I am not a fan of ASF either, but I have used it here and there.

 

Grumpy times....Grumpy times...frown

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"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"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

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

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

jgmdesign wrote:
Grumpy times....Grumpy times...frown

 

Jim

Time for tea Jim? cheeky

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

@mojo-chan wrote:

It's this kind of thing that makes XMEGA awesome. Other MCUs have events, they have DMA, they have timers obviously... But the flexibility and ease of use you get from XMEGA is rare.

+1.  The XMEGA Event System is rather awesome, allowing peripherals to be interconnected in hardware, and to require CPU intervention only when a new measurement/result/state/etc. has been achieved.

 

The XMEGA peripherals have both a newer/smarter design and an intelligent register layout that is unseen (at least by my aging eyes...) in other 8-bit MCUs. 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

larryvc wrote:

jgmdesign wrote:
Grumpy times....Grumpy times...frown

 

Jim

Time for tea Jim? cheeky

Inside joke of sorts....but yes, exactly.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"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"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

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

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

Greg_Muth wrote:
+1.  The XMEGA Event System is rather awesome, allowing peripherals to be interconnected in hardware, and to require CPU intervention only when a new measurement/result/state/etc. has been achieved.

 

The XMEGA peripherals have both a newer/smarter design and an intelligent register layout that is unseen (at least by my aging eyes...) in other 8-bit MCUs. 

+1 and +1 for the aging eyes, seems to be going around.  The new ATtinys (XTINY) have the same Event System and Peripheral structure as the XMEGAs.  I've been amazed at what I have been able to accomplish with the XTINYs.  Should have given the XMEGAs more of a look a long time ago.

"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

The XMEGA Event System is rather awesome

 I wouldn't mind seeing some example projects that do neat things with the Event System.  It sounds neat, but all I can think of doing with it offhand is setting up the A2D to take samples at regular intervals without a timer ISR.  It's marketing seems aimed at power-saving (handling events while the CPU sleeps), which is not usually sometime I'm concerned with...

 

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

@larryvc wrote:

+1 and +1 for the aging eyes, seems to be going around

wink  +2.0 here!

 

 

EDIT:

I've been amazed at what I have been able to accomplish with the XTINYs.

I have a couple TINY817 Xplained Minis that I played around with a few months ago.  The "XTiny" moniker is appropriate.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

Last Edited: Sun. Feb 25, 2018 - 09:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@westfw wrote:

 I wouldn't mind seeing some example projects that do neat things with the Event System.

I must admit the neatest thing I've done is measure the echo pulse width of an HC-SR04, which is probably too simple to be termed "neat."  After configuration, the Timer's CCA interrupt fires when a new measurement is ready.

 

 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

Last Edited: Sun. Feb 25, 2018 - 09:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

westfw wrote:

Indeed!  I've decided that "Professionals" are frequently indistinguishable from "Hobbyists" when it comes to that initial "evaluation" of new architectures and chips.

 

This.  As a freelancer, my clients don't really care what chip I use, as long as it does what they want it to do.  If some outfit comes out with a new wunderprocessor but charges 10,000 Omani Dinar for the programmer and IDE, I'm not even going to experiment with it.

 

Because I won't experiment with it, it's not going in any of my new gizmo designs.  And the manufacturer won't sell any to me or to my clients who mass-produce the gizmos.

 

The same thing applies to those who pass out 'free trials' (Hi, Xilinx) and then ask for thousands of dollars a year to maintain a license so you can maintain a one-off product.  No.

 

If you want to sell chips, make it as easy as possible for people to use them.  Pay no attention to the beancounters who say, "Hey, we wrote all this software, we should monetize this!"  NO.  Tell those beancounters they're penny-wise and pound-foolish, because the more they charge to develop with those chips the fewer chips you are going to sell.

 

And isn't your business selling chips?

 

Thank you,

 

S.

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

I should have been more specific when I seemed to bash the PIC32!

What I was doing was a tight, cycle counted loop in assembly to read from internal SRAM, and then send a full byte to a port.

The XMega can do this in 3 cycles...

 

ld r1,X+ ;2
out VPORT,r1 ;1

I spent a few weeks learning MIPs for the PIC32-MZ series, and finally realized that the XMega stomps all over it when it comes to getting data from internal SRAM out to a port in a fast and predictable manner.

 

Clocked at 68MHz, I can achieve a 256 color fully bit-mapped VGA resolution of 580x480 purely by bit banging alone.

I do a lot of this kind of thing for fun, just to see what processors are made of. XMega is the clear winner by far.

 

To the other question... no, my propeller torque sensor and data logger project is clocked at the "legal" 32 MHz.

Someone is going to be in the air with this thing (not me!), so everything is being done to ensure safety.

The other production board I used an XMega on is also clocked using the internal 32MHz clock.

I chose XMega for both projects as it was cheaper than an FPGA for similar performance.

 

Also, just for fun, I have had an XMega256 overclocked to 64MHz, and over-volted to 5v running for almost 4 years non stop.

This project has been displaying NTSC video, using the entire 256K program memory and all of SRAM since 2013.

I plugged it in and let it sit in a corner of my lab so I could do a "rebuttal" to all those claiming that overclocking could harm a uC.

The over-volting from 3.3v to 5v was just icing on the cake!

I intend to post my results in another year or so.

Again, just for the hell of it.

 

I hope one day an even faster XMega with more SRAM comes out.

Rated for 80MHz, with 512K of SRAM.

Give me that, and I will stop using FPGAs altogether.

Ditch the old PIC8 family and make me a new XMega!

 

Brad

 

angelu wrote:

mojo-chan wrote:

Is the PIC output just a PWM channel? Or a long series of GPIO toggle op-codes?

A long series of GPIO toggle op-codes. I think AtomicZombie implies the same thing when getting 34MHz output signal from an Xmega at 68MHz.

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Mon. Feb 26, 2018 - 12:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
I wouldn't mind seeing some example projects that do neat things with the Event System.
Though not a project (it's a post)

AVR Freaks​

E5's XCL doing 2Mbps(!!!) FSK, appnote to follow

https://www.avrfreaks.net/forum/e5s-xcl-doing-2mbps-fsk-appnote-follow

...

- receive pin drives an event which is configured to RESET the XCL's timer BTC0
...

- XCL is configured in DFF mode, where the receive pin's event selects via MUX whether the D flip-flop is looped back or latched to the OC0 value.

...

westfw wrote:
... without a timer ISR.

AVR42772: Data Logger Demo Application on XMEGA A1U Xplained Pro

APPLICATION NOTE

http://ww1.microchip.com/downloads/en/appnotes/atmel-42772-data-logger-demo-application-on-xmega-a1u-xplained-pro_avr42772_applicationnote.pdf

(page 5)

2.2. Event System

...

In this application the event system removes 64 relatively short RTC interrupt routine calls per program cycle, and give us approximately 1% lower power consumption by using the event system.

...

via http://start.atmel.com/#examples/CustomBoard-ATxmega128A1U-AU

 

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

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

AtomicZombie wrote:
I hope one day an even faster XMega with more SRAM comes out.
Conversely, a 16-bit data path with variable-width (up to 16b) single-cycle I/O ports.

Anyone for AVR16?

 

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

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

westfw wrote:

 I wouldn't mind seeing some example projects that do neat things with the Event System.  It sounds neat, but all I can think of doing with it offhand is setting up the A2D to take samples at regular intervals without a timer ISR.  It's marketing seems aimed at power-saving (handling events while the CPU sleeps), which is not usually sometime I'm concerned with...

 

Another trick I did using the event/timer system I outlined was to handle the NMEA output from a GPS module. Used DMA to capture characters into a buffer with no interrupt overhead, and the event/timer to detect the end of the sentence block.

 

I also used an event triggered by the 1 PPS pulse to restart a timer for super accurate timing.

 

Oh, I did an RTC calibration routine using the XMEGA timers with a 10MHz TCXO reference clock and the event system triggered by the RTC overflow causing a timer capture. If the capture is under 10M you know that the RTC is running fast, if it's over you know that the RTC is running slow, and you can calculate exactly how much you need to compensate by.

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

Rammon is spot on.

 

Libraries often do too much and have unwanted side effects. The classic example is the ASF code for the XMEGA, which disables all the peripheral clocks as part of the clock management init code. You include it because you want to set a 32MHz core clock, but then find that it disabled all your peripherals for some unknown reason. Why isn't that part of the power management module? Because it has the word "clock" in it? And what part of "init" implies "disable everything"?

 

The AVRxxxx app notes and example code are much better. You can use them as libraries or as references. They are short enough and transparent enough to understand, unlike the ASF that has 50 layers of abstraction or code generators that produce thousands of lines of mostly unused crap with little organization for you to sift through.

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

gchapman wrote:

Conversely, a 16-bit data path with variable-width (up to 16b) single-cycle I/O ports.

Anyone for AVR16?

 

 

The Chinese AVR cloners at Logic Green Technologies devised a clever trick; certain memory areas trigger 16 bit access. So, for example, if you store r16 to these addresses, actually r16 and r17 are written to consecutive byte addresses. That is, "st Z, r16" causes a 16 bit write. They used this only to a very limited extent, though.

Of course gcc has no notion of this feature so it can only be used from assembly. Still, it's an idea...

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

So, for example, if you store r16 to these addresses, actually r16 and r17 are written to consecutive byte addresses.

I expect that will only have value to the likes of Brad if both bytes are written in the same clock cycle i.e. a true 16-bit write, not two consecutive 8-bit writes.

"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

XMEGA AVR at Microchip :

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

Again though now it's QFP-100 for XMEGA AVR and megaAVR (iow AVR with a segment LCD controller (many segments) or an EBI)

Microchip Technology Inc

Microchip Technology

Product Change Notification - GBNG-05QUVX037 - 09 Aug 2018 - CCB 3496 Initial 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 100L TQFP (14x14x1.0mm) package.

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

...

 

Affected CPNs:

https://www.microchip.com/mymicrochip/Data/GBNG-05QUVX037/GBNG-05QUVX037_Affected_CPN_08092018.pdf?TimeStamp=8/9/2018%203:35:12%20PM

 

...

 

Estimated Qualification Completion Date:
November 2018

 

...

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

 

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

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

I'm a great fan of the ATXMEGA range and wait for the day when USB OTG is provided.

Sad to say, but  if Microchip loose interest in the ATXMEGA range, then when the IP period has run out, I hope the Chinese do start selling compatible chips.

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

jalbinson wrote:
... and wait for the day when USB OTG is provided.
USB OTG isn't a part of XMEGA AVR for a reason.

jalbinson wrote:
... if Microchip loose interest in the ATXMEGA range, ...
That will not occur as long as XMEGA is a commodity.

That's apparent for several XMEGA due to increased assembly production capability.

Will the ones at Microchip seek to better compete against MSP430TM and its ecosystem by a follow-on to XMEGA and PIC24?

(the best of both plus a twist or two)

jalbinson wrote:
... then when the IP period has run out, I hope the Chinese do start selling compatible chips.
currently that's by Logic Green for a relative few AVR.

https://www.avrfreaks.net/forum/forbiden-tech-china-has-arrived

https://olimex.wordpress.com/2013/12/12/3-arduino-possible-holly-molly-chinese-avr-clones-are-coming-meet-lgt8f88a-mavr-core-processor/

 

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

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

jalbinson wrote:

I'm a great fan of the ATXMEGA range and wait for the day when USB OTG is provided.

Sad to say, but  if Microchip loose interest in the ATXMEGA range, then when the IP period has run out, I hope the Chinese do start selling compatible chips.

 

Why would the Chinese want to sell XMEGA clones ?

The new low-end MCU of focus in China, is now the 8051 - no licenses, no tariff risk, and good eco-system.... 

 

If you want USB-hosting, the company that makes the CH340, now has a series of USB-MCUs

http://www.wch.cn/products/categ...

https://lcsc.com/search?q=CH55

 

 

  • 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