linnix wrote:> On Feb 28, 1:23 pm, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote: > >>>>>On Feb 28, 12:28 am, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote: >>I think that you might be able to create a simple LCD controller with the >>X-Mega DMA controllers, timers and the event handling. > > Yes, as long as we can set the outputs at 3V, regardless of battery > voltage.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
X-Mega AVRs are here!
Started by ●February 28, 2008
Reply by ●February 28, 20082008-02-28
Reply by ●February 28, 20082008-02-28
Ulf Samuelsson wrote:> For people in this newsgroup that has been wondering... > > > Key features > * ATmegaAVR core (just higher frequency) > * 1.6V-3.6V operation > * Flash (max 384 kB)/SRAM/EEPROM > * 32 Mhz operation (max 32 MIPS)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 http://www.abvolt.com
Reply by ●February 28, 20082008-02-28
Ulf Samuelsson wrote:> "David Brown" <david.brown@hesbynett.removethisbit.no> skrev i meddelandet > news:47c6f520$0$15000$8404b019@news.wineasy.se... >> John Devereux wrote: >>> linnix <me@linnix.info-for.us> writes: >>><snip>>> It's fair enough that it's an 8-bit architecture, but they could have put >> a little effort into fixing the most glaring design flaws of the cpu. Why >> not drop the fmul* instructions that almost never get used, along with the >> rcall opcodes (I guess they are used by Forth systems, but I can't see >> they are much use to a C compiler), and add some of the features that >> would have made a real difference to the cpu power for C programming? >> Adding an X+q mode comparable to the Y+q and Z+q, and making R24:R25 a >> forth pointer register would be a big help. Support for (SP+q) addressing >> would be a benefit, although it would not be too important if it there was >> more if a forth pointer with W+q addressing modes existed. A method of >> atomically accessing the 16-bit stack pointer would be useful, however. > > 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.> 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.>> As for making it entirely von Neumann, I think that's a bit too big a >> change - but it would have been perfectly possible to make the flash >> accessible in the data space as well (in the same way as the eeprom is now >> mapped into the data space). You'd need 24-bit pointers to access it, but >> it would still be a very useful feature. >> > > The AVR core supports 16 MB dataspace and 8 MB instruction space. > I think that if the code was mapped to the upper 8 MB of the dataspace > there would be no conflicts.Agreed.> Again, such a change would probably affect the compilers, > which was undesirable. >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).>> It's also missing a CAN controller, and the SDRAM setup is a bit odd (it >> should be possible to get an 8-bit SDRAM bus using only three ports). >> > > I assume that the fancy stuff will come in future chips. > >> Apart from that, it looks a very nice chip, which we will probably find >> use for. Maybe I can use it to drive my QVGA screen... >
Reply by ●February 28, 20082008-02-28
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. )>> 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. 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 by ●February 29, 20082008-02-29
"Jim Granville" <no.spam@designtools.maps.co.nz> skrev i meddelandet news:47c75702$1@clear.net.nz...> David Brown wrote: >> Ulf Samuelsson wrote: >> >>> >>> Which of course require a new compiler... >> >> >> No, it would mean a *change* in the compiler.That is what I meant.> 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. >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 This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Reply by ●February 29, 20082008-02-29
"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> skrev i meddelandet news:wZHxj.9956$5K1.7906@newssvr12.news.prodigy.net...> > > Ulf Samuelsson wrote: > >> For people in this newsgroup that has been wondering... >> >> >> Key features >> * ATmegaAVR core (just higher frequency) >> * 1.6V-3.6V operation >> * Flash (max 384 kB)/SRAM/EEPROM >> * 32 Mhz operation (max 32 MIPS) > > > No, thanks. > > I bet in less then 2 years it will be discontinued,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.> 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 > http://www.abvolt.com >-- 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
Reply by ●February 29, 20082008-02-29
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 > > > >
Reply by ●February 29, 20082008-02-29
>> >> 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
Reply by ●February 29, 20082008-02-29
Le Fri, 29 Feb 2008 09:32:13 +0100, Ulf Samuelsson a écrit:> "Vladimir Vassilevsky" <antispam_bogus@hotmail.com> skrev i meddelandet > news:wZHxj.9956$5K1.7906@newssvr12.news.prodigy.net... >> >> >> Ulf Samuelsson wrote: >> >>> For people in this newsgroup that has been wondering... >>> >>> >>> Key features >>> * ATmegaAVR core (just higher frequency) >>> * 1.6V-3.6V operation >>> * Flash (max 384 kB)/SRAM/EEPROM >>> * 32 Mhz operation (max 32 MIPS) >> >> >> No, thanks. >> >> I bet in less then 2 years it will be discontinued, > > OK, I take you on. > Would you accept a $10 bet!Do not panic guys! I manage the fund bets. Now attention ladies and gentlemen, nothing more going !> > The standard AVR family will not be replaced by this, since > the X-Mega is not a 5 Volt device. > >> 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 >> http://www.abvolt.com >> > > >-- HBV
Reply by ●February 29, 20082008-02-29
Ulf Samuelsson wrote:> "Vladimir Vassilevsky" <antispam_bogus@hotmail.com> skrev i meddelandet > news:wZHxj.9956$5K1.7906@newssvr12.news.prodigy.net...>>I bet in less then 2 years it will be discontinued, > > OK, I take you on. > Would you accept a $10 bet!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 http://www.abvolt.com
