Re: X-Mega AVRs are here!
- From: linnix <me@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 28 Feb 2008 10:09:40 -0800 (PST)
On Feb 28, 9:53 am, David Brown
John Devereux wrote:
linnix <m...@xxxxxxxxxxxxxxxxxx> writes:
On Feb 28, 12:28 am, "Ulf Samuelsson" <u...@xxxxxxxxxxxxx> wrote:
For people in this newsgroup that has been wondering...
Key featuresOnly thing missing is a LCD segment driver. Otherwise, we would jump
* 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
* 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
right into it.
And an extra 24 bits of register width... And a Von Neumann
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.
- Re: X-Mega AVRs are here!
- From: Jim Granville
- Re: X-Mega AVRs are here!
- Prev by Date: Re: GNU tar problem
- Next by Date: Re: New STM8 Microcontroller from STMicroelectronics is ST7 Upgrade
- Previous by thread: Re: X-Mega AVRs are here!
- Next by thread: Re: X-Mega AVRs are here!