Is xmega a viable device for a long-term project?

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

For a long time I have contemplated basing a new design on the xmega; - multiple uarts, multiple SPI, and an (apparently) versatile memory interface make it very attractive. BUT, its very long gestation period, followed by the major analogue system bugs that don't appear to be getting addressed, are making me somewhat nervous about commiting to a multi-year project.

So I have a couple of questions:

1. Does anyone have experience with a significant development using these devices? Any further problems, besides those in the errata?

2. Without wading through all the static surrounding the xplain board, I'm assuming (dangerous, I know) that those problems are just crap-software/hardware design on Atmel's part. Or are there deeper problems?

3. Related to (2), I assume (there I go again!) that program loading/debug via a JTAGICE Mk II, the JTAG interface, and avrstudio is a straightforward, bug-free operation. Or am I wrong?

All comments gratefully received.

Roger

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

Quote:
that program loading/debug via a JTAGICE Mk II, the JTAG interface, and avrstudio is a straightforward, bug-free operation.
The first part you may ASS-U-ME correctly :) I have used both the Dragon in JTAG mode and the JTAGICE Mk II in PDI mode. It all seem to work as well or as bad as any other chip.

The "bug-free operation" is something yet to be determined. It is all awfully slow in single step, but there are over 3000 registers to update at every step so it is livable with.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I am into my second board/project with the A3 device now and have not had any issues at all. I mainly use the JTAG ICE mk II in PDI mode but have also tried JTAG and have not experienced any problems.

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

I have completed porting a large assembler program from ATMega168 to ATXMega16A4. This included a number of additional features. In addition I took the opportunity to change the way some existing features work.

Firstly read "AVR1000: Getting Started Writing C-code for XMEGA" . It has little to do with C but tells you a lot about the design philosophy of the XMEGA.

My experience is that:

    1) Internal AVR code goes across without any trouble (as you would expect) 2) I/O access has been fundamentally changed. Pretty well start again from scratch AVR1000 should give you a clue.
    3) There has been a structure drift throughout the evolution of the AVRmega family. Which has meant a lot of problems porting between processors. Clearly Atmel have decided to put a stop to this and have come up with a structure that should be fixed for future XMegas. There is a 4K register address structure which should not need to grow. At present the registers are scattered thoughout this address range in a structured manner to allow for future enhancements. A good idea but the result is I/O controller access is slower. On an I/O intense section I found the 32MHz XMega was only running 25% faster than on a 20 MHz ATMega.
    4) Documentation - the format has changed but it is still of a good quality. However, a work in progress i.e. errors? - yes, ommisions? - yes. All things considered better than expected and I am sure that Atmel will fix the problems over time.
    5) Debugging - Simulator2 has problems - once again I have no doubt they will be fixed.
    6) Debugging - JTAGICEmk2 (I am using PDI but I suspect most of these comments also appy to JTAG & Dragon) on the whole works well download is reliable and fast. There are problems relating to clocking - the note in help on this subject glosses over what is a serious problem when using some of the more advanced features of XMega. Debugging AWEX and Events needs a major cleanup.
    7) I/O controller application Notes - you will find you need to use these to ovecome ommisions in the "A Manual" and data sheets. This is OK until you find the info you need is HIDDEN in the Example code. As is demonstrated if you want to HIDE information DOXYGEN is an excellent tool for the purpose. :evil:
    8 ) Although the the code port took a lot longer than expected I am pleased with the result.

So would I recommend the XMEGA. If you will be able to use some of the advanced features to advantage the answer is undoubtedly yes. Otherwise stick to the tried and tested AVRmega range.Over time I have no doubt the balance will shift towards the XMEGA. The XMEGA is undoubtedley a very flexible and well strucured device but this is at the cost of complexity.
As to wether problems on the chip are a show stopper depends on your requirements. The ADC problem is undoubtedly the biggest one. The only undocumented bug I have found is on the AWEX.CTRL register.

js wrote:
...It is all awfully slow in single step, but there are over 3000 registers to update at every step so it is livable with.

I have seen a number of references to slow speed in single stepping, however, I have not had any such problems. I use JTAGICEmk2/PDI. If I autostep I can do 2 steps/second. with a large number of things to watch this is quite fast enough.

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

    Thanks guys.

    Trevor_G, I appreciate the time and thought that you have put into your reply - a lot of it sounds like the 'don't ask me how I know that' sort of experience. Could I ask you to expand a little on some of your points, please?

    In (3) you said

    Quote:

    On an I/O intense section I found the 32MHz XMega was only running 25% faster than on a 20 MHz ATMega.

    Is this because it was necessary to use more 2-cycle instructions, or because you had to make more register accesses than previously?

    In (5), could you list a few examples, even if you don't go into detail.

    In (6)

    Quote:

    the note in help on this subject glosses over what is a serious problem when using some of the more advanced features of XMega.

    sounds like a few more words (just a hint) would be handy.

    And ditto again for (7)

    Just knowing that there are needles in the haystack is good, but being able to avoid sitting on them is better...

    Roger

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

    Quote:

    In (3) you said
    Quote:

    On an I/O intense section I found the 32MHz XMega was only running 25% faster than on a 20 MHz ATMega.


    I'd be interested in an expansion of that as well. I'm guessing it is not GPIO register manipulation that is the bottleneck, as the shadow registers should take care of that.

    You can put lipstick on a pig, but it is still a pig.

    I've never met a pig I didn't like, as long as you have some salt and pepper.

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

    laserman wrote:
    Trevor_G, I appreciate the time and thought that you have put into your reply - a lot of it sounds like the 'don't ask me how I know that' sort of experience.

    On the contrary please do ask me how. As the reply was getting rather long I thought I would let you decide what to focus on.

    Quote:
    On an I/O intense section I found the 32MHz XMega was only running 25% faster than on a 20 MHz ATMega.

    The difference in clock speed would be expected to give a 60% increase. There are 2 things getting in the way:
    a) The need to use more 2 cycle acesses
    b) The increase in the number of registers per I/O controller means that bits that would be on a single register are split across two or more registers.

    The figure I quote relates to two timer subroutines that I timed. Although both came out at 25% I am not attempting to generalise only to flag the issue.

    There are of course a number of features that can be used to improve performance. I particularily like the idea of using some of the GPIO registers as flag registers (I always seem to use a lot). The only down side is that sbis & sbic take one cycle longer in XMega than in other AVR's.

    My comment:

    Quote:

    7) I/O controller application Notes - you will find you need to use these to ovecome ommisions in the "A Manual" and data sheets. This is OK until you find the info you need is HIDDEN in the Example code. As is demonstrated if you want to HIDE information DOXYGEN is an excellent tool for the purpose.

    Is something I personally find very irritating. I am not criticising DOXYGEN as such just its totally inappropriate use in this case.

    The purpose of these App Note examples should be to expose the details of I/O drivers in a simple way avoiding irrelevant clutter. Because of the need to modify the source to use DOXYGEN the author has fallen into the traps of splitting the example into 3 or 4 files and in some cases making them into complete applications.

    As a result in an effort to smoke out the "good stuff". I invariably rewrite the example in a single file (as it should have been in the first place). To my surprise despite the fact I was using assembler my source code was often only 70% the length of the original C source.

    Have a look at AVR1003... why is it neccesary to illustrate different clock regimes by flashing LEDs. The most important point that is easily missed is that rather more registers require protected access than is documented in the "A Manual".

    Ok I accept the above is my personal view/rant but make up your own minds.

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

    Quote:
    result is I/O controller access is slower. On an I/O intense section I found the 32MHz XMega was only running 25% faster than on a 20 MHz ATMega
    But In\Out still takes 1 cycle in the Xmega doesn't it? Moving 4 ports to the virtual ports will allow 32 I\O pins to function as any other chip.

    John Samperi

    Ampertronics Pty. Ltd.

    www.ampertronics.com.au

    * Electronic Design * Custom Products * Contract Assembly

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

    js wrote:
    But In\Out still takes 1 cycle in the Xmega doesn't it? Moving 4 ports to the virtual ports will allow 32 I\O pins to function as any other chip.

    True but that is only 16 registers out of how many?
    I must admit I am having trouble with your register total of 3000. I think the figure is under 1000 for the A4's but I must admit I can't be bothered to do a detailed count. In any case there is 4K register address space that could be used in the future.

    When you get into the XMega there is less need to access pins directly. There are controllers to do a huge amount of things. This is where many of the gains on the XMEGA come from. The application I ported across reduced the number of interrupts by 55,000/sec. This also cut down significantly on the need for direct processor intervention.

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

    Quote:
    I am having trouble with your register total of 3000. I think the figure is under 1000 for the A4's
    With the A4 the register map start at 0x000 and finishes at 0x0AA2 (2722).

    With the A1 the register map start at 0x000 and finishes at 0x0BC0 (3008).

    Admitedly there seem to be large adress ranges for things like ports (32 addresses, I can see 21 addresses taken up by each port) but they seem pretty much filled up.

    John Samperi

    Ampertronics Pty. Ltd.

    www.ampertronics.com.au

    * Electronic Design * Custom Products * Contract Assembly

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

    js wrote:
    With the A4 the register map start at 0x000 and finishes at 0x0AA2 (2722).

    With the A1 the register map start at 0x000 and finishes at 0x0BC0 (3008).

    I thought perhaps this was the how the figure had been arrived at. When I looked at the A4 register map I realised that there were some enormous holes. Also controllers were allocated a 16 or less often 32 register address space which is often not fully occupied. So I estimated the A4 on tha basis of 51 controllers with an average of 16 registers totalling 816 registers.Whatever the actual number its a lot of registers!

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

    Thanks everyone.

    Roger