Hi, I have some experience with CVS and SVN (and everyday I wish my job would dump VSS for just about anything else).
As for the name, back in the days I found that avr-drv was simple and stand for what it mean, that is just my opinion. avr-libc-drv or something else would still make sence since it is an C library after all. On the other hand, if you look at most Linux library, they do not include the libc or libc++ as, I believe, it makes the name heavier for no big reason. As a side note, avr-drv is basicaly a dump of what I wrote in university for various project and I put it on the web on the request of someone. Beside the API, I believe the following are issues: - Code repository: I originally chose google code for it simplicity. savannah might be better since it has bug tracking etc.. - Compile as library or...: It is sure simple to simply include a library than to compile the UART for every single project. - License: big discussion on AVR-Freaks about that. My opinion is: - to go with savannah. It is feature rich and already host of avr-libc. - I would prefer to distribute is as a library, altough it is far more complicated. - I would use BSD as it is less restrictive than GPL. If you look into my project, you'll find at least an API for: ADC, USART, SPI, and CAN USART is far from complete though, but all these could serve as a starting ground. My code used function like spiEnable(true/false) function, but I think that it could be more efficient size wise and speed wise to have inline macro like spiEnable() and spiDisable(). I'll see tomorow if I can put an even more upto date version of my code online. On Thu, Sep 17, 2009 at 5:09 PM, Ruddick Lawrence <rudd...@stanford.edu> wrote: > I'm game if Ron and Frédéric are willing. I have extensively used the > simpler aspects of SVN (ie, no branching or merging), and I hear CVS is > similar enough. > > I agree we should move further discussion to a dedicated list in order to > stop bugging people here who are uninterested. As for the name, do we want > to tie it to avr-libc in any way (but not as confusingly as Procyon AVRlib > did...)? Something along the lines of avr-libc-extension. Or it can be > completely whimsical, such as avr-packmule (it does the heavy lifting). > > Ruddick > > On Thu, Sep 17, 2009 at 12:35 PM, Joerg Wunsch <j...@uriah.heep.sax.de> 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. >> >> -- >> cheers, J"org .-.-. --... ...-- -.. . DL8DTL >> >> http://www.sax.de/~joerg/ <http://www.sax.de/%7Ejoerg/> >> NIC: JW11-RIPE >> Never trust an operating system you don't have sources for. ;-) >> >> >> _______________________________________________ >> AVR-libc-dev mailing list >> AVR-libc-dev@nongnu.org >> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev >> > _______________________________________________ > AVR-libc-dev mailing list > AVR-libc-dev@nongnu.org > http://lists.nongnu.org/mailman/listinfo/avr-libc-dev > -- Frédéric Nadeau ing. jr _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
