AVR Freaks

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.

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.

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:

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.

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.

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!