Re: X-Mega AVRs are here!
- From: "Ulf Samuelsson" <ulf@xxxxxxxxxxxxx>
- Date: Fri, 29 Feb 2008 11:18:46 +0100
Is the AVR opcode map fully packed ? - just use a spare one ?
They have added opcodes over the years, but DROPPING an opcode is much
more dangerous. (and would be a no-no - "safe superset" is tolerable. )
I believe it is mostly full, but there should be some space left. The
datasheets and application notes do not have a summary ordered by opcode,
so it's not easy to see.
Certainly dropping opcodes is much more involved than adding new ones, and
should only be done if there is a great deal to gain.
The decision was made to not change the CPU core.
Obviously that's the decision - the AVR designers are not daft, and it's
easy to see the advantages that changes like these would have. I
therefore assume they felt improvements to the core would be too
disruptive to the design or the tools.
and keep in mind they have AVR32 (& ARM ) in the stable as well.
So 'creeping featurism' of the core is not going to open new markets,
but just give more overlap with AVR32.
Atmel's microcontrollers already overlap - if this was a worry for them,
then the AVR Mega 256 would not exist, and probably not the XMegas either.
Freescale would REALLY be in trouble...
The sizzle in uC these days is less the core, and more the peripherals
- and from what I've seen of the xmega peripherals they have done a nice
job in advancing the peripheral suite.
Yes, it's the peripherals that make the XMega particularly interesting.
It's also worth noting that doubling the frequency of the core makes more
of a difference than the speed increases that could be gained with
enhancing the cpu.
Actually, for the 3V market, the performance is quadrupled.
Perhaps some will now 'morph-over' into AVR32 / LPC51 ?
Seems they never wanted 'not enough uarts' to be a design-miss :)
No, it is regularity of design, which matters.
Also this simplifies development kits.
If you develop an I/O module on a separate PCB for the digital block,
then you can connect it to any of the digital I/O ports on the chip.
We recently did a design with a AVR Mega that needed a total of 6 uart
channels, so it needed an external UART device. The XMega would have
fitted very nicely here.
They also fixed some of the blindspots, and made it less of a step-back
from a 80C51 ;).
interrupt priority levels are now there, and port toggle is also
possible & I think I saw some means of better SFR mapping too....
(no register bank switching, but perhaps with DMA and Event control,
you have fewer critical interrupts alive anyway... )
-jg
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
.
- References:
- X-Mega AVRs are here!
- From: Ulf Samuelsson
- Re: X-Mega AVRs are here!
- From: linnix
- Re: X-Mega AVRs are here!
- From: John Devereux
- Re: X-Mega AVRs are here!
- From: David Brown
- Re: X-Mega AVRs are here!
- From: Ulf Samuelsson
- Re: X-Mega AVRs are here!
- From: David Brown
- Re: X-Mega AVRs are here!
- From: Jim Granville
- Re: X-Mega AVRs are here!
- From: David Brown
- X-Mega AVRs are here!
- Prev by Date: Re: Strange behavior on Ethernet interface
- Next by Date: Re: X-Mega AVRs are here!
- Previous by thread: Re: X-Mega AVRs are here!
- Next by thread: Re: X-Mega AVRs are here!
- Index(es):