Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc

[David Brown]

Joerg Wunsch wrote:
> As Ron Kreymborg wrote:
>
> > I now have a little more spare time, so would be willing to join as
> > a volunteer for this library.
>
>
> As Frédéric Nadeau wrote:
>
> > I started such a project at the beginning of the year. Please check
> > at: http://code.google.com/p/avr-drv/
>
> > [...] I'm
> > willing to work on that and would see no objection to actully give
> > that code to the AVR-LIBC project.
>
>
> As Ruddick Lawrence wrote:
>
> > I am willing to help develop and maintain such a library [...]
>
>
> Cool!  That makes three of you, I think that's enough for a start.
>
>
> How to proceed from here?  Do you all have CVS experience?  I think
> the next step would be to discuss an API.  I think it might make sense
> to setup a different developers list so things like that API
> discussion could be done there.  Oh, that also asks for a name for the
> new library then ;-), as that name should probably be reflected in the
> name of the mailing list.
>
> What do you thkin about it?
>
>
> As Ruddick Lawrence wrote:
>
> > ..., but I am more enthusiasm than experience, and
> > obviously it would need more developers.
>
> I'm willing to act as a consultant for technical details, like
> organization of the CVS tree, and I could get you going on how to roll
> a release.  If you are willing to establish an autoconf/automake
> infrastructure, you could basically re-use the release preparation
> instructions from avr-libc (which are described in detail in the
> documentation).
>
>
> As Ron Kreymborg wrote:
>
> > I guess it would be a library of modules with a documented API for
> > each. The trick would be to ensure any common code in modules from
> > various contributors is extracted out into the one place. Otherwise
> > including more than one module could mean possible code duplication.
>
> Well, that certainly needs to be discussed.  But don't worry too much,
> a consistent and relatively stable API is more important than details
> like how to avoid code duplication.  Then, as long as you stay with
> the API once agreed to, anything else will be details internal to the
> library, which could be easily changed between releases.

Can I add a few comments here?  First I'd like to applaud the volunteers 
here - enthusiasm is more important than experience for a project like 
this, and I think it is great that you are able and willing to spend 
time on this library project.  The world of embedded development has too 
many people like me - lots of experience, but little time to spread it 
around since we work too much!

One thing I'd like to suggest is that the "library" be divided into 
separate areas.  In particular, I'd like to see a "stable" area and a 
"staging" or "experimental" area.  A module will only be moved into the 
stable area after it has been well tested on a variety of devices, 
documented, and after the maintainers and the mailing list have 
generally agreed that it is ready.  These will be modules that users can 
rely on, and which the library maintainers are committed to maintaining 
over time.

The "staging" area would be for modules that are proposals.  They should 
be good enough for people to make use of if they want, but there are no 
guarantees about stability of the code or the APIs.  This gives you an 
area for code that you'd like to see tested by others, without the risk 
of being stuck with a sub-optimal API or implementation.

There may also be a "what you see is all you get" area, where you can 
keep code that is donated but not documented, maintained, tested, or 
otherwise ready for the main library.  This would provide a cheap entry 
point for people who could provide code, and users can take it or leave 
it.  If the code looks generally useful, it could then provide a 
starting point for a full library module.  This should of course not 
just be a dumping ground for any old code.

What I'm aiming at here is a way to get more code into the project, and 
to allow different levels of completion (including documentation, 
generalisation, testing, ABI stability, code style, and commitment to 
maintenance) for different modules.  Modules of common use to beginners 
must have a higher standard and ease of use than unusual modules useful 
only to a few.  And it is very important that these distinctions are 
made clearly, so that users know what they are getting.


Joerg has suggested using avr-libc's system for building and 
infrastructure, which would be a good starting point.  However, I think 
you should be open to other ways to use the code than as a traditional 
static library build combined with header files.

For some modules and uses, it could be more practical for users to 
simply add the module's C and header files to their project.  There are 
several advantages to this - debugging is easier, code optimisation is 
better (it will compiled with the same flags as the rest of the project, 
possibly including --combine and -fwhole-program), it is easier to keep 
the code stable (especially if the module is not from the "stable" 
area), and it is easier to modify the code.

Making the modules re-usable in this way might mean more effort is 
needed in making the modules stand-alone, or at least with clearly 
specified interdependencies.  This is perhaps a good thing in general, 
as modules will typically be written by different people.  Another issue 
is licensing, although I think the avr-libc license allows such use even 
with modifications to the library modules.


You might also want to have areas set up as a wiki for information, and 
perhaps areas for sample code (either full demo programs or code 
snippets).  But that would perhaps be stretching the scope of the 
project too far.


On a practical point, having a separate mailing list is a good idea, but 
with announcements copied to the related lists (like this one).  It 
would also be nice to have the list registered at gmane.org - I find 
gmane.org very convenient for many of the lists I follow.


mvh.,

David