[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Xmega class confusion?

From: Erik Walthinsen
Subject: Re: [avr-gcc-list] Xmega class confusion?
Date: Thu, 03 Jun 2010 17:44:51 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100423 Thunderbird/3.0.4

On 06/03/2010 05:05 PM, Weddington, Eric wrote:
Also take a look at the comments for avr.c in the patch. There it shows the classification 
of the devices. Those devices that are in an architecture that says ">  64K 
RAM" means the possibility of using external RAM.
Right, that's the table I copied into my original post. There are two inconsistencies I'm trying to understand and make sure are correct:

1) the 32a4 is listed as avrxmega3, which is 8-64KB Flash, and >64KB RAM. Problem is, *only* the A1 series chips have an EBI, so the 32a4 is not capable of more than the 4KB it comes with. The 32d4 is correctly listed as avrxmega2, <=64KB RAM.

2) all the class boundaries are very clearly delineated as far as which boundaries are *in* the window, and which are *outside*. avrxmega5 is listed as > 64KB and <= 128KB (and >64KB RAM), yet the only chip ever put in that range is the 64a1. That's inconsistent, as 64KB is not > 64KB.

!!!!! *brainstorm* I think I might have realized where the confusion is, and how it can be rectified in comments and documentation:

The > <= window for flash *includes* the bootloader space. That means the 64a4 is actually 64KB + 4KB, so it falls within the "> 64KB" rule. If that's the reason, then the comments and docs should indicate that "flash size includes bootloader", and that will clear up any confusion. I can draft a patch to that effect.

And yes this patch will be in the next toolchain release, of course.
Do you mean the mainline binutils/gcc release, or WinAVR et al?

I'll make a point of finding/filing and following Debian and Ubuntu bugs to make sure the next versions of the binutils-avr, gcc-avr, and avr-libc packages have the proper device support.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]