RE: [avr-libc-dev] avr-lib-c-extentions library

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of David Bourgeois
> Sent: Monday, January 07, 2008 9:33 AM
> To: address@hidden
> Subject: Re: [avr-libc-dev] avr-lib-c-extentions library
> 
> Hi folks,
> 
> On Wed, 02 Jan 2008 22:12:37 +0100, Joerg Wunsch <address@hidden>
> wrote:
> 
> > My major criteria for inclusion would be:
> >
> > . general usability (i.e. covers at least a good number of 
> AVRs if not
> >   all of them)
> >
> > . same license as avr-libc to improve re-usability in closed source
> >   projects (that's the major distinction from Procyon AVRlib)
> >
> > . only include contributions where it is ensured that we (i.e. the
> >   current or perhaps future avr-libc developers) are really able to
> >   actively maintain it with the same dedication as avr-libc is being
> >   maintained
> >
> 
> I also thought about such a library some time ago and I'm 
> very happy such
> a project will get started. I may also consider a couple 
> stuff I'd be glad
> to share:
> 
> - a circular buffer (I spent quite some time on this one to 
> get it clean
> and optimized.)

I also have a ring buffer implementation that's been tested.
 
> - an I2C library (I made one inspired from Procyon AVRlib but want to
> rebuild a new one based on this:
> http://www.embedded.com/columns/technicalinsights/186500781?_r
> equestid=455589
> )

I would be interested in an I2C/TWI library.
 
> - maybe a MCP2515 driver.
> 
> A couple of questions/thoughts are emerging:
> 
> - What quality level should we achieve in order for you to consider
> inclusion?

Here are some random thoughts:
- Code tested on real hardware.
- Unit tests for any API.
- Clear documentation (as you mentioned below, I lean towards doxygen)
including any/all limitations with the library.
- For any on-board peripheral driver, it should be designed with
thoughts of having it work across most/all AVR devices (where the
peripheral exists). I'm certainly ok if it's not yet tested/ported to
all AVR devices, but it should be flexible enough to do this sometime in
the future.
- Code examples

All of the above, I would think, should be pretty obvious.
 
> - Shouldn't you have, like for linux distributions, 
> maintainers for each
> package. This way there's at least one person to look at the 
> bug reports
> and apply patches.

I would certainly hope for that, but if we're basing this library on
volunteers, then we're dependent on volunteers to do the continual
maintenance. I can guarantee that I am interested in heading up and some
maintenance of such a project because of my capacity as a Product
Manager in the AVR Tools Group of Atmel. I will also be looking into
additional resources in the near future.
 
> - There should be some code guidelines in order to have consistency
> throughout the library. Avr-libc is usually a good source of 
> inspiration
> for me. 

Then let it be the same style guidelines as avr-libc.

> Beside style guidelines, some pointers to what you 
> consider good
> practice would maybe be interesting (modular programming, use 
> of const,
> static, extern, what should be in the interface). 

If the project is a library, then take a look at the avr-libc user
manaual on how to build a library:
<http://www.nongnu.org/avr-libc/user-manual/library.html>
It talks a little about how to organize one.

> - There should be some documentation with the modules. I hope Doxygen
> would behave better with such a library than it does with avr-libc,
> otherwise is there any better alternative?

I don't know of a better alternative. I would prefer the "devil we
know", and stick with doxygen.
 
> - I think it would also be important to have an example of 
> how to use the
> library. 

Agreed. It's essential.

> I still didn't look at it but can't we reuse the 
> test framework
> already in avr-libc? Regression tests usually serve as good 
> examples of
> how to use the code, and of course check for regressions. But 
> I still have
> no idea how to do such tests with modules that depend on hardware.

Pick a standard (hardware) platform that the tests should run on. I
would lean towards using the new STK600 platform (it should be able to
handle newer devices). Specify in the test documentation any special
wiring needed to run certain tests. The more automated the better. 
 
> - Shouldn't there be an official library which is considered 
> stable and
> meet the requirements, and a kind of playground section or playground
> library where more people could contribute. When a module is 
> considered
> good, it can be moved to the official library. It's always 
> better if the
> community has a way to easily bring small contributions. 

Good idea. Yes, something like that should be incorporated.

> - On the other
> hand, there's already AVRFreaks.

Projects have a tendence to get a little lost. They're working on
overhauling their projects system.
 
> - I guess there will be a new ML for that.

Eventually, I suppose. But I'm ok with avr-libc-dev for now, unless
anyone has objections.

Eric Weddington