Re: X-Mega AVRs are here!

Jim Granville wrote:
David Brown wrote:
Ulf Samuelsson wrote:


Which of course require a new compiler...


No, it would mean a *change* in the compiler. If little-used instructions had to be dropped to leave room in the instruction space for the additional features, then you break backwards compatibility. But that's hardly something new - small breakages occur with changes to the memory maps, the introduction of the 3-byte return stack, and the differences to the eeprom access methods for every new generation of AVR.

Taking advantage of the new instructions would mean a fair number of changes to compilers - but there would be no problem generating correct code.

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.

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.

Perhaps some will now 'morph-over' into AVR32 / LPC51 ?

Seems they never wanted 'not enough uarts' to be a design-miss :)


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




.