8/16-bit AVR microcontroller?

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel repeatedly claims (on web site and in datasheets) that the XMega is an "8/16-bit" microcontroller.

Now I've searched the datasheets specifically for 16-bit stuff and for differences between mega1280 and xmega128A1. I expected to find a number of new instructions handling 16-bit operations, but no. I see a lot of differences, but, sadly, fail to see that the XMega is a 16-bit microcontroller any more than the mega 1280. I see both as being 8-bit microcontrollers and that's that.

Does any of you know where that 8/16-bit stuff comes from?

Best regards,
ErikT

You're absolutely right. This member is stupid. Please help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps they mean "like 16 bit" in the sense that it has advanced on chip features (Events, DMA) as usually only found on micros greater than 8 bit?

But you are right that apart from the AES/DES opcodes and the LACT/LAT/etc. stuff there's nothing really new in the opcode set and the working registers are still all just 8bits wide while the indexing registers are 16bit and can only address 64K.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, I read it as "16-bit performance in an 8-bit architecture".

Note that technically, in the XMega, all the index registers are always treated as 24-bits wide for all data address space operations (as opposed to Flash address space, where they are still selectable between 16-bits and 24-bits based on the associated variety of (E)LPM op-code). And all pre/post-increment/decrement operations on the data address space always apply to the full 24-bit width of the index registers.

So every time you access the data space through the index registers, you always have access to the full 16 MB address space - it's just that the (nominally) 3 byte transfer sequences you need to issue to set up the pointer apply to different target register spaces -- the first two bytes are set up in the CPU register space, and the 3rd byte is set up in the I/O register space.

This may lead to confusion, for example, if you wrote an esoteric application which depended on post-incrementing the index pointer to automatically wrap around from 0xFFFF back down to 0x0000 -- it wouldn't wrap around, but would rather increment to the potentially invalid memory location 0x10000.

However, the most significant 8 bits of each of the index registers live in I/O-space instead of CPU-space.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks a lot. So it's not just me who doesn't understand something that should be obvious. That's a relief.

Quote:
So every time you access the data space through the index registers, you always have access to the full 16 MB address space - it's just that the (nominally) 3 byte transfer sequences you need to issue to set up the pointer apply to different target register spaces -- the first two bytes are set up in the CPU register space, and the 3rd byte is set up in the I/O register space.

This may lead to confusion, for example, if you wrote an esoteric application which depended on post-incrementing the index pointer to automatically wrap around from 0xFFFF back down to 0x0000 -- it wouldn't wrap around, but would rather increment to the potentially invalid memory location 0x10000.


Luckily, I don't do super-advanced (or strange) stuff like that. :-)

So, let's just ignore the whole 16-bit shebang, and accept that this is just another 8-bit microcontroller.

Best regards,
ErikT

You're absolutely right. This member is stupid. Please help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use an MSP430 or a PIC24/dsPIC if I need a 16-bit MCU, they both have a full set of 16-bit registers and 16-bit arithmetic operations. I wouldn't call the Xmega a 16-bit device in the same sense as those products.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I wouldn't call the Xmega a 16-bit device in the same sense as those products.

Out of interest, do they have the advanced features like Events, DMA and EBI support?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DMA:
I think the at least some subset of the PIC24/dsPIC family does have DMA support. A quick read of a Microchip presentation suggests that they have a special dedicated 2KB region of data space in which DMA transfers must originate and/or terminate. They support 8 independent DMA channels. Provided you design your application so that it requires no more than 2KB of buffer space for all your concurrent DMA transfers, that should be fine.

XMega allows you to use as much of the full Data address space as you wish for DMA transfers, but it only has 4 independent DMA channels. So in applications where you KNOW that you'd need a grand total of more than 2KB of concurrent DMA buffer space, XMega would be a winner; for applications where you KNOW that you'll need to perform more than 4 DMA transfers concurrently, PIC24/dsPIC would be a winner; otherwise, I think this would be a draw.

EBI:
Again, I believe at least some members of the dsPIC and PIC24 family have a parallel memory interface. This interface is not directly integrated into the native CPU address space in the same way as XMega devices -- its software interface is extremely similar to the interface you'd use for accessing the internal EEPROM of a classic AVR.

Personally, due to the simpler interface which actually places the full extent of the EBI within the same linear address space as internal SRAM, and its flexibility for more different chip select and port multiplexing options, and its integrated SDRAM support, I'd call the XMega's implementation a clear winner.

Event System:
I think this is fairly unique to the XMega within this application space. I'd love to be shown some examples of clear equivalents or improvements on the design.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a full description of the PIC24H DMA:

http://ww1.microchip.com/downloa...

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lfmorrison wrote:
DMA:
I think the at least some subset of the PIC24/dsPIC family does have DMA support. A quick read of a Microchip presentation suggests that they have a special dedicated 2KB region of data space in which DMA transfers must originate and/or terminate. They support 8 independent DMA channels. Provided you design your application so that it requires no more than 2KB of buffer space for all your concurrent DMA transfers, that should be fine.

XMega allows you to use as much of the full Data address space as you wish for DMA transfers, but it only has 4 independent DMA channels. So in applications where you KNOW that you'd need a grand total of more than 2KB of concurrent DMA buffer space, XMega would be a winner; for applications where you KNOW that you'll need to perform more than 4 DMA transfers concurrently, PIC24/dsPIC would be a winner; otherwise, I think this would be a draw.

EBI:
Again, I believe at least some members of the dsPIC and PIC24 family have a parallel memory interface. This interface is not directly integrated into the native CPU address space in the same way as XMega devices -- its software interface is extremely similar to the interface you'd use for accessing the internal EEPROM of a classic AVR.

Personally, due to the simpler interface which actually places the full extent of the EBI within the same linear address space as internal SRAM, and its flexibility for more different chip select and port multiplexing options, and its integrated SDRAM support, I'd call the XMega's implementation a clear winner.

Event System:
I think this is fairly unique to the XMega within this application space. I'd love to be shown some examples of clear equivalents or improvements on the design.

For me the decision is a no brainer.

With the exception of EBI, all xmegas have events and dma (among dacs , and ebi in the case of A1s) as standard features.

While a 16 bit core is nice, it's no killer feature.

Atmel did the right thing by skipping 16 bit, and directing focus at 8 and 32bits.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCHIP's DMA is a true DMA, compared to the slower cycle-stealing design of the Xmega . For the uCHIP families mentioned they have an EBI for up to 64KB and selectable 8/16 bit data bus .

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They are also much faster devices - up to 70 (16-bit) MIPS.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
all xmegas have events and dma (among dacs , and ebi in the case of A1s) as standard features.

XMEGA D-series does not seem to have DMA. It still has events.
I think most "advanced" controllers link their peripherals to their DMA controllers in a scheme that is somewhat less flexible than xmega "events", but I havent dug into the details. (The D-series surprised me, because I thought the most likely action for an event would be a DMA...)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Quote:
all xmegas have events and dma (among dacs , and ebi in the case of A1s) as standard features.

XMEGA D-series does not seem to have DMA. It still has events.
I think most "advanced" controllers link their peripherals to their DMA controllers in a scheme that is somewhat less flexible than xmega "events", but I havent dug into the details. (The D-series surprised me, because I thought the most likely action for an event would be a DMA...)

The "D" series is by all means crippled. It's sad that with the ARM competitors hovering about, Atmel should cripple its mcus.

Instead of crippling its mcus, Atmel should have done what it has traditionally done with the older Atmegas: price them according to flash memory.

I don't think Atmel would have gained the respect it has now among us had it decided to cripple its traditional AVRs like it is doing now with the "D" series.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But the D is surely a "cost down version" aimed at those that just want a subset of X features and a low pin count?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

indianajones11 wrote:
uCHIP's DMA is a true DMA, compared to the slower cycle-stealing design of the Xmega .

Which would be an important distinction in situations where the data needs to be transferred at speeds on the same order as the CPU instruction time. It would be a much less consequential distinction in situations where the peripheral to/from which the data is being transferred dictates transfer speeds more on the order of dozens to hundreds of CPU clock cycles, which (for me) is the case in the vast majority of circumstances.

Quote:
For the uCHIP families mentioned they have an EBI for up to 64KB and selectable 8/16 bit data bus .

But from what I've read, uCHIP's PMP (their name for EBI) is a separate address space, and requires a separate software abstraction layer to read/write - and probably manual allocation of static and/or automatic variables to live in that memory region.

I REALLY like the XMega's EBI for the way in which it integrates the external address space seamlessly into the XMega's internal data address space, so reads/writes to any location in the EBI are completely indistinguishable from reads/writes to any other portion of the data address space, and the compiler can automatically manage allocating all variables that live in external memory. I cannot overstate this point: I REALLY like that feature.

It is also more flexible, allowing up to 16 MB of external memory across up to 4 independent chip selects, and the possibility to interface with SDRAM natively. I haven't needed those features personally, so I have never needed to investigate them in too much depth.