[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: |
Mon, 07 Oct 2002 10:23:25 -0600 |
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
- [avr-libc-dev] Why include <ina90.h> from <avr/pgmspace.h>?, Joerg Wunsch, 2002/10/06
- 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, 2002/10/08