[Top][All Lists]

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

RE: [avr-gcc-list] ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/

From: Mark E. Scott Jr.
Subject: RE: [avr-gcc-list] ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/ATMega2561
Date: Tue, 13 Sep 2005 14:19:45 -0500

I'd be overjoyed to have any solution for the 2560 :)  It sounded to me
like the option #2 (GCC mods) was a non-starter.

Mark E. Scott, Jr.
AWS, Inc.
512-478-7727 x 122

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Bjarne Laursen
Sent: Tuesday, September 13, 2005 1:59 AM
To: address@hidden
Subject: Re: [avr-gcc-list]

Chip Webb wrote:

> It seemed as though there were two proposed methods to handle this:
> 1) Align functions (and labels?) to 4-byte boundaries so that  gcc can

> continue to use 16-bit
>   values to represent function pointers.  This isn't so different from

> the method that is
>   already used for the Mega128.
> 2) Modify GCC to support longer pointers (PSImode?)

3) Make any function, where the address is put into a pointer, start  
below 64K, using a jump if neassesary.

Also: If these functions, and any program memory strings could be forced

into a memory range like 32K<=adr<64K, it would be possible to determine

if a pointer points to ram or flash at runtime. This could be very

I know these things have limits too, like when using more than 32K ram, 
or more than 32K program memory strings.

AVR-GCC-list mailing list

reply via email to

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