X-Mega AVRs are here!

If you need to cross voltage domains, and drive smallish LCDs, a CPLD can be a good solution. They have separate supplies on IO banks, and you can get them well under 10uA static Icc with 28-32 IO lines. (eg ATF1502BE )

A chip like the xmega could provide the backplane(s) drives with very little CPU overhead. (maybe none?) (tho 44 pin xmega are a way off)

-jg

Reply to
Jim Granville
Loading thread data ...

No, thanks.

I bet in less then 2 years it will be discontinued, as it is usual with Atmel. The recommended replacement would be, say, Y-Mega or Z-Mega, which are almost compatible except for some fine issues and the unpredictable changes in the configuration bits. Ahhhh, the cost will be higher, too.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

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.

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.

Agreed.

Again, it would not affect a compiler until the compiler added support for that sort of addressing. There is no harm in adding a feature - the only risk if you change remove features on which the tools depend (the view of flash in the dataspace would be in addition to the traditional lpm instructions).

Reply to
David Brown

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. )

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.

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.

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

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

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

Reply to
Jim Granville

That is what I meant.

I think it is all related to project management/resources. Even if things are not perfect, it may be considered good enough, and that resources are better used elsewhere.

Would Atmel benefit, by introducing a few more instructions, and delay the introduction of the X-mega by 1 month/3 months/6 months a year?

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

"Vladimir Vassilevsky" skrev i meddelandet news:wZHxj.9956$ snipped-for-privacy@newssvr12.news.prodigy.net...

OK, I take you on. Would you accept a $10 bet!

The standard AVR family will not be replaced by this, since the X-Mega is not a 5 Volt device.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

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.

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.

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.

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.

Reply to
David Brown

Freescale would REALLY be in trouble...

Actually, for the 3V market, the performance is quadrupled.

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.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

Le Fri, 29 Feb 2008 09:32:13 +0100, Ulf Samuelsson a écrit:

Do not panic guys! I manage the fund bets.

Now attention ladies and gentlemen, nothing more going !

--
HBV
Reply to
Habib Bouaziz-Viallet

Fine with me. I state that more then one of the devices of ATXmega family will be discontinued no later then in 2 years after the it will show up in stock at DigiKey.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

What AVR has EEPROM mapped into data space?

Using lpm isn't terribly painful. No doubt motivated C compiler authors could hide the AVR FLASH constant data access mechanics, if only there was motivation.

Reply to
David Kelly

The XMega - at least for reading the eeprom (I haven't read the datasheets in detail).

No, you can't hide it. C only understands a single address space for data. There is no way to express ideas such as a pointer that is accessed by "lpm" instead of "ld", and there is no way to write a function with a pointer parameter which will work with both a pointer to flash and a pointer to ram. There is plenty of motivation for C compiler writers, but they are restricted by the language and by existing compiler parts (since most compilers share parts with other targets). Solutions include macro wrappers (used by avr-gcc - fully standard C, but a bit ugly), abusing the "const" keyword (used by ImageCraft, until recent versions - very clear and neat, but non-standard and causes trouble for other use of "const"), a new "flash" keyword (used by IAR - neat and clear, but non-standard), and generalised pointers (the only standards-compliant way to get full pointer functionality - but big and slow).

There are plans for introducing multiple address spaces in the next C standards, but I'm not holding my breath waiting for the implementations.

Reply to
David Brown

Exactly right, and in the end that was the downfall of the AVR for me. That's why I don't really see the point of these new big devices. As the memories get bigger and the I/O more capable, the core must be taking up proportionally less and less area. So why not go for a 32 bitter and be done with it?

--

John Devereux
Reply to
John Devereux

Au contraire. It can be done, and it has been done.

That's correct, but not as relevant to the issue at hand as one might think. The trick is that there's no requirement that the single address space known by C map directly to any of the address spaces of the CPU. E.g. in the Keil C compiler for the 8051, a standard C pointer is constructed of two parts: one byte to identify the memory space, and two bytes to hold the actual address.

The downside, of course, is that such pointers are big, clumsy and CPU-expensive to handle. Every access has to be decoded by somewhat involved code that checks which memory space is being used, and then accesses the relevant address. Which is why in addition to the C standard pointer type, Keil supports memory space-specific pointers that don't cause the extra cost or storage.

Reply to
Hans-Bernhard Bröker

Which is precisely what he meant by the "big and slow" "generalised pointers" in the bit you snipped!

--

John Devereux
Reply to
John Devereux

The Philips MX51 core extension, handled this by keeping the opcode basis of separate memory, but also overlaying/re-mapping the DATA space into the TOP of code space. That halves the memory span, but once you have gone past

64K, no uC I have seen get anywhere close to filling up the 24/32 bit address space. The result is the low level stuff stays the same, but you can access ANY code as data (and I guess, jump into RAM and run code there.. ?.)

It would have been an obvious thing to do on the XMEGA ?

-jg

Reply to
-jg

There are multiple AVR32's on the market already ;-)

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.