Re: X-Mega AVRs are here!

"David Brown" <david.brown@xxxxxxxxxxxxxxxxxxxxxxxxxx> skrev i meddelandet
news:47c6f520$0$15000$8404b019@xxxxxxxxxxxxxxxxxx
John Devereux wrote:
linnix <me@xxxxxxxxxxxxxxxxxx> writes:

On Feb 28, 12:28 am, "Ulf Samuelsson" <u...@xxxxxxxxxxxxx> 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.

Which of course require a new compiler...
The decision was made to not change the CPU core.


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.
Again, such a change would probably affect the compilers,
which was undesirable.

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

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


.

Relevant Pages

  • Re: X-Mega AVRs are here!
    ... The pinout allows a design to use 44,64 and 100 pin concentric pads ... all I/O ports, Larger devices will have extra ports, not different ... Why not drop the fmul* instructions that almost never get used, along with the rcall opcodes, and add some of the features that would have made a real difference to the cpu power for C programming? ... Support for 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. ...
    (comp.arch.embedded)
  • Xilinx System Generator Black Box
    ... A few weeks back I posted about importing a VHDL, actually a Xilinx Core, ... core wrapper for a core that does not have a CE pin. ... the wrapper and every time I brought it into the Simulink model it would ... front of the filter driven by 4 sine wave blocks. ...
    (comp.arch.fpga)
  • Re: Commodore One help needed
    ... All this playing with cores and mostly the TurboCPC core - which is used to ... The MonsterSID features disappeared. ... on this current version C-One. ... CPC and a partially working C64 core. ...
    (comp.sys.cbm)
  • Re: Where next?
    ... I agree with the committee's approach: new core including module ... system plus standard libraries, ... belong to "the core" even if they're organized as libraries. ... This even allows adding some new features (such as making ...
    (comp.lang.scheme)
  • Re: Fast embedded architectures.
    ... >>risc'ified a 68k with a ton of embedded features. ... The ColdFire core design has quite an interesting history (assuming I ... programming model was already fairly "riscy" (16 full-size registers, ... register, variable instruction lengths). ...
    (comp.arch.embedded)