[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Change EEPROM SFR definition.

From: Anatoly Sokolov
Subject: Re: [avr-libc-dev] Change EEPROM SFR definition.
Date: Fri, 1 Jul 2005 01:08:33 +0400


As Anatoly Sokolov wrote:

>>1.To define EEPROM SFR and corresponding bits in device ioXXXXX.h

>>2. In io.h for support EEPROM library define EEPROM SFR only if
>>any of __ AVR_device __ is not defined and defined __

>I don't see much point in changing it right now.

I see two reasons to make it now: 1. Fix bug #13290; 2. After
addition of support of new devices it will be necessary to correct
more files.

In retrospect, I see your point now.

Yes, I agree with you on this, Anatoly.  As we know we'll eventually
have to move out the EE* register and bit names back into each
individual ioXXX.h file, it's really the time to do it now.  Then,
embrace the existing definitions in avr/io.h within an #if defined
__COMPILING_AVR_LIBC__, and the status quo will be maintained.  (No
need to check for the __AVR_device__ macros, as the macro
__COMPILING_AVR_LIBC__ is only ever supposed to be set within
avr-libc's compilation process, and then we know there's no -mmcu
option in effect.)

Are you willing to do that?

Yes, I shall do that.

Btw., I'd really like to see the EEPROM issue fixed for the next
release of avr-libc, one way or the other.  I'm a bit reluctant to
move the entire EEPROM handling into inline functions (for possible
code bloat reasons) but unless we can come up with a per-device
library solution quickly, I think the inline/macro approach would at
least be fine as a workaround that can even be applied inside the 1.2
version line.

cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

AVR-libc-dev mailing list


reply via email to

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