Re: [avr-libc-dev] Ordered todo

[Joerg Wunsch]

As E. Weddington wrote:

> Lastly, should the "port newlib" item be dropped? i.e. how useful is 
> this item?

I think it's not useful at all, but i don't know who has ever put it
onto this list.  Marek?

I've already moved it to the bottom for that reason. ;-)

> Before avr-libc 1.0
>  - Doxument the following:
>    * interfaces in:
>      + include/avr/crc16.h  ???
>      + include/avr/delay.h  ???
>      + include/avr/ina90.h  ???

I'd wish to move that to include/compat/ina90.h.  Documentation could
probably be sparse, just mention that it's there for IAR
compatibility.

I'd also like to see the following two files in include/compat/.  For
version 1.0, we do supply the wrappers directly under include/ anyway
that issue a warning.  In later revisions, we could drop them if we
prefer.

>      + include/avr/timer.h (move to examples?)

See above.  Many people think it's not useful in any way at all, and
it's sheer impossible to get it to a point where it could be useful
enough to save people some work.

>      + include/avr/twi.h (move to examples?)

Perhaps suitable for examples, but only together with a genuine
example (like an I²C EEPROM driver or something like that).

>      + include/avr/wdt.h (move to examples?)

This one could be kept, IMHO.  Fairly useful, basically a complete
interface for the watchdog, and keeps all the hairy details away
from the luser.  I could document it.

>      + include/avr/parity.h (move to examples?)

I think that's a nice one to keep, but wouldn't mind moving it to
examples.  The only alternative i know of is from the BSD fortune
database:

#define BITCOUNT(x)     (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255)
#define  BX_(x)         ((x) - (((x)>>1)&0x77777777)                    \
                             - (((x)>>2)&0x33333333)                    \
                             - (((x)>>3)&0x11111111))

                -- really weird C code to count the number of bits in a word

Stripped down to 8-bit integers, it'll still yield some more code
than Marek's assembler version.

>    * the mechanism behind include/avr/io*.h ???

I wish we could move out the common register definitions into
<avr/io.h> itself before 1.0 as well.  So far, that's at least SREG,
SPL, SPH.  Doing so would allow us to remove some `magic numbers' from
a few library C files (like malloc(3) that needs to know about the
stack pointer).  Perhaps it'd even allow us to move the compilation of
the assembler (.S) library files away from faked -m<cpu> flags to
-m<architecture>.

Ted, didn't you say you want to do that some day?  Otherwise i might
look into that, too.

>    * merge chapter 3 from Rich Neswold's doc. Needs some rewriting to
>      update for newer tools. (explanation of start code)

Hmm. :)

>    * gcrt1.S

Hmm.  Part of that is already explained in Ted's section about memory
sections.

>  - Document how to pre-program the EEPROM.

Hmm, hmm.  Wasn't there something already?  I remember that someone
submitted a bugfix (fix offset for avr-objcopy).

>  - Figure out how to remove __ prefix from function args in dox.

That's nothing to do before 1.0.  By now, we simply gotta live with
it.  One idea would be to move all the documentation away from the
header files into the respective source file, where we don't need to
care for potentially weird user macros that could shoot into our feet.

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