It gets quite confusing.
Anatoly decribes a method to allow an addition 64K bytes of space for
progmem data. As this is limited to 64K bytes even for 128 devices.
(since pointers are byte pointers)
For functions, pointers are words - so 64Kwords or 128K bytes is ok for
128 devices - but not f
Andy H wrote:
Yes this should be more than enough for data!
I am happy with "high" or anything that is not "far".
I am more than happy to be way off base, but the libraries looks to
already be using _far:
When I ported some code recently from M644(p) to M1281, I had to fix this:
#if FLASHEND
Yes this should be more than enough for data!
I am happy with "high" or anything that is not "far".
(Its bad enough with "trampolines" that are not really trampolines.) ;-)
Andy
Anatoly Sokolov wrote:
Hi.
From: "Andy H" <[EMAIL PROTECTED]>
Sent: Sunday, July 20, 2008 8:51 PM
A better
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Anatoly Sokolov
> Sent: Sunday, July 20, 2008 11:37 AM
> To: Andy H
> Cc: avr-GCC
> Subject: Re: [avr-gcc-list] Re: "progmem_far" attribute
>
> This patch adderss only to data. User space
Hi.
From: "Andy H" <[EMAIL PROTECTED]>
Sent: Sunday, July 20, 2008 8:51 PM
>
> A better name would be progmem_high. FAR is entirely different.
Ok.
>
> Unlike some cpu AVR does not need different direct JMP/CALL/RET...
This patch adderss only to data. User space of 'progmem' section
lim
I was describing concept - not literally.
Literal it would be
|*int* (far *x)(*float*, *char*, *char*) = NULL; |
or similar.
Internally we would handle as unsigned long (SImode).
If we get that far without a road block, then the last step is for gcc
to permit a call using this and not squark
On 7/20/08, Andy H <[EMAIL PROTECTED]> wrote:
> If we can create "FAR" as unsigned long
Should that not be size_t rather than unsigned long?
Might not make a difference on the smaller AVR's right
now but if we ever need to port the code to a future AVR64
it might.
--
http://www.wearablesmarts
To use that amount, would suggest we need additional abilities to
access progmem without going thru RAM.
But if this is considered a limitation then your method seems ok.
A better name would be progmem_high. FAR is entirely different.
FAR is normally used to indicate large pointers - not
Hi Anatoly,
Patches look good so far.
Is included in avr.c? Should it be for the bool type, and
'true' and 'false'?
FYI, it would be nice if you could use the -p switch in producing
patches. This prints out the C function that the hunk belongs to. It
helps in reviewing patches.
Thanks,
Eric We
Hi.
The patch add "progmem_far" attribute in GCC.
Anatoly.
- Original Message -
From: "Anatoly Sokolov" <[EMAIL PROTECTED]>
To: "avr-GCC"
Cc: "Anatoliy Sokolov" <[EMAIL PROTECTED]>
Sent: Friday, May 02, 2008 8:36 PM
Subject: "progmem_far" attribute
> Hello.
>
> Now GCC have "progme
10 matches
Mail list logo
