[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?
From: |
E. Weddington |
Subject: |
Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>? |
Date: |
Tue, 08 Oct 2002 10:13:26 -0600 |
On 8 Oct 2002 at 9:55, Joerg Wunsch wrote:
> [Marek & Denis: please see below for a specific question, that's
> why i've set you on Cc.]
>
> As E. Weddington wrote:
>
> > > Both are not the same, i think. Does gcc automatically set RAMPZ?
>
> > RAMPZ is defined in the specific ioXXXX.h file. Doing a grep, it's
> > defined for the mega103 (iom103.h) and the mega128 (iom128.h).
>
> Sorry, i was not clear. :-) Sure, i knew this.
>
Sorry too. (It did seem kind of an odd question :-)
> My question was whether when accessing an __attribute__((progmem))
> string, would gcc automatically set the appropriate value in RAMPZ, or
> is it in the domain of the programmer to do so. If gcc doesn't handle
> this automatically, i don't see why one should always use ELPM on >
> 64KB devices.
I thought (and I could be wrong) that the only way to access progmem
data was through the API that the lib provides; hence it boils down
to the _LPM() and _ELPM() macros which produce inline assembly. So,
if that's the case, it would seem that gcc would *not* automatically
set RAMPZ. Also, how would gcc know about the existence of RAMPZ?
It's not a general purpose register; it's in the I/O space.
> Btw., unfortunately, there's no different architecture name for > 64K
> devices (only a distinction for <= 8KB and > 8KB since the latter
> require JMP/CALL instead of RJMP/RCALL to cover the entire address
> space), thus the existence of RAMPZ & ELPM cannot be automatically
> determined inside library code anyway (since there's only one library
> version per architecture). This, for example, will restrict the
> impending printf_p() implementation from accessing format strings
> beyond 64 KB. Perhaps we should invent avr6 for avr5 devices with
> more than 64 KB of RAM?
avr6 is fine by me. Especially if it will help in building a correct
library, i.e. with the impending printf_p().
> Given that AVR's flash is organized by 16-bit words, i don't quite
> understand why they didn't use word addressing. This would have saved
> us the nuisance of RAMPZ for 128KB devices...
>
Tell me about it! This drove me nuts when I was working on a
bootloader API. Atmel's documentation could use some improving in
that area.
Also, I've seen some issues at avrfreaks about the current _ELPM()
macro not working for the ATmega128. I wrote a replacement for it
that does work when I wrote the bootloader code. But, I haven't
completely verified that this is an issue.
Eric
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, (continued)
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, Joerg Wunsch, 2002/10/07
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, E. Weddington, 2002/10/07
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, Joerg Wunsch, 2002/10/07
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, E. Weddington, 2002/10/07
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, Joerg Wunsch, 2002/10/08
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?,
E. Weddington <=
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, Marek Michalkiewicz, 2002/10/08
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, Joerg Wunsch, 2002/10/08
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, Marek Michalkiewicz, 2002/10/08
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, Theodore A. Roth, 2002/10/07
- Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, Joerg Wunsch, 2002/10/07