[Top][All Lists]

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

RE: [avr-libc-dev] [RFC] Reorganizing io.h and common registers

From: Eric Weddington
Subject: RE: [avr-libc-dev] [RFC] Reorganizing io.h and common registers
Date: Wed, 06 Jun 2007 17:41:59 -0600

Mailer error.
The patches should be attached now.


> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Eric Weddington
> Sent: Wednesday, June 06, 2007 5:39 PM
> To: address@hidden
> Subject: [avr-libc-dev] [RFC] Reorganizing io.h and common registers
> Hello All,
> See attached patches for 1.4 branch and HEAD.
> This patch reorganizes avr/io.h a bit. A new file is created, 
> avr/common.h.
> The purpose of this file is to hold register and symbol 
> definitions that are
> common across AVR devices and families. It defines common 
> registers that
> have not previously been defined in the individual IO header 
> files (e.g. the
> stack pointer and status registers), and it also defines 
> generic names for
> some registers that are common across devices and families. 
> avr/common.h is
> #included in avr/io.h *after* the individual IO header files. 
> Therefore many
> definitions in avr/io.h have been moved to avr/common.h. 
> There have been
> some of the assembler files in avr-libc that use common register
> definitions, and these have been changed to use the generic 
> symbols defined
> now in avr/common.h. Lastly, there is a small change to get 
> avr/io.h back
> into the documentation.
> The main reason to do all this is to organize this a bit 
> better for future
> support of new devices. Also, in the future, generic definitions of
> registers where the names are different between devices, such as in
> avr/wdt.h, avr/sleep.h, avr/power.h, etc., could be placed in 
> avr/common.h.
> These generic definitions are not prefixed with an 
> underscore, with the idea
> that they should also be available for public use. However, 
> they are not
> currently doxygenified, but could be in the near future. The 
> point is to get
> this changed ASAP.
> Let me know if anyone sees anything missing, or if something 
> might need to
> be added, or rearranged. However, I'm not inclined to quibble 
> over every
> detail. These changes are very necessary and I would like to 
> get them in
> soon. If there are no significant objections, I will commit 
> these patches on
> Friday.
> Thanks,
> Eric Weddington 

reply via email to

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