avr-libc-dev
[Top][All Lists]
Advanced

[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




reply via email to

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