XMEGA

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

Any one know much about the AVR XMEGA chips, I have just had someone arrange to come and see me next week to show me them. It would be nice to have some background so i know what he is talking about.

thanks

James

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

Searching the Forums for "xmega" should uncover all that common people know about them.

It is encouraging just to hear that they may, in fact, be real. Report back as much as you will be allowed to say.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I will do its a distributer that is coming to see me they have just been to a seminar and think i will be intrested.

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

I checked the Atmel website and found NOTHING about XMega. I used the parametric search on the 8-bit RISC processors and got nothing faster than 20MHz, so apparently the XMega devices are not there. None of the other microcontrollers seemed applicable either.

Where on the Atmel website might we find something about the XMega chips?

-Tony

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

But that's the point - so far all anyone has heard are "whispers in the wind".

This thread (like several before it) provides a place to pool the rumours.

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

so you are going to talk to someone, who claims to have seen one?!? get yourself a camcorder and record that event! it's historical ;) We too want to see/hear/read about that!!!

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

I saw a whole spool of them being carried by Elvis into his UFO, but he took off before I could ask any questions.

Smiley

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

bloody-orc wrote:
so you are going to talk to someone, who claims to have seen one?!? get yourself a camcorder and record that event! it's historical ;) We too want to see/hear/read about that!!!

goujam wrote:
I have just had someone arrange to come and see me next week to show me them.

To me, goujam's statement implies that the Atmel rep. will have some XMega's "In Hand... "

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

smileymicros wrote:
I saw a whole spool of them being carried by Elvis into his UFO, but he took off before I could ask any questions.

Smiley

It's at times like these; I wish the future you had not destroyed your time machine as you could have easily fixed this in so many ways! :lol:
Like going back to the future and returning with free samples of AVR's from 2010, 2020 or at least antique XMEGA's!!!

John

Resistance is futile…… You will be compiled!

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

I dont think he will have samples, he just wants to talk to me about them. I hope he will have some literature, he seem quite impressed by them so we shall see.

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

I asked my distributor (http://www.spoerle.de) today about the availability of the XMega AVRs because they already have mentioned them in their online product listing. The sales guy replied, that they will hit the market at the first quarter of 2008 (March) - samples maybe a little bit earlier. I also asked him for further details about the new family and he said, that he will try to get some further infos. I will keep you informed.
So far, they are listing 10 different versions with the pin count, Flash-, eeprom- and SRAM- size but no further info. The biggest one comes with 256 KB Flash, 16K SRAM and 2Keeprom.

By the way - that was my first posting at the AVR freaks forum. I started my first little Atmel project two or three weeks ago and enjoy this forum a lot. Greetings to everyone...

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

Welcome Elektro_Lurch, I am fairly new here as well i started AVR's 6 months ago.

It looks like your distributor Spoerle is part of the same company who are coming to see me Arrow Electronics.

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

Yep - Spoerle is an Arrow company.

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

Found There :

Quote:
Title: AVR Xmega Redefines the 8-bit World
Details: Atmel is presenting the new 8-bit ‘XMEGA‘ device able to perform 32 MIPS @ 32 MHz with an outstanding analogue capability; this device will be code-compatible with the existing MEGA & TINY on which we will give you an update, followed by a presentation on the ATMEL Zlink solution, a 2.4 GHz radio bundled with the AVR of your choice.

Author of simavr - Follow me on twitter : @buserror

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

Two files from the internet

http://www.fourwalledcubicle.com...

http://www.improveatmel.com/pres... (see chart at page 17)

Attachment(s): 

Last Edited: Thu. Sep 20, 2007 - 09:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Michael and lpapad!!!
John

Resistance is futile…… You will be compiled!

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

Wow, that one big corporate soap-opera going on in 'New_Atmel.pdf'. Perhaps something not meant for our eyes?

Matt.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Last Edited: Thu. Sep 20, 2007 - 09:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wells
http://www.fourwalledcubicle.com...
is from Dean's Site he wouldn't publish it untill they say it's OK.
Cheers,
John

Resistance is futile…… You will be compiled!

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

Quote:

You can also find datasheets for the XMEGA TM A family here:

One word: Wow.

It looks like configuration of all the pin options will be quite a bit like starting up a SAM7S or similar.

A disappointment for us Mega48/88 fans: the small size has no analog.

I'm guessing this all won't be given away. It will be very interesting to get ballpark figures for the X vs. "comparable" Mega.

One surprise: No multiply-accumulate.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I found this on the Atmel web site.

http://www.atmel.com/ir/document...

It's referring to the XMEGA for 2005.

This one is from July 2007

http://media.corporate-ir.net/me...

Check out slide 13 too.

official AVR Consultant
www.veruslogic.com

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

Quote:

Check out slide 13 too.

Where 76% would consider a PIC for their next design, and 32% an AVR?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Xmega not too interesting for me as far as I can see.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

Wells
http://www.fourwalledcubicle.com...
is from Dean's Site he wouldn't publish it untill they say it's OK.
Cheers,
John

Actually I haven't heard anything. Someone here posted it from god-knows-where, but it disappeared so I hosted it for them for AVRFreaks so it wouldn't screw up again. I haven't heard anything from Atmel so I assume it's ok - of course, if they ask I'm happy to take it down.

Apparently someone from a German AVR website found and hotlinked it, so now my logs show a large amount of hits off it from microcontroller.net each month. Lucky it wasn't a high-definition bandwidth-sucking movie!

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:
Where 73% would consider a PIC for their next design, and 32% an AVR?

Well, they accomplished what they wanted to with me on that one. I stopped at Freescale. :oops:

official AVR Consultant
www.veruslogic.com

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

Quote:
I stopped at Freescale.
I hope you don't mean that you are using Freescale chips, you'll be sorry if so, spoken by experience.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

Xmega not too interesting for me as far as I can see.

Spoken by a guy that rarely uses the A/D.

In most microcontroller apps (with emphasis on the "micro" and on the "controller") I rarely run out of gas with the current AVRs, even at modest clock rates. But there are a few jobs where the AVR >>is<< pushed, and a number of apps that are just not suitable. The Xmega should help in both cases--faster top clock speed, and ability to tackle some of the "unsuitable" apps (more on that later).

The claim is lower power than the P chips. Let's just call that a wash and say that the low-power modes are at least "very good". So we haven't lost anything there.

Some apps a 10-bit A/D just ain't enough. Not only do we get a 12-bit ADC, but much faster at Msps rather than Ksps. If really needed the big boys have two ADCs.

When a DAC is needed, having an integrated 12-bit DAC saves a buck or two vs. external DAC or the filter/driver parts needed for a PWM DAC.

I haven't read through the section on the serial peripherals (USART, TWI, SPI). But the list indicates there are LOTS of them. (In several apps we have used multiplexers to direct the limited number of AVR USARTs to different "destinations".)

Some have been disturbed at the lack of an interrupt-priority mechanism on AVRs. No longer.

Now, at least the ADC and serial peripherals can have DMA (and some double-buffered). I don't know whether input capture can also be DMAed, but I think the DAC. That, coupled with the other features above such as high-speed ADC will be of immense help in some apps that just aren't suitable for AVRs.

The I/O ports have a lot of configuration options that the AVR doesn't have now, such as push-pull and pull-down. Add in an accurate internal clock, a 1% reference, and a few other toyz and more AVR apps can be near-single-chip. The cost and size may well make up for a somewhat higher price.

As I mentioned earlier, many of the features seem to be the mechanisms used in the Atmel version of the ARM7TDMI/SAM7x chips. Top clock (flash read) speed about the same. ADC/DAC about the same. I/O pin configuration options about the same. Interrupt controller with many of the same capabilities.

If not too pricey I think it will be a hit in the middle of the range--an alternative to, say, a Mega324 app. Since the instruction set is (or seems to be) the same we can use our same tools that we already have--nearly all the new stuff is in I/O space. With the smallest having no ADC I don't see it squishing my Mega48/88 apps, though there are a couple that are running out of gas but are also price and size sensitive.

I'd say for me definitely VERY interesting. I'm anxiously waiting to see the price points and availability. Hopefully the smaller sizes will hit soon but the leaked documents pretty much are A1.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
I hope you don't mean that you are using Freescale chips, you'll be sorry if so, spoken by experience.

No. I didn't consider the two other PIC product lines in my impression as theusch pointed out.

I agree on the Freescale thing. I went to one of their workshops once and the instructor couldn't get it to work. Code Worrier is a mess too.

official AVR Consultant
www.veruslogic.com

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

Quote:

Well, they accomplished what they wanted to with me on that one. I stopped at Freescale. Embarassed

It WAS meant to be a slide flashed at a big meeting for the general population, after all. Of COURSE the spin-doctors are going to dig out some way to show Atmel/AVR with the longest tool (eerr--bar).

But for a new architecture in an already mature (the 8-bit micro was declared dead long ago) market the AVR has grown nicely to a significant market share and enough volume to be [quite--one of the other references] profitable.

The Xmega should help to address at least some of the concerns recently presented here with ARM and PSoC, for example.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I was told the ST ARM cortex parts have configurable I/O pins. So if you need an SPI AND input capture that share the same default pin, you can move the functions to other pins. Is this something we will see in the XMEGA?

official AVR Consultant
www.veruslogic.com

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

Darn, John, you just ain't excited?!? With just the Xmega and a MMC you can make a 1Msps datalogger and have enough time left over to do digital filtering and/or data compression.

Or add a display and have a Msps digital 'scope with the only additional components being the ranging/protection on the probe inputs.

Or add on to that with logic analyzer.

Or finally have the AVR be able to do high-quality sound capture.

Or finally have the AVR have enough oomph to drive streaming peripherals like AC97 codecs.

Or finally be able to match Jesper's miniDDS without resorting to cycle counting.

After the Xmega learning curve all of the above are going to become starter apps that can be tossed together in a day or two. We already >>know<< how to drive our displays with AVRs; we already >>know<< how to communicate; etc.

And you aren't excited???

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

++ : As a first guess based on the A1 summary all Xmega will be rated to 125 degrees C.

-- : It looks like a 3.6V max supply. May not be a biggie nowadays.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
And you aren't excited???
baaah humbug :lol: all I need is for Atmel to put DW on the M8515 and M8535, otherwise the current range is perfect. The M48/88/168 is the most I really need (M328 I'll get just for fun), I have done a few T2313 project. I have used M64 because I needed more pins to match the HC11 pins and the M128 so I could write "Hello world!" in C.
Memory wise I have never needed more than 8K so far and speed wise I use 8MHz as standard and many times I have to put a few nops to slow things down. Started to use the M164 only because I can use it to emulate the M8535 for debugging, JTAG is a pain otherwise. A DAC would come in handy in my current project but a simple R/2R network has been doing a good job for the past 15 years, also a 12 bit ADC but I use an external one anyway.
All I need is the current range to be available for a few more years and then I'll retire and start working with vacuum tube amplifiers :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

...and the M128 so I could write "Hello world!" in C.

LOL Good one.

Quote:

...Memory wise I have never needed more than 8K so far and speed wise I use 8MHz as standard...

Most of ours are 7.3728 and 3.6864 as well. I do have some 32k+ projects, but those are about 6 months (that's my rule-of-thumb: full Mega32 is 6 months; Mega48 is one month. Comes out pretty close with design & redesign & new board revs & ...).

But there are that 10% that could really use some of those features. And some that are just plain not attacked (see my list of "easy with Xmega apps above) 'cause a conventional AVR just won't hack it.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

According to the datasheets it'll be a VERY powerful thingie. 32MIPS is nice, but 2MSps 12bit ADC and 1MSps DAC makes me drool. Where can I get one!? I want my xmega!

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

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

all I can say is: DROOL-DROOL ;)
Angry Orc in a need of XMEGA!

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

I just care about the DMA and prioritized interrupts. DAC will be nice as well, though to be honest I don't need DACs very often. But man do I love DMA...

I just wish they'd get off their bums and release the buggers.

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

Hi,

Just to note that a man from Atmel on Friday assured me that these things may be a lot closer than you might think - probably can't say exactly when, but they do look like very sexy devices!

Cliff

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

It's about time! Based on the leaked stuff they should have been trickling out a year ago.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
Based on the leaked stuff they should have been trickling out a year ago.

That's ridiculous. Do you base your purchases on leaked information? When has Atmel announced such devices?

I would think that you would be thrilled that Atmel hasn't announced vaporware.

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

Quote:

That's ridiculous. Do you base your purchases on leaked information? When has Atmel announced such devices?

Easy now, EW.

1) It isn't >>that<< ridiculous, as the evidence (see below) indicates.
2) Yearning/expecting/hoping isn't "basing purchases".
3) Let's leave digging out "available now" vapour for a different discussion.

One of the links above http://media.corporate-ir.net/me... indicates a 2006 date. And tell me that OleBrom http://www.avrfreaks.net/index.p... is not an Atmel person...

Quote:
The Xmega will be released in February 2007 and will have the same instruction sets as the other AVR's. The speed and pheripherals are better and includes i.e. 12-bit/2Msps ADC, 12-bit/1Msps DAC, built-in DMA controller..

along with some datasheets and other info. The first info was indeed found in 2006 and the OleBrom date of Feb. 2007 gives rise to my "year" comment.

In any case, we can't use them till we can hold them in our sweaty palms. See my posts above for the excitement that an enhanced AVR will bring. Again, it is disappointing that the Mega88-killer won't have an A/D, and thus won't be [a Mega88-killer]. The cost of these advanced features will be VERY interesting in making selection decisions.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Meanwhile the lowly Rabbit 4000 microprocessor has DMA and 60mhz clock. Dont know the mips/mhz yet. Their microcomputer module has 12 bit a/d onboard. Not quite the same as onchip, but close if the cost is comparable. Just for comparison.

Imagecraft compiler user

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

To add to the speculations pool: What was the mystery thingie the fellow was playing with on the AVRTV video?
...
...
...

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

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

Hmmm. ADC into a DMA channel would make my current task about 256 times easier... Hurry up Atmel!

Quebracho seems to be the hardest wood.

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

theusch wrote:

One of the links above http://media.corporate-ir.net/me... indicates a 2006 date. And tell me that OleBrom http://www.avrfreaks.net/index.p... is not an Atmel person...
Quote:
The Xmega will be released in February 2007 and will have the same instruction sets as the other AVR's. The speed and pheripherals are better and includes i.e. 12-bit/2Msps ADC, 12-bit/1Msps DAC, built-in DMA controller..

A leaked document for a shareholder meeting, and some unknown person posting on AVR Freaks, does not equal a corporate news announcement.

One cannot say that a product is late, if it has never been *officially* announced. Until then, all bets are off.

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

Quote:

A leaked document for a shareholder meeting,

Huh? How can shareholder meeting documents be "leaked"?
I suppose the datasheets are just April Fool's elaborate fabrications like the Signetics (?) Write-Only-Memory (WOM)?

I don't know what turned your crank, EW. I didn't say "late", is "should have" coupled with "trickling" inciteful rhetoric?

Still looking forward to the beasties.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:

I don't know what turned your crank, EW.

Sorry, Lee, it's historical. I know that you've complained about Atmel's vaporware in the past, what with announcing devices, and then they come out a year (or more) later, or not even at all.

theusch wrote:

Still looking forward to the beasties.

Yeah. I know what you mean. :D

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

theusch wrote:
Still looking forward to the beasties.
Yes, the leaked capabilities look very useful.

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

ok firstly leaked datasheets are not a product announcement, they are only good as a glimpse as to what a product might be, and it's questionable at best even then. Nor is a stockholder report a product announcement. Stockholder reports regularily contain "forward looking statments". So while the plan might have been to announce/release the xmega back then, it never happened for whatever reason (engineering delays, marketing shifts, etc).

Until Atmel flies a banner saying "New AVR XMega Introduced", or something to that effect, the product doesn't exist, and it's not late, nor is it vapourware.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Last Edited: Mon. Jan 14, 2008 - 07:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I know that you've complained about Atmel's vaporware in the past, what with announcing devices, and then they come out a year (or more) later, or not even at all.

Yes, I certainly have, and will probably continue to do so. ;)

In this case, it is probably due to the lack of oxygen from holding my breath waiting for that nebulous announcement for about a year. lol

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
Quote:

I know that you've complained about Atmel's vaporware in the past, what with announcing devices, and then they come out a year (or more) later, or not even at all.

Yes, I certainly have, and will probably continue to do so. ;)

I'm really hoping you won't have to. :wink:

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

Not to pee on anybodies campfire, but is there a company that doe NOT leak product information that is either arrives late or never?

Smiley

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

Joe,

I know one - I've worked here 24 years.

Cliff

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

There were two seminairs the other day in Germany where the X-mega was shown/discussed.

Is there anyone who has some info about it?

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

Nick, do you know if the information provided was under a non-disclosure agreement?

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

Quote:
if the information provided was under a non-disclosure agreement?
Most likely. No one is allowed to know when they REALLY are available :? maybe the odd freak knows...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

This is what I found about the XMega:
http://www.changnamint.com/board...

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

I'm going merge this onto the end of the existing Xmega discussion...

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

Hi,

I just saw it on the seminar page from atmel. They reffered to another company: http://www.msc-ge.com/seminare/

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

Fleemy, thanks for the pdf. I'm still looking for the pdf preliminary data sheets that were posted by are now gine. Can someone pm them to me or tell me where to find them. Thanks!

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

Dean's still got them at fourwalledcubicle hasn't he??

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

Cliff,

It is dark out there :lol:
Can you pm them?

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

I don't have them (I'm waiting for my Atmel FAE to send me the real ones in fact) but, like I say, I'm pretty sure Dean cached a copy on his site so maybe try a PM to abcminiuser (but you'll have to wait for Aus to wake up now I guess)

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

Wouldn't it be neat if an Atmel Fab engineer told us how the first parts are allocated.... How many die can be made on an 8" wafer? How many wafers in a boat? So the whole first run goes to big outfits that have preordered 1000s of xmegas, one chip at a time? So we wait for the 2nd run for the FAEs to get samples? And how are fab runs scheduled? Wait till the orders for a boat load of 168s backs up, then run that one? So you always schedule the highest profit product? There must be a priority scheduling system for these things like a task list? How about a freaks signup sheet?

Imagecraft compiler user

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

I'm in!
JC

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

The prelim overview of the XMEGAs:

http://fourwalledcubicle.com/fil...

Note that this is probably totally out of date. If anyone sends me the leaked datasheets, I'll host those too.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

I wonder if the boardroom soap opera and CEO jump-ball goings-on will hurt Atmel in being chosen for large new design wins.

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

bobgardner wrote:
There must be a priority scheduling system for these things like a task list?

As I guess Atmel's goal is only really making the greatest return for their shareholders I imagine all the early samples went to the 10 million+ customers but the fact that most of the compilers are likely to have X support on day one means that maybe a few went out in that direction too - now, does anyone know anybody involved in compiler development?

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

If I guess 200 die per wafer and 20 wafers per boat, the initial run would be 4000 chips... which I assume go to the first 4000 customers with the highest orders. Can we assume Eric W is modifying the avr gcc compiler as we speak?

Imagecraft compiler user

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

Quote:

If I guess 200 die per wafer and 20 wafers per boat, the initial run would be 4000 chips... which I assume go to the first 4000 customers with the highest orders. Can we assume Eric W is modifying the avr gcc compiler as we speak?

LOL. Now >>that<< is thought-provoking.

-- EW made a recent post in the GCC Forum which I interpreted like this, relating to WinAVR support of new AVR models: "Since I'm intimately involved with WinAVr & Atmel, users should see WinAVR having timely support for new models."

-- There was another lively exchange a while back where IIRC EW insisted that Atmel did not give any special treatment to any particular compiler brand.

Ergo, if EW is, in fact, busily cooking up XMega recipes, then the same should be happening with Pavel at HPInfoTech and Richard at ImageCraft and at BASCOM and at CrossWorks and ... .

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Well the men in black from Atmel actually mentioned a number of different C compilers that were likely to have X support on day one - not just GCC. I don't think anyone's going to be too disappointed.

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

My inside info at Imagecraft was saying he was done a year ago when they announced the imminent introduction of the xmega.....

Imagecraft compiler user

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

Though presumably it later required actual chip samples to test that the implementation was OK?

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

We'll have to see once all the details are out, but I can certainly see where the AVR8 compiler vendors could certainly support these chips quickly, perhpas no more than any new AVR model line:

--It >>is<< an AVR, after all.
--I don't remember mentions of any new instructions. The instruction set is pretty much full anyway, right? Little if any room for new op codes.
--I/O registers are I/O registers.

It is setting up and >>using<< all these fancy new features such as DMA and port re-mapping that is the hard part. The compilers themselves probably care less--the code generation is going to be the same. It is going to be stuff like the app building Wizard that may lag way behind. [So again WinAVR is obviously the best since it doesn't concern itself with trivia such as app builders or IDEs or the like.]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Don't know about the other compilers but to add a new entry to the -mmcu= compiler parameter to GCC actually requires changes in several places. Then the supporting io.h needs fixing up and an io???.h for the specific part(s) to be supplied.

But yes, as long as it conforms to the "avr5" architecture otherwise it should be pretty much a "shoe in" I guess.

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

Isn't there a couple of new instructions? A multiply and accumulate or something?

Imagecraft compiler user

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

It would be nice to have dsp instructions - proper pixed point arithmetic. Good dac's / adc's, analog comparators and plenty of ram/flash. Then I could make me a software radio. But maybe I'm dreaming and should find another processor company that have them on the shelf.

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

I don't mean to offend, I'm simply curious. What is the big deal about these XMEGAs? I feel I must be missing the point. Looking at the preliminary info Dean posted, they don't look THAT special.

Matt.

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

I concur. The chips will be outdated the moment they are launched. Right now I'm looking at luminarymicro's stuff.

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

Matt,

Depends what you are after - you might just look at them as an ongoing development in the line of Tiny - Mega - Xmega. The reason folks find Mega's "better" (whatever that means) than Tiny is probably the same reason why folks will find Xmega "better" than Mega's. I know some specific things that I thought "hey, it's about time AVR8's got that" when it was described to me. There are improvements in areas like ADCs (and added DACs), much better internal oscillators, DMA, interrupt and "event" priority systems and a whole bunch of other stuff that are just a natural progression. I guess users of mega88P probably prefer it to mega88 and users of that prefer it to mega8 and users of that prefer it to AT90S4433. It's just the natural course of development and maturity. (like I'd prefer to be typing this on a multi GigaHertz core 2 Duo than a 4.77MHz 8088!)

Cliff

PS That isn't to say that there's aren't some jobs for which the most lowly of Tiny's are still the obvious choice!

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

Thanks for the info Cliff. I was only going by the info presented in the chart Dean gave a link for so was not aware of DMA etc.

It'll be interesting to see what the pricing and power consumption are like for these devices. Things are getting very competitive in the high-end 8-bit/low-end 32-bit category so they're going to have to fight their corner!

Matt.

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

With rumors of being able to directly address 16 MB external SRAM and/or SDRAM in the previously linked PDF (http://www.changnamint.com/board...), I suppose at the very least there'd have to be an addition to the instruction set.

(Maybe an Extended LD family of instructions in conjunction with RAMPZ, as well as the RAMPX, RAMPY, and RAMPD registers that have been mentioned in the official instruction set for quite some time but never actually implemented thus far, in the same vein as the ELPM instruction that was added to support the >64 kB Flash parts.)

It seems to me that IAR's AVR-related documentation has advertised "far" and "huge" memory models that are intended to be able to access a 16 MB data address space for quite some time.
http://supp.iar.com/FilesPublic/...

It'd be very interesting to see how avr-gcc would adapt itself to that sort of development, since it's currently tied to a single, 16-bit data addressing mode.

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

lfmorrison wrote:
It'd be very interesting to see how avr-gcc would adapt itself to that sort of development, since it's currently tied to a single, 16-bit data addressing mode.
One of the avr-gcc developers thought that to support beyond 16-bit addressing avr-gcc would need to expand to a 32-bit addressing, bypassing 24-bit as well as not supporting a mixed memory model like IAR. My suspicion is the initial avr-gcc support will use a library function to access memory beyond 16-bits and will still be a 16-bit pointer compiler.

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

Wonder is 24 bits would be enough anyway? (he asked knowingly).

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

Forget 24-bit pointers, I'd sell my soul for (amongst a pile of other things including a never-ending chocolate bar) 24-bit integer support. Using 32-bits when 24 would do is so inefficient!

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Xmegas are going to be announced in the next couple weeks according to our local FAE here in South Florida. Took Atmel a while to get them out, but worth the wait to get DMA, event support, 384K flash, and 32Mhz clock.

OTOH, the AVR32 B series of mc's is also quite nice, and would seem to have otherwise overtaken the field that the Xmegas were supposed to fill.

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

Not sure how you consider an overlap between AVR32 and X-AVR8 ? They are quite different devices with quite different purposes. It's like saying an ARM overlaps any form of AVR8 - it doesn't.

(BTW I think your rumour may be just slightly optimisitic - but there is an intersting thing somewhere on the atmel.com web site ;) )

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

Quote:

but there is an intersting thing somewhere on the atmel.com web site

Hmmm--Google hasn't picked it up yet.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Lee,

I (think!) you have PM (the system froze after [submit] so I'm not entirely sure it went)

Cliff

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

In few weekss, in our company would have a meeting to discuss if it's worth a try to include ARM's int our new 'big' products, and what other choices would be there. Right now, only XMega and new Cypress PSoC (with ARM cores) would be the best chances. Anyway, it seems that an RTOS would be a 'must have', for faster developing, including, possibly TCP/IP and/or USB support. Probably XMega will loose by the delay.

BTW, our Atmel representative told us they don't think any XMega would be released soon.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Quote:
Xmegas are going to be announced in the next couple weeks according to our local FAE here in South Florida

Quote:
BTW, our Atmel representative told us they don't think any XMega would be released soon.

LOL, that doesn't exactly instill confidence does it :-) or maybe it is just the difference in perseption of what "soon" is :-)

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

Well, probably is not the same USA than Spain. Potential marked is greater on the first, maybe they are more interested to sell the first batches only there, and left the others for when they reach full production, huh?

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

I'm REALLY curious to see the pricing. And not the PR flack "less than a few $$$ in 1.2 billion quantities"--the price to buy 100 or a flat from a distributor. Looking over the feature list again, an A4 16k/32k would compete with, say, Mega164/324. With all the fancy features, would it cost about twice as much? But that would be a killer as well, as Atmel's own AT91SAM7S32 has a lot of the features, and is $4.32/100; Mega324 is $3.98/100. So can it really be an $8 chip and still be attractive? Stay tuned...hold your breath for yet another year. lol

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Its an advantage to Atmel to have an ARM Eater right? If you have better features and less price, the only negative is second source availability, but that doesnt happen till something is a 'commodity'

Imagecraft compiler user

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

Quote:
But that would be a killer as well, as Atmel's own AT91SAM7S32 has a lot of the features, and is $4.32/100;

I totally agree. These things are going to need to be damn cheap otherwise there just isn't going to be a market for them. There are so many ARM chips around now offering at least the same kind of features as the current top AVRs, often at lower cost.

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

Doesn't it take an AVR32 to be an "ARM Eater"? Or, are you implying the XMega will have a sufficient increment in capabilities that it infringe on some 32-bit or 16-bit ARM7 Thumb applications?

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

No, what I'm speculating about is that if it os priced much more than the SAM7S it won't have much attraction.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I see, Lee, that makes sense. The integrated DAC might save cost on an additional component for some applications, but of course only benefits those applications that depend on that additional component.

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

Well I heard that devices of similar flash size are likley to be priced at similar levels to existings devices of the same size. Although there may be more "goodies' on board this is offset by the fact that they are probably fabbed on a smaller process so the actualy silicon cost is the same or less.

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

Way cool! [downside: it is kind of a general rule that the smaller the geometry/feature size/power consumption, the less "robust" w.r.t. noise and other disturbances. cross your fingers.]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

In my email today, from Atmel re "Embedded World Nurnberg 2008":

Quote:
... meet with an expert technologist to learn what's new in Atmel's microcontroller offering and be the first to see Atmel's newest, innovative MCU family.
...
What You Will See

Product demonstrations exhibiting the latest technologies and capabilities found in:
8-bit Microcontrollers
A New Member of the AVR® Family
At EW2008, Atmel will unveil a major extension of the AVR 8-bit microcontroller proprietary architecture. This new family will extend the reach to 8/16-bit applications with significant architectural enhancements and best-in-class low power consumption characteristics.

Any day now...

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

That was I was going to say:)

Caleb

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

Whoohoo! 2 weeks away :smile:

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

clawson wrote:
Not sure how you consider an overlap between AVR32 and X-AVR8 ? They are quite different devices with quite different purposes. It's like saying an ARM overlaps any form of AVR8 - it doesn't.

(BTW I think your rumour may be just slightly optimisitic - but there is an intersting thing somewhere on the atmel.com web site ;) )


Ah ha - all is revealed - so the "interesting thing somewhere on the atmel.com" site was merely:

http://www.atmel.com/corporate/c...

(my spies had told me there'd "be an annoucement in February" - of course that will always mean the last few days, not the first few days!)

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

Quote:
my spies had told me there'd "be an annoucement in February"

My spies must be better than yours since they told me exactly when and where ;)

Quote:
Whoohoo! 2 weeks away

Don't get too excited. This is for the announcement. I would bet that the chip availability won't be for a few more months.

Regards,
Steve A.

The Board helps those that help themselves.

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

Ah well, my spies told me that some selected people already had samples - or by "availability" did you mean with the distis?

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

clawson wrote:
"be an annoucement in February" - of course that will always mean the last few days, not the first few days!)
Yep, just like "before the end of the year" almost always means between Christmas and New Year's Eve.

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

My spies tell me Atmel has WMD, but I'm not buying it.

Smiley

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

Quote:
My spies tell me Atmel has WMD, but I'm not buying it
HOWEVER, just to be on the safe side, send in 100k troops...you never know. :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

smileymicros wrote:
My spies tell me Atmel has WMD
Wares for Mass Distribution -- they just might have them! :wink:

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

Today?!?

A site search at atmel.com uncovers several hits tonight...

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

It is a probability that it will be relased today, since the embedded world conference starts today, and there many companies releases their new stuff!

Hope so :)

EDIT!!

The XMEGA and STK600 specs are now available av the atmel.com website :) :) :)

So can't be long until we can order it.

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

What's with STK500 Mk2? Anyone knows anything about it?....or do you want me to do a search...?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

STK500 Mk2 ? Hmm never heard of it..

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

Some of the xml part description files have STK500_2 as well as STK500 in the module list :roll:

Quote:
[SIMULATOR:ICE50:STK500:STK500_2:AVRISPmkII:AVRDragon:STK600]

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

hmm... did a quick search on atmel and google, but didn't get anything.

Could be an alternative to the stk600 ?

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

Don't know! Anyway all of my hopes of just dropping in an A3 into one of my CONT3 modules have vanished as the pinout is different than the M64/M128 :(

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

PLL up to 31x. Does this mean 31*32MHz?
Wow thats ultra fast PWM. :P

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

Quote:
PLL up to 31x. Does this mean 31*32MHz?
Wow thats ultra fast PWM.

Oh yes :) Soooo looking forward to it can be ordered:)

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

js wrote:

> Some of the xml part description files have STK500_2 as well as STK500 in the module list

That's the version 2 firmware of the STK500, which is now already
quite dated.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

:oops: I thought it could have been a STK500 with a Dragon front end...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Well, I've just been reading the datasheets, and I'm disappointed. The XMEGAs look great, but I was hoping to be able to use the DMA facility to capture a stream of parallel data at around 5MB/s, clocked by an external signal. There doesn't seem to be any such facility. Oh well... Just have to wait for the XGIGAs to be announced...

Quebracho seems to be the hardest wood.

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

Quote:
Well, I've just been reading the datasheets, and I'm disappointed.

...Always someone who must complain ... :D

But I guess that is what forces the development for next generation beyond next generation..

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

Oh no! More rabbits!

Quebracho seems to be the hardest wood.

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

Xgiga, nice one :lol:

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

John_A_Brown wrote:
Well, I've just been reading the datasheets, and I'm disappointed. The XMEGAs look great, but I was hoping to be able to use the DMA facility to capture a stream of parallel data at around 5MB/s, clocked by an external signal.

If you can work with serial data: in theory rev. H. AT32UC3 micros should clock almost 8 Mbytes/sec over SPI. Less wiring, too. My engineering sample puts out measly 3.75 Mbytes/sec.

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

Where's the "Trade your soul for one of them" form? I can't find the link :-(

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

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

One thing that:

http://www.atmel.com/products/AV...

doesn't give, of course, is any idea of availability. I don't know if it's common knowledge or not but I'll risk it anyway - I was told the the two initial devices would be the 64A1 and the 128A1 but I don't know when and I don't know how far behind the others will lag or whether they're actually planning to get them all available at the same time after all?

Cliff

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

Quote:
doesn't give, of course, is any idea of availability.

It does say "100% predictable timing", however, if that gives you any clues...

Quebracho seems to be the hardest wood.

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

I was told that they would be released soon, where soon means anything between yesterday and next century. Most probably, ready for mass production by the end of the year (which one, is unknown) the first two models (IIRC, atmel respresentative told me about the same models that Cliff mentions).

Anyway, not big difference between dec-31 and jan-01. I would be out of the office both days. ;)

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Next decade is going to be very interesting !!!

Atmel is making the right moves !

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

Quote:

John_A_Brown wrote:
Well, I've just been reading the datasheets, and I'm disappointed. The XMEGAs look great, but I was hoping to be able to use the DMA facility to capture a stream of parallel data at around 5MB/s, clocked by an external signal.

If you can work with serial data: in theory rev. H. AT32UC3 micros should clock almost 8 Mbytes/sec over SPI. Less wiring, too. My engineering sample puts out measly 3.75 Mbytes/sec.


I'm kind of with John on this one. I thought from reading the earlier "leaked" documents that streaming from a port was included. But maybe I was thinking of SAM7.

The most obvious application that I can think of is "logic analyzer", or a "'scope" faster than the on-board A/D.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
Quote:

John_A_Brown wrote:
Well, I've just been reading the datasheets, and I'm disappointed. The XMEGAs look great, but I was hoping to be able to use the DMA facility to capture a stream of parallel data at around 5MB/s, clocked by an external signal.

If you can work with serial data: in theory rev. H. AT32UC3 micros should clock almost 8 Mbytes/sec over SPI. Less wiring, too. My engineering sample puts out measly 3.75 Mbytes/sec.


I'm kind of with John on this one. I thought from reading the earlier "leaked" documents that streaming from a port was included. But maybe I was thinking of SAM7.

The most obvious application that I can think of is "logic analyzer", or a "'scope" faster than the on-board A/D.

Lee


FWIW, I was hoping to be able to grab a few DVB packets, and analyze them at leisure for progamme identification. However, I think the DMA in conjunction with the ADC could interest me.

Quebracho seems to be the hardest wood.

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

John_A_Brown wrote:
Well, I've just been reading the datasheets, and I'm disappointed. The XMEGAs look great, but I was hoping to be able to use the DMA facility to capture a stream of parallel data at around 5MB/s, clocked by an external signal. There doesn't seem to be any such facility. Oh well... Just have to wait for the XGIGAs to be announced...

I believe this is possible by mapping "parallel data" to external memory and by using the new event system.

From the datasheet:

Quote:
"The XMEGA Direct Memory Access (DMA)Controller is a highly flexible DMA Controller capable
of transferring data between memories and peripherals with minimal CPU intervention. The DMA controller has flexible channel priority selection, several addressing modes, double buffering capabilities and large block sizes.

The DMA Controller can move data between memories and peripherals, between memories and between peripherals.

There are four DMA channels that have individual source, destination, triggers and block sizes. The different channels also have individual control settings and individual interrupt settings and interrupt vectors. Interrupt requests may be generated both when a transaction is complete or if the DMA Controller detects an error on a DMA channel. When a DMA channel requests a data transfer, the bus arbiter will wait until the AVR core is not using the data bus and permit the DMA Controller to transfer data. Transfers are done in bursts of 1, 2, 4 or 8 bytes. Addressing can be static, incremental or decremental. Automatic reload of source and/or destination address can be done after each burst transfer, block transfer, when transmission is complete, or disabled.

Both application software, peripherals and Events can trigger DMA transfers."

Last Edited: Tue. Feb 26, 2008 - 05:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I saw that, but, looking at the DMA trigger information, I was unable to see how a strobe from an external device could be used in the DMA system. I'll look into it further.

Quebracho seems to be the hardest wood.

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

John_A_Brown wrote:
I was hoping to be able to grab a few DVB packets, and analyze them at leisure for progamme identification.

Just being nosey - DVB-T, DVB-S or something else?

(it's just that in the main DVB-S source in the UK 184 of every 188 byte TS packet is scrambled anyway - so all you can identify are the PIDs)

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

Regarding availability for samples, let's just say REAL SOON, and no, we're not talking end of the year. Very probably single digit weeks. ;) But that's not official.

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

Thanks for the update, Erik. I expect STK600's will be available by then to assist in development as well.

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

Well...I am pleased with the XMega. I was sort of hoping for a drop in replacement for the ATmega128...but I will be purchasing an Eval board as soon as they come out. It looks like it will be a lot of fun to write code for these.

-Jim

-Jim
http://www.noniandjim.com
Analog and Digital Electronics
Music Synthesizers

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

patchell wrote:
Well...I am pleased with the XMega. I was sort of hoping for a drop in replacement for the ATmega128.

No, they're definitely not a drop-in replacement for the ATmega128.

However, you may be interested in the upcoming ATmega1284P. I don't know the pin-out for this chip, but think mega128, with 128K Flash, 16K RAM, 4K EEPROM and PicoPower.

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

EW wrote:
Regarding availability for samples, let's just say REAL SOON, and no, we're not talking end of the year. Very probably single digit weeks. ;) But that's not official.

What base are we talking about here? Base 10 or mayber base 32?

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

Quote:
Well, I've just been reading the datasheets, and I'm disappointed. The XMEGAs look great, but I was hoping to be able to use the DMA facility to capture a stream of parallel data at around 5MB/s, clocked by an external signal. There doesn't seem to be any such facility.

Well, I've been giving the xxA3 data sheet a quick read. There may be hope.

See page 11: Since the DMA can access all the peripherals through the I/O memory...

See page 12: Events can be generated by.... ports.... Events can be used by .... DMA controller

So, I'm obviously reading between the lines here, but I think with further digging we may find a way to set up the port to generate, say, a pin change event, route that event to the DMA controller as an event trigger, and have the DMA controller take input data from the I/O port.

Anyway, that's my quota of "engineering by wishful thinking" for this morning, so I had better stop now.

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

EW wrote:
Regarding availability for samples, let's just say REAL SOON, and no, we're not talking end of the year. Very probably single digit weeks. ;) But that's not official.

Sorry, EW, here we go again... [and I'm tweaking you, not criticizing.]

Quote:
Availability and Pricing.
The first devices, ATxmega128A1 and ATxmega64A1 are both offered in 100-pin TQFP and BGA packages and are available now.

What part of "available now" am I having trouble understanding? I seem to repeatedly have problems with that term, especially when related to Atmel product announcements. Does that mean "Several of our 1M unit customers plus tool developers got a few of the first small engineering batch of working chips. Thus, for them, it is indeed 'available now'."

To me, "available now" means that ordinary people like myself can place an order at the disti and/or the rep, and at least get in line with my order of specific part numbers even if delivery is a ways off.

Sigh.

Still slathering to see the instruction set and a few other holes in the datasheet. Price looks OK though if those 10k prices hold: in the past, quotes for 10k of AVRs was about 50% to 60% of qty. 100 prices. Perhaps some of you volume customers can extrapolate the percentages for us.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Wow, many wishes came true since Troubling started the thread The dream microcontroller!. Unfortunately the XMEGA still can't make coffee and wash the dishes. However, I think I can live with these restrictions.

Regards
Sebastian

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

Actually I'd have thought things like coffee machines and dishwashers were perfect applications for them. :lol:

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

Quote:
Where's the "Trade your soul for one of them" form?
Well, if you trade in your soul then you'll be DEAD. So the XMEGA will not be much use to you in the coffin...unless you can bring your laptop and STK600 along... :lol:

But what will you do for power once the batteries go? I guess some methane to electricity converter could do the job for a while....

Quote:
But maybe I was thinking of SAM7.
Weren't you looking at "Son of SAM7"? :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

So - what about the XMEGA is 16b? To me, looking through the documentation, it seems to be very much an 8b family.

It is a pity that there are no CAN XMEGAs, or any smaller than 44 pins. I would really love to see a "ATXMEGACAN168". That would solve a lot of problems for me.

Lastly, is there GCC support for the XMEGAs? I couldn't find anything on the WinAVR sourceforge page about a new release... And the Atmel XMEGA site seems to only talk about IAR.

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

Looks like the Xmega is going to be nice. However it seems there are still those that need a few more ob board features. I see up to 8 USART's but no USB. To compare the Xmega with the AVR32's, I wish that the AVR32 had the A/D's of the xmega but 14bit A/D:) That would be my chip of choice!

It will be fun to do a project sometime with the new Xmega!

Also what compiler support will there be. It seems GCC would not be hard to update to suport the Xmega's. Also I am wondering if Imagecraft and Codevision will be supporting the Xmega's soon.

Cheers,
Caleb

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

Quote:

So - what about the XMEGA is 16b? To me, looking through the documentation, it seems to be very much an 8b family.

LOL I just came here to post this from the product announcement
Quote:
Modern CPU Built for Scalability – The 8/16-bit AVR CPU is designed for high-level languages like C. It has 16- and 32-bit arithmetic support and 16- and 24-bit memory pointers.

I was really expecting (when looking at the leaked documents a while back) to find a few enhanced instructions like MAC and/or MULW. I also noted with interest the "8/16" in the announcement and poked at the documents. I can't find anything, besides the expansion to handle the bigger memory spaces. Not really an "enhancement" to me; more like the necessary infrastructure so the extra memory space isn't wasted.

Quote:

It is a pity that there are no CAN XMEGAs, or any smaller than 44 pins. I would really love to see a "ATXMEGACAN168". That would solve a lot of problems for me.

Not having small CAN (on classic and X) seems to be a drawback for me as well, for CAN "sensors" that only need limited pins. And it sure would be nice to have the X features in a Mega48-class. But if they really do come through on the pricing the 44-pin A3/A4 wouldn't be too bad.

Quote:

Lastly, is there GCC support for the XMEGAs? I couldn't find anything on the WinAVR sourceforge page about a new release... And the Atmel XMEGA site seems to only talk about IAR.

I ASS-U-ME that now that the official product announcement is made, we'll be hearing from our compiler vendors that have been under a shroud of secrecy. Betcha a cold one that Pavel & Richard have been poking at them for quite a while, and that "support" will be there when we can get one into our sweaty palms.

But consider: What do they need to change to get going? The Instruction Set info is quite scarce, but considering that the 64k instruction space is nearly full already, there won't be many--any?--changes of substance. That's what a compiler mostly does, anyway: produces the "best" stream of machine instructions to carry out a task. All the rest of the stuff is in the I/O space and how to configure and use the peripherals. But that is just more INs and OUTs and LDS & STS which they already do.

I came across an interesting bit that I've got to dig into further--"locked" I/O configuration, unchangeable by code. Then do we get a way to >>ISP<< the I/O registers, kind of like fuses? Gotta dig further.

But I think you can agree that a compiler should be able to generate code--it is just an AVR [instruction set] in different clothing.

Can't wait. Slathering. Ordered samples from the Atmel Web site today. After all, the announcement said "available now", so I'm getting into line. Lessee--function generator. Add graphic LCD, and logic analyzer up to classic AVR speeds depending on DMA speed. Digital 'scope up to a Msps or maybe a bit more. Streaming audio, but I didn't see any mention of I2S as is in SAM7S. One of my industrial apps that is tapped out at 20MHz. Add FFT to that digital 'scope? ... [add your favourite dream here]

Power consumption: the new V & P chips can get plenty low, so not a biggie for me.

Drawback: No 5V operation, but kinda passe nowadays anyway.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. Feb 27, 2008 - 03:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nleahcim wrote:
So - what about the XMEGA is 16b? To me, looking through the documentation, it seems to be very much an 8b family.

I was just wondering the exact same thing. The data sheet says:
Quote:
XMEGA uses the 8/16-bit AVR RISC core
But I haven't found anything 16 bit yet beyond what the older AVRs have.

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

austca wrote:
Looks like the Xmega is going to be nice. However it seems there are still those that need a few more ob board features. I see up to 8 USART's but no USB. To compare the Xmega with the AVR32's, I wish that the AVR32 had the A/D's of the xmega but 14bit A/D:) That would be my chip of choice!

It will be fun to do a project sometime with the new Xmega!

Also what compiler support will there be. It seems GCC would not be hard to update to suport the Xmega's. Also I am wondering if Imagecraft and Codevision will be supporting the Xmega's soon.

Cheers,
Caleb

IAR is traditionally the first compiler with support, but the other compilers are sure to follow in short order.

As for other features, I think you can be fairly confidant that on-board features like CAN and USB will be in the future. The "basic" general purpose models are always the first out the door, the more specialized versions come later.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Quote:

but 14bit A/D

Caleb, Caleb, Caleb--Didn't you read what Uncle Atmel said in the product announcement, in front of God and everyone, nearby to "available now":

Quote:
hardware support for oversampling to increase resolution to 16 bits without extra cost.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
Quote:

Check out slide 13 too.

Where 76% would consider a PIC for their next design, and 32% an AVR?

I think Flylogic.net/blog put the nail in the PIC MCU market honestly.

None of the PICs are secure against "light" attacks.!@!@!@!@!

Want to secure your hardwork? Stay away from Microchip!

Regards

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

The AES/DES hardware crypto instructions are nice welcome too.

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

Yes, Now add a little PKI functionality and people will swarm to the OTS AVR's instead of smartcards.

One final feature they could add immediately is to allow switching between internal clock oscillator and external world via a register setting :).

Regards

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

That is the impression I get actually, that one can move between clock sources on the fly. (at least from a first glance that's how it appears to me)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

No fricken #$#@??? WOW!!!

Okay Flylogic, tear one down PLEASE!

Regards

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

Quote:
one can move between clock sources on the fly.
A high tech house fly!! What will they think of next.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Are you sure you all have any workbench area left to drop a new STK-600 starter kit on :roll: . I took a quick look at the details on the ATMEL site, the only thing I don't like (and like at the same time) is the Seperate Package boards for each package type. I'm hoping the darn thing ships with one or two types so it's a quick startup.

Now is this really supporting all AVR products, and should I therefore place my beaten up 500 on a shelf for future generations to use?

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

Quote:
Are you sure you all have any workbench area left to drop a new STK-600 starter kit on
YEP, I'm getting rid of the Motorola EVM shortly which takes about 4 times the space of a STK600 :) (it's been sitting on my bench for about 16 years :? )

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
(it's been sitting on my bench for about 16 years Confused )

WOw, it took you 16! years to get rid of Motorola, wonder how long it will take to get rid of Atmel xmegas???

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

glitch wrote:
IAR is traditionally the first compiler with support, but the other compilers are sure to follow in short order.

The men from Atmel told me that all the major AVR C compiler writers would have X support pretty much from day one.

For example, I'm assuming Eric/Joerg may have a new avr-libc/WinAVR in the offing fairly shortly?

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

I've been reading the XMega-A manual, and it looks like one of the agendas with this series was to uplevel the quality of the peripherals by a big chunk. Seems like every module is improved over the regular Mega series, and they're specified to avoid the need to have each new chip create gratuitous register-level incompatibilities.

For example, look at the I/O port design. It's got totem pole drive, pullup, pulldown, wire-or, wire-and, and bus-keeper modes. Slew rate control. (Which makes the I2C module handle SMBus a lot better...) More IRQ triggering options; you don't need an external interrupt pin to get active-low triggering, and there are more single edge trigger options too. None of that dodgey side effect dance to trigger pullups.

So the XMega driver codebase is going to be a lot different from the current stuff, but it'll be a lot easier to make it do the right sort of things. Compatibility between chip versions will be better, and so will interoperation with other systems. Even if XMega just means "same old instruction set but all-new peripherals", it's looking to be very nice...

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

rocketman49 wrote:
Are you sure you all have any workbench area left to drop a new STK-600 starter kit on :roll: . I took a quick look at the details on the ATMEL site, the only thing I don't like (and like at the same time) is the Seperate Package boards for each package type. I'm hoping the darn thing ships with one or two types so it's a quick startup.

Now is this really supporting all AVR products, and should I therefore place my beaten up 500 on a shelf for future generations to use?


While the STK500 had something like 10 DIP sockets to accomodate all the DIP packaged AVRs the STK600 requires just one socket for all of them (though you have to put the right "routing card" for the selected device in the middle of the "sandwich" but it's actually a much neater system than the STK500 I think.

The same system allows sockets for other package types to also be added easily (so no more needing boards like STK501)

With the right carriers is supports all the AVR8s, the Xmegas (I obviously didn't get a chance to try that) and the AVR32 UC3 models.

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

theusch wrote:

Quote:
Availability and Pricing.
The first devices, ATxmega128A1 and ATxmega64A1 are both offered in 100-pin TQFP and BGA packages and are available now.

What part of "available now" am I having trouble understanding? I seem to repeatedly have problems with that term, especially when related to Atmel product announcements. Does that mean "Several of our 1M unit customers plus tool developers got a few of the first small engineering batch of working chips. Thus, for them, it is indeed 'available now'."

To me, "available now" means that ordinary people like myself can place an order at the disti and/or the rep, and at least get in line with my order of specific part numbers even if delivery is a ways off.

Well, Lee, have you actually tried to order samples? What did your disti/rep say? ;)

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

nleahcim wrote:

It is a pity that there are no CAN XMEGAs, or any smaller than 44 pins. I would really love to see a "ATXMEGACAN168". That would solve a lot of problems for me.

These are just the first parts out. XMEGA is whole family of parts.

nleahcim wrote:

Lastly, is there GCC support for the XMEGAs? I couldn't find anything on the WinAVR sourceforge page about a new release...

I have mentioned before in different posts on these forums, about an upcoming WinAVR release in Februrary. I've moved that back slightly to the middle of March.

The reason for the release is preliminary support of the XMEGA. :) I haven't been able to officially talk about this until the product was officially announced.

nleahcim wrote:

And the Atmel XMEGA site seems to only talk about IAR.

Maybe I'm just missing it, but where does it say this?

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

Hmmmmmmm

Very nice especially the pico power side of it.
The 12 bits ADC & DAC is very welcome.

Ken

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

Quote:

Well, Lee, have you actually tried to order samples? What did your disti/rep say?

Way ahead of you, EW--read down to:
Quote:
Can't wait. Slathering. Ordered samples from the Atmel Web site today. After all, the announcement said "available now", so I'm getting into line.
;) So "we'll see" after the wheels churn.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
However, you may be interested in the upcoming ATmega1284P. I don't know the pin-out for this chip, but think mega128, with 128K Flash, 16K RAM, 4K EEPROM and PicoPower.

Judging by the pinout in the RZRaven hardware user's guide, this is nothing more than a doubled Mega644, as the part number would indicate. If it is in DIP the robot people will love it with the bigger SRAM and flash. But not much use as a '128 drop-in. ;)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:

Quote:

It is a pity that there are no CAN XMEGAs, or any smaller than 44 pins. I would really love to see a "ATXMEGACAN168". That would solve a lot of problems for me.

Not having small CAN (on classic and X) seems to be a drawback for me as well, for CAN "sensors" that only need limited pins. And it sure would be nice to have the X features in a Mega48-class. But if they really do come through on the pricing the 44-pin A3/A4 wouldn't be too bad.

It is funny to me that last I checked, the cheapest way to get a CAN connected MCU was to get a very basic MCU and attach it to a Microchip MCP2515. This just seems to me to be a massive hole that Atmel could easily fill. There is also a huge hole in the market for physically small CAN connected MCUs. Last I checked the best out there was either the AT90CAN128 in a 9x9mm QFN package or a Renesas R8C/23 in a 9x9mm LQFP package (I would consider the Renesas part to be smaller as QFNs require essentially all traces to go out away from the center of the part). Too bad it's a Renesas part and I have very little interest in learning yet another new family of parts.

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

EW wrote:
nleahcim wrote:

It is a pity that there are no CAN XMEGAs, or any smaller than 44 pins. I would really love to see a "ATXMEGACAN168". That would solve a lot of problems for me.

These are just the first parts out. XMEGA is whole family of parts.


So are there any plans for anything like what I'm talking about? I've been asking for years for an AT90CAN168 and still haven't seen it - so I guess I'm not keeping my hopes up anymore...
Quote:

nleahcim wrote:

Lastly, is there GCC support for the XMEGAs? I couldn't find anything on the WinAVR sourceforge page about a new release...

I have mentioned before in different posts on these forums, about an upcoming WinAVR release in Februrary. I've moved that back slightly to the middle of March.

The reason for the release is preliminary support of the XMEGA. :) I haven't been able to officially talk about this until the product was officially announced.

nleahcim wrote:

And the Atmel XMEGA site seems to only talk about IAR.

Maybe I'm just missing it, but where does it say this?


Glad to hear about the upcoming release! IAR is talked about, albeit briefly, in AVR1000

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

Digging around in the docs, it appears that STK500 and ATAVRISP2 and similar "serial ISP" tools are dead for the Xmega. So if I get one into my sweaty palm, is it JTAGICE2? STK600? a tool similar to ATAVRISP2?

Drilling down on the devices to ATxmega64A1 http://www.atmel.com/dyn/product... it DOES list the ATAVRISP2 and JTAGICE2 along with STK600 and 'Studio4. Must be a different MkII firmware, then, eh?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

They could have replaced some of the SPI's with other stuff, like CAN , ETH etc. then the chip would have been great :)

But still a pretty nice chip, looking forward to testing it.

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

Quote:

So are there any plans for anything like what I'm talking about? I've been asking for years for an AT90CAN168 and still haven't seen it - so I guess I'm not keeping my hopes up anymore...

Our wish has come true (but not on Xmega yet): CAN in a 32-pin package, plus other toyz: http://www.avrfreaks.net/index.p...

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

nleahcim wrote:
This just seems to me to be a massive hole that Atmel could easily fill. There is also a huge hole in the market for physically small CAN connected MCUs. Last I checked the best out there was either the AT90CAN128 ...

You might be interested in the ATmega32C1 then. (QFN32)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Quote:
Bit 4:0 - PLLFAC[4:0]: Multiplication Factor
The PLLFAC bits set the multiplication factor for the PLL. The multiplication factor can be in the
range from 1x to 31x. The output frequency from the PLL should not exceed 200 MHz. The PLL
must have a minimum output frequency of 10 MHz.

200MHz/4096 = 48.8kHz?

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

RES wrote:
Quote:
Bit 4:0 - PLLFAC[4:0]: Multiplication Factor
The PLLFAC bits set the multiplication factor for the PLL. The multiplication factor can be in the
range from 1x to 31x. The output frequency from the PLL should not exceed 200 MHz. The PLL
must have a minimum output frequency of 10 MHz.

200MHz/4096 = 48.8kHz?

where did the 4096 come from? I'm not even sure what it is you're trying to say/ask

The minimum input clock is 440KHz (as stated in the documentation) The maximum input clock (to the PLL), if you back calculate from the max multiplier of 31, is 6.45MHz

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

An ATtiny861 has a PLL can run @ 32MHz max., and 10-bit PWM, makes 31.25kHz samplerate, right? :?

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

theusch wrote:

I came across an interesting bit that I've got to dig into further--"locked" I/O configuration, unchangeable by code. Then do we get a way to >>ISP<< the I/O registers, kind of like fuses? Gotta dig further.

No, the I/O is still set by software. But you have a lock bit that is programmable by software, once set, the I/O configuration cannot change. The only way to clear the lock bit would be a reset. The idea is so you can set up your I/O and then protect it from accidental changes later in execution.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

RES wrote:
An ATtiny861 has a PLL can run @ 32MHz max., and 10-bit PWM, makes 31.25kHz samplerate, right? :?

Well nothing on the xmega can actually run at 200MHz. The fastest subsystem clock is at 4x the CPU clock (which has a maximum of 32MHz). However, the timers appear to work off of the periperal clock, which is the same as the CPU clock. Thus your timer is limited to 32MHz operation. (I haven't seen any "high speed" 2x or 4x peripherals yet... though I haven't looked that hard)

[edit]
A quick search of the PDF for "PER2" and "PER4" shows that they only show up in the clock section, and in a block diagram. So it looks like these clocks are currently not used. (though some functions are described in other documents, so they may pop up there) [my guess is that the external bus interface would be a good candidate for the faster clock, though it is not mentioned there]

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

John_A_Brown wrote:
I saw that, but, looking at the DMA trigger information, I was unable to see how a strobe from an external device could be used in the DMA system. I'll look into it further.

John--as far as I can tell streaming to/from an I/O port should be a standard DMA function. Look in the datasheets (actually the A family doc) at the SRCADDR and DESTADDR registers, a 24-bit pointer into the universal address space. PORTn (PINn?) is just one of those addresses. [An interesting very small side note probably insignificant: I don't see a spot in the universal address space for R0-R31, which used to be SRAM address 0. Rarely used it myself, though the compiler did sometimes when a pointer to a register variable was needed.]

Anyway, see the DMA app note AVR1304 http://www.atmel.com/dyn/resourc...
which should have almost the right example in the source code. "Almost" 'cause it is from SRAM streaming to a port. Ignore the interesting cut/paste typo

Quote:
2 Module Overview
This section provides an overview of the basic configuration options and functionality of the DAC. Section 3 then walks you through the basic steps to get up and running, with register descriptions and configuration details.
2.1 DMA Channels
In addition to ...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

MMMmmm, the ATxmega64A4 looks delicious, I'll definately be looking to get one when it comes out to replace my ATmega644 in my project... so many new things I can do....

Edward

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

Pity it is not pin compatible with other chips :(

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

By the way, I don't think anyone has noted it so far in this thread but did anyone spot the accuracy on the internal oscillator? When Atmel presented the devices to me this is one of the things I thought looked particularly attractive if it meant reliable, crystaless, UART comms (probably accounts for about 5-10% of Freaks traffic!!)

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

Quote:
one of the things I thought looked particularly attractive if it meant reliable, crystaless, UART comms (probably accounts for about 5-10% of Freaks traffic!!)
since no dip packages (yet? ever? never?), I doubt you will see the 'dip'(2 meanings) freaks user using these things, except on pre-made boards that will most likely include a crystal. So the usart traffic count will remain as high as always (I'm a 'dip' user, both meanings). But, looking at the datasheet, I think your FAQ signature will become quite large, and you may have to give the xmega a section of its own.

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

Quote:
Too bad it's a Renesas part and I have very little interest in learning yet another new family of parts.

I like the Renesas series of micros. I haven't used the R8C series, but some of the M16C series seems like it would be comparable to the Xmega. Most of my recent projects have either used Atmel AVR or Renesas M16C or in some cases a combination of both.

One thing that is for sure is that the AVR Freaks forums are much better than the Renesas Rulz forums.

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

While the preliminary XMEGA datasheet doesn't list the accuracy of the internal oscillators, application note AVR1003 ( http://www.atmel.com/dyn/resourc... ) shows the high speed internal oscillators have a factory accuracy of 1% (rather than the typical 10% of AVRs). That's very good news to people who use an external crystal just to have acceptable UART communications at near room temperature. Thanks, Atmel!

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

I still have to find time to dig into it's datasheets (I'm about to release a new AVR based product to the market...), but for shure 1% for the internal oscilator is really welcome for us. Anyway, our systems always use 32KHz crystal for RTC, thus we systematically calibrate the internal oscilator for serial comms.

But that doesn't mean that this feature is not welcomed.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

kevin123 wrote:
Quote:
Too bad it's a Renesas part and I have very little interest in learning yet another new family of parts.

I like the Renesas series of micros. I haven't used the R8C series, but some of the M16C series seems like it would be comparable to the Xmega. Most of my recent projects have either used Atmel AVR or Renesas M16C or in some cases a combination of both.

One thing that is for sure is that the AVR Freaks forums are much better than the Renesas Rulz forums.


Do you have any experience with the open source C compiler for Renesas parts? I've looked at it a couple times in the past - and every time it looks like it's not really ready for mainstream... As in, it looks like you still have to compile it yourself (http://people.redhat.com/dj/m32c/) and it still doesn't even support all the part's opcodes (http://people.redhat.com/dj/m32c...)

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

curtvmsince no dip packages (yet? ever? never?), I doubt you will see the 'dip'(2 meanings) freaks user using these things, except on pre-made boards that will most likely include a crystal.[/quote wrote:

Well I don't know about your application but we use about a million AVRs a year and if we can save the $0.10 that an external crystal costs then we just saved $100,000. Sure it's not THAT much, but it's fairly welcome. (and I don't know about other's IQC rates but we maybe find something like 0.1% failure rate on some of the crystals we use - if that causes the whole unit to fail it costs $10's if not $100's in support costs on each failed unit)

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

nleahcim wrote:

Do you have any experience with the open source C compiler for Renesas parts? I've looked at it a couple times in the past - and every time it looks like it's not really ready for mainstream... As in, it looks like you still have to compile it yourself (http://people.redhat.com/dj/m32c/) and it still doesn't even support all the part's opcodes (http://people.redhat.com/dj/m32c...)

You should take this to the Off Topic Forum.... Or another site altogether since this is AVR Freaks.

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

Cliff wrote:

Quote:
Well I don't know about your application but we use about a million AVRs a year and if we can save the $0.10 that an external crystal costs then we just saved $100,000. Sure it's not THAT much, but it's fairly welcome. (and I don't know about other's IQC rates but we maybe find something like 0.1% failure rate on some of the crystals we use - if that causes the whole unit to fail it costs $10's if not $100's in support costs on each failed unit)
The savings will be even more than that: assembly-cost in production will be less as well. Less parts to place, less costs.

Nard :)

A GIF is worth a thousend words   She is called Rosa, lives at Mint17.3 https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Quote:
Anyway, our systems always use 32KHz crystal for RTC, thus we systematically calibrate the internal oscilator for serial comms.

And with the Xmega without software!

Two built-in Digital Frequency Locked Loops (DFLLs) can be used to improve the accuracy of
the 2 MHz and 32 MHz internal oscillators. The DFLL compares the oscillator frequency with a
more accurate reference clock to do automatic run-time calibration of the oscillator. The choices
for the reference clock sources are:
• 32 kHz Calibrated Internal Oscillator.
• 32 kHz Crystal Oscillator connected to the TOSC pin

Look ma, no hands!

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

Let me just say for the record- I'm in favor of accurate internal oscillators.

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

I my company, we had been using many Cypress PSoC without Xtal, and we never had problems with serial comms. 1% straigh from factory, no calibration. No costs.

We quote about 0.03€ to mount any small SMD parts, thus an Xtal that costs us 0.1€, in fact it's about 0.13€ or a little more.

I should definitively find time to read the datasheets. How accurate is internal 32KHz oscillator? I hope is better than the one used at AT91SAM7 families.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Guillem Planisi wrote:
I should definitively find time to read the datasheets. How accurate is internal 32KHz oscillator?.
From AVR1003 I referenced above:
Quote:
The 32.768 kHz internal RC oscillator (RC32K) is factory-calibrated to 32 kHz with an accuracy of 1% at 3V and 25°C. The calibration value is stored in the calibration row and is automatically loaded into the oscillator’s calibration register (RC32KCAL) on reset. This value is read and write accessible for the user

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

OK, I haven't had much caffeine yet this morning, but:

24 hrs/day, 60 min/hr, gives 1440 minutes/day.
1% of 1440 = 14.4, or about 14 minutes per day.

I guess one could individually measure and tweak their systems, but if it really is an RTC, then to me a crystal still makes sense.

JC

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

1% certainly is not good enough for accurate timekeeping... I don't think anyone was suggesting that. It should, however, be good enough for serial communications.

Quote:

Two built-in Digital Frequency Locked Loops (DFLLs) can be used to improve the accuracy of the 2 MHz (1%) and 32 MHz (1%) internal oscillators. The DFLL compares the oscillator frequency with a more accurate reference clock to do automatic run-time calibration of the oscillator.

The choices for the reference clock sources are:
• 32 kHz Calibrated Internal Oscillator. (1%)
• 32 kHz Crystal Oscillator connected to the TOSC pin

I am curious, however, how one could "improve" the accuracy of a 1% accurate clock by using another 1% accurate clock? (all 3 oscillators 32K, 2M, and 32M are factory calibrated within 1% @ 25C / 3V) So I'm thinking that the external 32K crystal is really the only viable "accurate" time source to calibrate against.

[edit] added the accuracies, ane emphasis in the quote

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Last Edited: Thu. Feb 28, 2008 - 05:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Depending on the drift numbers over time, temperature, & Vcc levels of one (or more) of the internal clocks, it may give very satisfactory results to do a one-time cal on the bench against a known signal. For USART comms the xxxCAL steps on classic AVRs are fine enough for this. I/We will have to dig a bit to see if the steps in the CAL register for the 32k are fine enough to give "good" results for timekeeping. My rule of thumb with an uncalibrated DS1305/6 is a minute a month is good enough, and nearly all built boards come within that. Lessee-- 40k minutes/month, so 1 minute is about 25ppm, which is about the spec on many crystals anyway. Without hard numbers, the "average" on a batch is less than half a minute, so maybe 10-20ppm. That's good enough for all my apps for logging and timestamping.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

curtvm wrote:
since no dip packages (yet? ever? never?)

We don't need your stinkin' dip packages...lol

Join the dark side luke... (in a very breathy, puffer medication sort of way). :D The STK600 will help with that won't it?

Last Edited: Fri. Feb 29, 2008 - 06:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please correct me if im wrong:

With the DMA in xmega the cpu will not be
blocked when writing on EEPROM like in the atmega.

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

I though that the CPU was not blocked when writting on EEPROM, unless you are waiting to the 'writing end'. I always thought that this was like ADC conversion: you start peripheral operation, then you can wait until it ends, or do other things until it ends, while polling, or write some ISR that performs certain actions, like starting the next write.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Just a little hint: IAR does support XMegas. Check new 5.1 release at theyr web page.

BTW: Where can I find information about ATmega1284. It seems to be available with certain packs (Raven), but no information on it.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Guillem Planisi wrote:
Just a little hint: IAR does support XMegas. Check new 5.1 release at theyr web page.

BTW: Where can I find information about ATmega1284. It seems to be available with certain packs (Raven), but no information on it.

I also noticed they cover the new ATmega32C1 and ATmega32M1 Automotive AVR's in this release.

  • 1
  • 2
  • 3