[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] AT43USB35x support!
From: |
Keith Gudger |
Subject: |
Re: [avr-libc-dev] AT43USB35x support! |
Date: |
Fri, 28 Feb 2003 15:36:39 -0800 (PST) |
The 320 supports 16 address lines for *words* of external Program Memory.
The PC is 16 bits wide. There is NO RAMPZ register. SO, I guess what
this means is that one could have up to 64K of program code, but LPMs
would only be able to get to the bottom 32K? I don't think any of us here
looked at this in detail - We've never put more than a 16K *byte* FLash on
the thing.
I don't have any easier questions...
Keith
On Sat, 1 Mar 2003, Marek Michalkiewicz wrote:
> On Fri, Feb 28, 2003 at 10:34:49PM +0100, Joerg Wunsch wrote:
> > Are they for IAR compatibility? If that's the case, we might move them
> > out to <compat/ina90.h> (doesn't exist yet in that directory). Hmm,
> > just a thought. Alternatively, we could e. g. define a symbol like
> > __COMPAT_IAR there, and maintain device-specific IAR compatibility
> > defines inside the various ioXXX.h files. It would be nice to have
> > them universally available, i. e. to know what to write into the
> > other .h files. Whatever makes migration between the various compilers
> > easier for our users is IMHO a win.
>
> OK, I've just added at43usb320 support, and removed the IAR defines
> from both io43u32x.h and io43u35x.h for now (can be added later, when
> we decide what is the best place for them, ideally for all devices).
>
> One thing about the at43usb320 is not clear to me - it appears to
> support 128K bytes (64K*16) of external program memory, but if
> FLASHEND is defined as 0x1ffff, RAMPZ must be defined, otherwise
> gcrt1.S (using ELPM to copy initialized data) fails to build.
>
> a. RAMPZ exists, but the datasheet forgot to document it
> b. RAMPZ doesn't exist, upper 64K is only for executable code
> c. RAMPZ doesn't exist, upper 64K is a mistake in the datasheet
> d. give me an easier question ;)
>
> What is the correct answer?
>
> Thanks,
> Marek
>
>