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

[Frédéric Nadeau]

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 <address@hidden> 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 <address@hidden> 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
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>



-- 
Frédéric Nadeau ing. jr