[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] avr-lib-c-extentions library
From: |
David Bourgeois |
Subject: |
Re: [avr-libc-dev] avr-lib-c-extentions library |
Date: |
Mon, 07 Jan 2008 17:32:52 +0100 |
User-agent: |
Opera Mail/9.50 (Linux) |
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.)
- 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?_requestid=455589
)
- maybe a MCP2515 driver.
A couple of questions/thoughts are emerging:
- What quality level should we achieve in order for you to consider
inclusion?
- 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.
- 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. 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). There are a lot of
ressources on embedded.com and AVRFreaks. Even if you expect avr-libc
developers to already have that background, it could help others submit
better patches and contributions.
- 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 think it would also be important to have an example of how to use the
library. 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.
- 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. On the other
hand, there's already AVRFreaks.
- I guess there will be a new ML for that.
Just my 2 cents though.
David Bourgeois
- RE: [avr-libc-dev] avr-lib-c-extentions library, (continued)
Re: [avr-libc-dev] avr-lib-c-extentions library, David Brown, 2008/01/03
- RE: [avr-libc-dev] avr-lib-c-extentions library, Weddington, Eric, 2008/01/03
- Re: [avr-libc-dev] avr-lib-c-extentions library, Joerg Wunsch, 2008/01/03
- RE: [avr-libc-dev] avr-lib-c-extentions library, Weddington, Eric, 2008/01/03
- Re: [avr-libc-dev] avr-lib-c-extentions library, Joerg Wunsch, 2008/01/03
- RE: [avr-libc-dev] avr-lib-c-extentions library, Weddington, Eric, 2008/01/03
Re: [avr-libc-dev] avr-lib-c-extentions library, David Brown, 2008/01/04
Re: [avr-libc-dev] avr-lib-c-extentions library,
David Bourgeois <=