Re: [avr-libc-dev] Ordered todo.

[Joerg Wunsch]

José,

first, thanks for your opinion!

As José Ildefonso Camargo Tolosa) wrote:

> So, my suggestion is: keep the definitions for each device inside
> the device's file, even if the definition is the same in all
> devices.  Why?, well, just because it is easier to add new devices,
> even if they differ a lot.

Well, you've somewhat missed the point of all this.

The suggested change simply moves those registers to the central
<avr/io.h> file that are essential for either the compiler or the
library:

. SREG
. X, Y, Z pointers
. SP

All of these are used by the compiler in a `generic' way, so unless we
really want to create one library version (i. e., multiple .a files)
for /each and any/ supported device, we by now heavily rely on these
registers being at fixed locations.  Thus moving the respective
definitions to a central file will basically only document this
dependency.

Also, libc/stdlib/malloc.c used to have a private hack that
effectively redeclared yet another name for the stack pointer
register, since there was no way for the library to use the names from
<avr/io.h>.  This was one of the motivations behind the move.

. the EEPROM registers

The idea to move these to the central file only occurred to me since
having them distributed was the reason to implement a gross hack in
the build infrastructure: in order to compile (actually assemble) the
EEPROM-related library functions, the assembler has been called with
`fake' -mmcu options instead of generic options.  E. g. when
assembling the library for the avr2 architecture, an AT90S8515 had to
be assumed in order to get <avr/io.h> to actually define the EEPROM-
related registers.  This hack seemed so terrible to me that i sought
to get rid of it.  As it turned out, i should be right about it:
nobody even /noticed/ the different locations of the EEPROM registers
for the ATmega169 before (which cause the EEPROM library functions to
not apply to this device) since the difference was well hidden in the
tree.  Now we can at least document this.

Should the diversity regarding register locations in the AVR increase
in future, we need to overthink the current concept of having 5
different AVR `architectures' (avr1, which is assembler-only, through
avr5) that can each share a single compiled object file among all the
actual devices in their class.  Maybe we really need to compile one
library for each device then.  But let's hope Atmel is at least
keeping the registers mentioned above at fixed places in future.

> This comment is based on my own experience adding new devices to
> avr-libc, about two months ago I added support for ATmega16 to the
> avr-libc that I had (I had not found the savannah site then), and I
> found it really easy because I only had to add one file and modify
> some makefiles.

Well, adding a new device with the new <avr/io.h> file is neither less
nor more work.  Since you're probably usually starting out using one
of the existing <avr/ioXXX.h> files as a template, you would not even
notice the difference.

> Additionally, I would like to suggest that you add some definitions
> for "inter-device" compatibility.  For example, in the ATmega16 the
> UBRR register pair is: UBRRL and UBRRH, but in the ATmega128, due
> that it have two USARTs, it have UBRR0L and UBRR0H and UBRR1L and
> UBRR1H.  So, for the ATmega16 (or any other that have just one
> USART), I would define:

> #ifdef UBRRL   //UBRRL would be defined ONLY if there is just one USART
> #define UBRR0L UBRRL
> #define UBRR0H UBRRH
> #endif

Opinions differ.  E. g., in my application (see test.c in my previous
mail), i defined UBRRL to UBRR1L since that was the default UART on my
test circuit.  By now, we rather restricted the files to ship all the
names that are present in the datasheet.

I think this kind of interoperability defines are better kept in local
files within a project that is meant to work on different devices.
There are so many other things to care about, e. g. in the ATmega128,
the UART baud rate registers are 16-bit, so when `back-porting' that
code to a smaller device you need to make sure to not overflow their
8-bit UBRR.

If at all, we might write up something that ends up as
<compat/avr_compat.h> and that holds this kind of interoperability
defines.  That way, it's up to the user to decide whether he wants
this feature or not.  We need more user input on what should appear in
that file though (your input is a starting point).

However, something i'd like to see is that we provide files with
matching name schemes for port bit numbering.  Right now, most files
declare things like PA0 for bit 0 in port A, PB0 for bit 0 in port B,
etc.  That's the way that is also used in the datasheets.  However, in
<avr/iom128.h>, only generic symbols (PORT0..PORT7) are available for
the bit numbers, even though the datasheet is structured in the same
way as for other devices.

OTOH, i like the generic names much more.  Using the port-bound names
would make the following a moot point:

#define LCD    PORTA
#define LCD_D4 PA0
#define LCD_D5 PA1
...

Now, say you want to move your LCD from port A to port B: you'd end up
with using PA0, PA1, ... still for port B then.  Just having the
generic constants everywhere would prevent us from that dilemma.  Or,
we simply drop these no-op constants, and people would just use the
bit numbers directly...

So i'd say we should provide both: the generic constants, but also add
the datasheet-conformant names to avr/iom128.h.  Now, the generic
constants could easily be added to the central avr/io.h file again,
saving us the need to edit a thousand files again in order to add
them.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/