Re: [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?

[E. Weddington]

On 6 Oct 2002 at 23:54, Joerg Wunsch wrote:

> As Joerg Wunsch wrote:
> 
> > Would anybody moan if i removed this line completely?  Otherwise, i
> > might encapsulate it into some #ifdef magic, but i feel that to be
> > ugly.
> 
> Sigh.  It's not quite that easy.  Further definitions rely on
> the definitions from ina90.h.  So i suggest the following.  It
> also changes all non-compat internal definitions to use two
> prepended underscores.

I like the change, it makes more sense to keep *just* IAR 
compatibility stuff in ina90.h.

I only have one nit, having to do with underscores. I've seen where 
other people have used _LPM(). With these changes, it will be 
__LPM(), but you include the definition with 1 underscore in ina90.h. 
I don't necessarily think that the "1 underscore definition" would be 
used exclusively with compatibility code, i.e. other people have used 
_LPM() because of reasons not having to do with IAR compatibility.

Perhaps have the 2 underscore definition, and also define a 1 
underscore definition, in pgmspace.h, but as a deprecation.

> 
> Still, user programs need to include <avr/io.h> before in order
> to define RAMPZ.  This is only actually needed when ELPM is used, so
> my stdio stuff won't stumple across it.  Anyway, in Ted's course of
> centralizing the common declarations of the various ioXXXX.h files,
> RAMPZ should probably be declared based on the architecture flag
> (avr5?) as opposed to based on the actual MCU type.  That way, library
> code code still include <avr/io.h> and get some useful definitions
> whithout the requirement to explicitly specify an MCU type.  This
> would also help eliminating the magic numbers for the SP_L/SP_H
> registers in malloc.c.

I'm not so sure about this one....

Ted, am I mistaken or didn't you just post a patch changing the 
ioXXXX.h files to give an error if an MCU type wasn't defined?

Also, RAMPZ is defined at a particular address for the MCU. This 
definition / address could change for a different MCU according to 
Atmels' whim. It doesn't seem like it would be good, then, to tie it 
to a particular architecture. ELPM and the ESPM instruction uses the 
RAMPZ register, which in turn is based on the MCU type. It makes 
sense to keep the current system of checking if RAMPZ is defined in 
any definition that uses ELPM and ESPM.

Eric