Xmega, my take

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

So I've been hacking away at the ATxmega for the last two weeks, and I gotta say I'm impressed.

This is probably the closest anyone will ever get to designing a processor that facilitates the implementation of high level code. Daily, I am stunned at how easy C++ code is written for this processor. Thats pretty high praise coming from me, because I'm not a C++ guy. This processor design just fits so well with OOP.

Whom ever was the master mind behind this gem, I'm drinking my favorite beer in your honor tonight.

That being said; I do think the bean counters did do some damage to the chip, before it made it to market. Its hideously under endowed with RAM, particularly for the number of peripherals.

Start the low end parts at 16K of ram, and go all the way up to 64K. Then add a built in Wiznet W5300, and that my friends would be a killer part.

Now don't get me started on the manufacturing of the parts, I still can't believe the 52 week lead times for parts that are supposed to be released. No, I'll completely ignore that for now, and just say thanks for the great design.

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

Quote:

This is probably the closest anyone will ever get to designing a processor that facilitates the implementation of high level code. Daily, I am stunned at how easy C++ code is written for this processor. Thats pretty high praise coming from me, because I'm not a C++ guy. This processor design just fits so well with OOP.

What sets the xmega apart from AVR or MIPS or ARM or PIC or whatever else in this sense?

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

clawson wrote:
Quote:

This is probably the closest anyone will ever get to designing a processor that facilitates the implementation of high level code. Daily, I am stunned at how easy C++ code is written for this processor. Thats pretty high praise coming from me, because I'm not a C++ guy. This processor design just fits so well with OOP.

What sets the xmega apart from AVR or MIPS or ARM or PIC or whatever else in this sense?

With each port being essentially identical, there aren't any hacks to writing a single code object that can drive all the peripherals of that particular type. Just pass the pointer to the structure (set of registers), and it just works.

With every other embedded processor there are always hacks needed to make then all look/act the same.

I've never written a serial driver for a processor, as quickly as I did for the xmega. Then to actually have all 8 USARTs working, once I got the first one working, was amazing.

Same with the timers, not little quirks between the two types.

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

Thanks, that's interesting.

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

dlmarti wrote:

With each port being essentially identical, there aren't any hacks to writing a single code object that can drive all the peripherals of that particular type. Just pass the pointer to the structure (set of registers), and it just works.

With every other embedded processor there are always hacks needed to make then all look/act the same.

I've never written a serial driver for a processor, as quickly as I did for the xmega. Then to actually have all 8 USARTs working, once I got the first one working, was amazing.

Same with the timers, not little quirks between the two types.

Well that's ALMOST true. Not all ports have the same number of peripherals. Most of the ports have at least one usart attached, TWI is available only on a few of the ports, etc. Still it IS true that where two ports have the same peripherals the only difference in programming is the "address" pointer.

Access to peripheral registers is now structure like, though this may be more of an invention of the compiler writers who took advantage of the uniform address layout than the silicon.

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

kscharf wrote:

Well that's ALMOST true. Not all ports have the same number of peripherals. Most of the ports have at least one usart attached, TWI is available only on a few of the ports, etc. Still it IS true that where two ports have the same peripherals the only difference in programming is the "address" pointer.

Access to peripheral registers is now structure like, though this may be more of an invention of the compiler writers who took advantage of the uniform address layout than the silicon.

I was speaking of the peripheral ports (ie. the USART/SPI/etc), not the 8bit ports (ie. PORTC).

In other words I can write code that just passes a reference to the device, and the code doesn't have to know which particular device.

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

dlmarti wrote:
kscharf wrote:

Well that's ALMOST true. Not all ports have the same number of peripherals. Most of the ports have at least one usart attached, TWI is available only on a few of the ports, etc. Still it IS true that where two ports have the same peripherals the only difference in programming is the "address" pointer.

Access to peripheral registers is now structure like, though this may be more of an invention of the compiler writers who took advantage of the uniform address layout than the silicon.

I was speaking of the peripheral ports (ie. the USART/SPI/etc), not the 8bit ports (ie. PORTC).

In other words I can write code that just passes a reference to the device, and the code doesn't have to know which particular device.

which is exactly what I meant. IE: usartE0, usartE1 refers to the usarts attached to portE pins (there are two of them).

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

Yes, the Xmega is more modular. They did away with things like PCMSK0 where each bit controlled a different port. With the Xmega such bits are in the port's registers, where they logically belong.

The ARM7 I programmed was just as bad as the Mega, or worse. There was a 32 bit interrupt enable register (or something like that) where each of the bits controlled the interrupts of a different device. So you couldn't simply write a device class that would work for multiple devices even if the devices were otherwise identical. You always needed a kludge.