EmbeddedRelated.com
Forums
Memfault Beyond the Launch

X-Mega AVRs are here!

Started by Ulf Samuelsson February 28, 2008
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)
* 44/64/100 pin package
    The pinout allows a design to use 44,64 and 100 pin concentric pads
    with S/W compatability. Pin multiplexing will be identical for
    all I/O ports, Larger devices will have extra ports, not different 
ports.
* 12 bit 2 Ms ADC/1 Ms DAC
* 4 level interrupts
* 4 channel double buffered DMA
* Advanced timers for Motor control
* Fancy new event system
* 2 uA in sleep w Brownout protection and 32 kHz osc.
* 100 nA in deepest sleep mode
* External bus in larger devices with SRAM/SDRAM support

First parts are available now in sample qty.

Press release
http://www.atmel.com/dyn/corporate/view_detail.asp?ref=&FileName=AVR_XMEGA_2_26.html&SEC_NAME=Product

Datasheet
http://www.atmel.com/dyn/products/product_card.asp?PN=ATxmega128A1


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


On Feb 28, 12:28 am, "Ulf Samuelsson" <u...@a-t-m-e-l.com> 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) > * 44/64/100 pin package > The pinout allows a design to use 44,64 and 100 pin concentric pads > with S/W compatability. Pin multiplexing will be identical for > all I/O ports, Larger devices will have extra ports, not different > ports. > * 12 bit 2 Ms ADC/1 Ms DAC > * 4 level interrupts > * 4 channel double buffered DMA > * Advanced timers for Motor control > * Fancy new event system > * 2 uA in sleep w Brownout protection and 32 kHz osc. > * 100 nA in deepest sleep mode > * External bus in larger devices with SRAM/SDRAM support
Only thing missing is a LCD segment driver. Otherwise, we would jump right into it.
linnix <me@linnix.info-for.us> writes:

> On Feb 28, 12:28 am, "Ulf Samuelsson" <u...@a-t-m-e-l.com> 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) >> * 44/64/100 pin package >> The pinout allows a design to use 44,64 and 100 pin concentric pads >> with S/W compatability. Pin multiplexing will be identical for >> all I/O ports, Larger devices will have extra ports, not different >> ports. >> * 12 bit 2 Ms ADC/1 Ms DAC >> * 4 level interrupts >> * 4 channel double buffered DMA >> * Advanced timers for Motor control >> * Fancy new event system >> * 2 uA in sleep w Brownout protection and 32 kHz osc. >> * 100 nA in deepest sleep mode >> * External bus in larger devices with SRAM/SDRAM support > > Only thing missing is a LCD segment driver. Otherwise, we would jump > right into it.
And an extra 24 bits of register width... And a Von Neumann architecture. :) -- John Devereux
John Devereux wrote:
> linnix <me@linnix.info-for.us> writes: > >> On Feb 28, 12:28 am, "Ulf Samuelsson" <u...@a-t-m-e-l.com> 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) >>> * 44/64/100 pin package >>> The pinout allows a design to use 44,64 and 100 pin concentric pads >>> with S/W compatability. Pin multiplexing will be identical for >>> all I/O ports, Larger devices will have extra ports, not different >>> ports. >>> * 12 bit 2 Ms ADC/1 Ms DAC >>> * 4 level interrupts >>> * 4 channel double buffered DMA >>> * Advanced timers for Motor control >>> * Fancy new event system >>> * 2 uA in sleep w Brownout protection and 32 kHz osc. >>> * 100 nA in deepest sleep mode >>> * External bus in larger devices with SRAM/SDRAM support >> Only thing missing is a LCD segment driver. Otherwise, we would jump >> right into it. > > And an extra 24 bits of register width... And a Von Neumann > architecture. :) >
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. 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. 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). 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...
On Feb 28, 9:53 am, David Brown
<david.br...@hesbynett.removethisbit.no> wrote:
> John Devereux wrote: > > linnix <m...@linnix.info-for.us> writes: > > >> On Feb 28, 12:28 am, "Ulf Samuelsson" <u...@a-t-m-e-l.com> 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) > >>> * 44/64/100 pin package > >>> The pinout allows a design to use 44,64 and 100 pin concentric pads > >>> with S/W compatability. Pin multiplexing will be identical for > >>> all I/O ports, Larger devices will have extra ports, not different > >>> ports. > >>> * 12 bit 2 Ms ADC/1 Ms DAC > >>> * 4 level interrupts > >>> * 4 channel double buffered DMA > >>> * Advanced timers for Motor control > >>> * Fancy new event system > >>> * 2 uA in sleep w Brownout protection and 32 kHz osc. > >>> * 100 nA in deepest sleep mode > >>> * External bus in larger devices with SRAM/SDRAM support > >> Only thing missing is a LCD segment driver. Otherwise, we would jump > >> right into it. > > > And an extra 24 bits of register width... And a Von Neumann > > architecture. :) > > 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. > > 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. > > 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). > > 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...
Adding to the AVR wish list. Having access to the SPI engine from the CPU would be nice. There are many features of the uC available to external SPI access, but impossible to do internally. For examples: fuses and lock bits, flash and eeprom.
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) > * 44/64/100 pin package > The pinout allows a design to use 44,64 and 100 pin concentric pads > with S/W compatability. Pin multiplexing will be identical for > all I/O ports, Larger devices will have extra ports, not different > ports. > * 12 bit 2 Ms ADC/1 Ms DAC > * 4 level interrupts > * 4 channel double buffered DMA > * Advanced timers for Motor control > * Fancy new event system > * 2 uA in sleep w Brownout protection and 32 kHz osc. > * 100 nA in deepest sleep mode > * External bus in larger devices with SRAM/SDRAM support > > First parts are available now in sample qty. > > Press release > http://www.atmel.com/dyn/corporate/view_detail.asp?ref=&FileName=AVR_XMEGA_2_26.html&SEC_NAME=Product > > Datasheet > http://www.atmel.com/dyn/products/product_card.asp?PN=ATxmega128A1
Missing in these devices is any mention of LIN support ? (but they do have a truckload of serial ports, and Quadrature counting, Ulf left of his list..) Peripherals is where all the action is these days. -jg
linnix wrote:
> > Adding to the AVR wish list. Having access to the SPI engine from the > CPU would be nice. There are many features of the uC available to > external SPI access, but impossible to do internally. For examples: > fuses and lock bits, flash and eeprom.
You mean the programming interface ? flash and eeprom are surely available ? Fuses ? - a good uC should be able to READ the fuse status, but IAP programming them is a different call: Higher risk, and lower security ? -jg
On Feb 28, 10:39 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> linnix wrote: > > > Adding to the AVR wish list. Having access to the SPI engine from the > > CPU would be nice. There are many features of the uC available to > > external SPI access, but impossible to do internally. For examples: > > fuses and lock bits, flash and eeprom. > > You mean the programming interface ? > flash and eeprom are surely available ? > > Fuses ? - a good uC should be able to READ the fuse status, but > IAP programming them is a different call: Higher risk, and lower > security ?
No more riskier than being able to reprogram the flash. They can have a very complicated sequence to change the fuses/locks.
On Feb 28, 12:22=A0pm, linnix <m...@linnix.info-for.us> wrote:
> On Feb 28, 12:28 am, "Ulf Samuelsson" <u...@a-t-m-e-l.com> 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) > > * 44/64/100 pin package > > =A0 =A0 The pinout allows a design to use 44,64 and 100 pin concentric p=
ads
> > =A0 =A0 with S/W compatability. Pin multiplexing will be identical for > > =A0 =A0 all I/O ports, Larger devices will have extra ports, not differe=
nt
> > ports. > > * 12 bit 2 Ms ADC/1 Ms DAC > > * 4 level interrupts > > * 4 channel double buffered DMA > > * Advanced timers for Motor control > > * Fancy new event system > > * 2 uA in sleep w Brownout protection and 32 kHz osc. > > * 100 nA in deepest sleep mode > > * External bus in larger devices with SRAM/SDRAM support > > Only thing missing is a LCD segment driver. =A0Otherwise, we would jump > right into it.- Hide quoted text - > > - Show quoted text -
Atmel introduced the SAM7L series a few days ago, which is low power and has an LCD segment driver, but meager SRAM (always something!) http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=3DAT91SAM7L_2_26= .html
On Feb 28, 11:00 am, steve <bungalow_st...@yahoo.com> wrote:
> On Feb 28, 12:22 pm, linnix <m...@linnix.info-for.us> wrote: > > > > > On Feb 28, 12:28 am, "Ulf Samuelsson" <u...@a-t-m-e-l.com> 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) > > > * 44/64/100 pin package > > > The pinout allows a design to use 44,64 and 100 pin concentric pads > > > with S/W compatability. Pin multiplexing will be identical for > > > all I/O ports, Larger devices will have extra ports, not different > > > ports. > > > * 12 bit 2 Ms ADC/1 Ms DAC > > > * 4 level interrupts > > > * 4 channel double buffered DMA > > > * Advanced timers for Motor control > > > * Fancy new event system > > > * 2 uA in sleep w Brownout protection and 32 kHz osc. > > > * 100 nA in deepest sleep mode > > > * External bus in larger devices with SRAM/SDRAM support > > > Only thing missing is a LCD segment driver. Otherwise, we would jump > > right into it.- Hide quoted text - > > > - Show quoted text - > > Atmel introduced the SAM7L series a few days ago, which is low power > and has an LCD segment driver, but meager SRAM (always something!) > > http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=AT91SAM7L...
But it does not come in 44 pins. We are small people working on small projects, so smaller chip is better. We need 16K flash, 4 A2D and 12x4 or 8x8 segmented LCD.

Memfault Beyond the Launch