Hi folks, On Wed, 02 Jan 2008 22:12:37 +0100, Joerg Wunsch <[EMAIL PROTECTED]> 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 _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
