Help to find xmega for stk600

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello; I'm new here and  I'm going to work serious with XMEGA via STK600.
Which XMEGA should I choose for a intermediate level?
I hop you nice people could help me as soon as possible.Thanks a lot. 

Tempress;

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

On the whole all Xmega (apart from the E series) are identical. It's just some have more/less of some peripherals. So to a certain extent it does not matter which one you choose. The original Xmega released that had "most of everything" was the 128A1 in fact. that chip had serious design flaws and was later withdrawn and replaced by 128A1U which fixed things like the ADC and even added a "free" USB peripheral to the chip.

 

So perhaps consider a 128A1U?

 

But to a certain extent (as always) your choice of chip should actually be dictated by what you ultimately intend to use it for. For example if your ultimate goal was to connect to the CAN bus in an automobile it obviously makes sense to pick a chip with a CAN interface and so on. So what application are you planning to use Xmega in?

 

(also why Xmega at this stage? The same money will likely buy you a 32 bit Cortex chip these days and it will likely deliver "more or everything" for that same money)

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

Dea Clawson; Thank you very much for your good reply.

My working area is Temperature Pressure and flow measurement.
I choose XMEGA, because of my good experiences with ATMEGA and stk500.
Unfortunately I'm not very good to change my current knowledge to a new area. 

Tempress;

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

As Xmega are radically different to Mega it's like learning a whole new micro architecture so if I was going to put in that effort I think I'd direct it to learning Cortex based chips in 2017. In what sense have the Mega's you were using previously failed to deliver for whatever it is you want to do now? IOW why change?

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

I keep seeing people mention the huge learning curve in transitioning from the Mega to the Xmega, I just note that I didn't find it that difficult. If one used a new peripheral, for example the DAC, then a little reading was obviously necessary. An 8 bitter micro certainly sounds reasonable for temperature and flow measurements and control, be it the Mega or the Xmega.

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

Jay things like you WGMs in TCCR and so on are quite different. In "traditional" chips once you know about the 0..15 WGM modes you can (often anyway!) expect most AVRs to behave similarly. Xmega is a whole new world in that sense. Even all your new PORT_TGLs (or whatever the heck it is actually called) are different. I know they add functionality but if you know DDR/PORT/PIN from tiny/mega that knowledge does not directly transfer to Xmega. Sure you may work out that the thre have become PORT_DIR, PORT_OUT, PORT_IN but the existence of all the other PORT_x (CLR, SET, TGL) are just plain confusing because, if anything, there are now "too many toys" to play with and it's more difficult to sort the wood form the trees. Same goes for anything. If I want to use Spi in any tiny/mega (well forget the dreadful USI!!) then I know I am looking for SPCR, SPDR and SPSR. No doubt Xmega has "equivalents" but they are a whole bunch of new names with new control bits. Sure, again., this may add more functionality (I believe SPI is variable bit length now - not just 8 bits?) but you aren't going to be able to hop from tiny/mega to xmega as you can hop between the tiny's and mega's.

 

And don't get me started on the subtle things like UART TXEN/RXEn not now taking directional control of the TXD/RXD pins so now it becomes your responsibility to set pin directions on the UART pins.

 

So, no, personally I don't believe Xmega are really anything like tiny/mega.

 

In fact I could be wrong about this but weren't Xmega designed in France by the team that did SAM7/9 and UC3 so the peripherals tend to bear more relation to those than tiny/mega?

 

For me, if I was putting in "effort" to make a transition and learn all these subtleties and nuances then I think my effort would be better expended on chips with more future potential like SAMD20/21, SAM3, SAM4, etc.

 

YMMV.

 

(and for me the same goes for UC3 - why tie yourself into something niche when Cortex exists in that arena?)

 

PS and the more I think about this the more examples I think of. In tiny/mega IO pins were simple, input, output or input-pulled-up. Doesn't Xmega now give you something like 8 options (and probably 5 I don't actually understand!)? I mean what in the heck is a "totem-pole"anyway and why would I want one?

 

PPS OK so probably bad example - totem pole turns out to be the "obvious one" with transistors to drive high or low. I guess it's the other options that are "odd"? (wired-OR, wired-AND, BusKeeper ...)

Last Edited: Fri. Nov 3, 2017 - 05:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tempress wrote:
My working area is Temperature ...
Some digital temperature sensors reach to 16b of precision.

If that's a possibility then XMEGA E has a 16b 12b SAR ADC with an oversample-and-decimate mode to reach 16b.

XMEGA E also has a better high impedance source capability in its ADC than XMEGA AU (XMEGA E ADC has variable sample duration)

XMEGA E leaks more than an AU

XMEGA AU have more local RAM and A1U has an EBI if need even more RAM.

In some ways it's a toss up.

 

Edit: strikethru

 

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

Last Edited: Sat. Nov 4, 2017 - 02:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Cliff,

 

No argument, just I still think the Xmega is an 8-bitter, and I hate to scare people away from it.

 

When I powered up my first Xmega I wanted to flash an LED, so I read the I/O pin config section.

New options and new configuration method.

Not too difficult, just "new", (and we know how well people like change!).

 

Then I wanted to try 32 MHz, so I read the clock section.

 

Then I wanted the equivalent of a CTC interrupt, so I read the Timer/Counter sections, and tested them a bit.

 

Then I read the priority interrupt section, as that was now needed for the T/C interrupt.

 

I think, for me at least, there was a big jump going from the Basic Stamp to the Pic, and a big jump going from the Pic to the AVR.

After that I think it was a bit more of an incremental upgrade to the Xmega.

 

That said, I do about all of my programming in Basic, either Bascom or ZBasic, with a smidgen of Asm and a direct register setup or two now and then, so much of what you have memorized for the AVR Mega and Tiny lineup is hidden from me.  For many peripheral modules I set a few parameters on the module's setup command and I'm done, so register names and such aren't ingrained in my head.

 

I will note, however, that I did stumble the first time using the Xmega E's.  I had a couple early chips and the chip wasn't yet supported by my preferred compilers.

I relied heavily on some guidance from JS to get a CTC equivalent ISR up and running.

 

The other significant difference was that just executing an ISR doesn't automatically reset some Xmega E interrupts, one has to manually reset them from within the ISR.  Not sure I've figured out the rationale behind that one, (perhaps it was a design "feature"?).

 

I'll admit, also, that being a bit obsessive / compulsive, I've read the Data Sheets for the micro's I've used cover to cover.

Although I might not recall the details, when I'm doing something new with the chip or a problem comes up I will often recall: "Didn't it say something about...", and a few minutes later I'm off to the next section of code.

 

Bingo pointed me to a Basic for Cortex chips, but I just haven't had time to work with it yet.

And then there is Basic for Androids, purchased for one project, but again no time to get back to that part of that project.

 

I'm going to be very busy when I finally retire!

Unfortunately, my wife tells me that won't be for a few more years...

 

JC 

 

 

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

Xmegas will run most AVR8 ASM code too without much change....wink There is a learning curve with the peripherals, no doubt, but I suspect not as steep as an ARM, at least from the little ARM experimentation I have done.

 

Of course being a part pensioner I don't really care anymore devil it's whatever, slowly moving from the PC keyboard to a musical keyboard too.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

@doc: IMO it's not the "8-bit" per se that makes the AVRs easy to deal with. At least not when not using assembler.
.
It's that with "8-bit" follos simple peripherals.
.
If the Xmegas peripherals are similar to the SAMs then I'd side with Cliff on this one.
.
(says me who's currently going through the SAM D20 peripherals. Not much to reuse from the mega328 there...)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

I really like these discussions...

 

When I started with AVR, the first device I was introduced with was the Xmega128A1U. So yeah I agree with clawson on this, that this is a good place to start with the xmega family.

I came from a Zilog background so this was a huge change for me, but the learning curve is not as steep as it looks. The manuals are great and this community here is also great for help.

Later, I discovered the more legacy AVRs, which are the Megas and the Tinys. Coding in C for them became simple coming from Xmega, for assembly it's almost the same. The Xmega peripherals though are more powerful.