Adding (some) Procyon AVRlib functionality to avr-libc

[Ruddick Lawrence]

This conversation is continued from the avrfreaks forum posting here:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=84072.
Basically, we were talking about how best to create a maintained version of
the functionality in the Procyon AVRlib, and whether there's a place for
such code in avr-libc.

Eric, in your post you said you were "willing to accept code that would
provide drivers for internal peripherals into AVR-LibC." I assume this means
that utility code to simplify using UART or timers (etc) is appropriate, but
an LCD driver is not. Other code, such as buffer and IP utilities, is more
of a gray area (at least to me). I guess the first thing to figure out is
how you (and the other developers/maintainers) define the scope of avr-libc,
and how best to design a complementary library (if at all) to house useful
code that is outside of that scope.

Ruddick
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Joerg Wunsch]

As Ruddick Lawrence wrote:

> I guess the first thing to figure out is
> how you (and the other developers/maintainers) define the scope of avr-libc,
> and how best to design a complementary library (if at all) to house useful
> code that is outside of that scope.

Ideally, if there were enough volunteers to develop *and* maintain
such a library (this includes maintaining documentation, handling bug
and patch tracker submissions, rolling releases etc.), I could think
of the avr-libc project being able to house it as a relatively
standalone project.  It could get a separate top-level directory in
the CVS tree, and roll separate releases from there.

That way, users could decide whether they just need the low-level
stuff from avr-libc, or want a higher level of abstraction, and install
a second library on top of that.

However, the biggest issue with that approach is finding enough people
who are willing to actively work on that.  I don't see those who
currently maintain avr-libc having enough vacant resources to manage
such a project.  (That doesn't mean we were completely "out" of such a
project, it's only we've got our hands full with maintaining the
current state of avr-libc.)

So, volunteers welcome. ;-)

Lacking that, I agree with Eric that some fairly low-level interface
abstractions might also go into the "classic" avr-libc, thereby
extending its scope a bit.  However, if there were enough developers
for a separate library, its scope could be much beyond the current
avr-libc, so things like a generic HD44780 driver API could be there
as well.  (Feel free to pick the current implementation from the
stdioexample as a starting point.)

I agree to the person in that thread about the GPL issue; in order to
keep such a project under the roof of avr-libc, I'd say using the same
licensing conditions as avr-libc is pretty much mandatory, as this has
shown to cause the least trouble to every potential user so far.  This
in turn would not allow re-using code of Pascal Stang's library, but
of course, re-using ideas or APIs does not constitute a licensing
issue.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Ron Kreymborg]

I now have a little more spare time, so would be willing to join as a
volunteer for this library.

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.

Ron Kreymborg

> -----Original Message-----
> From: avr-libc-dev-bounces+ron=jennaron.com.au@... [mailto:avr-
> libc-dev-bounces+ron=jennaron.com.au@...] On Behalf Of Joerg
> Wunsch
> Sent: Thursday, 17 September 2009 6:26 PM
> To: avr-libc-dev@...
> Subject: Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality
> to avr-libc
>
> As Ruddick Lawrence wrote:
>
> > I guess the first thing to figure out is
> > how you (and the other developers/maintainers) define the scope of
> avr-libc,
> > and how best to design a complementary library (if at all) to house
> useful
> > code that is outside of that scope.
>
> Ideally, if there were enough volunteers to develop *and* maintain
> such a library (this includes maintaining documentation, handling bug
> and patch tracker submissions, rolling releases etc.), I could think
> of the avr-libc project being able to house it as a relatively
> standalone project.  It could get a separate top-level directory in
> the CVS tree, and roll separate releases from there.
>
> That way, users could decide whether they just need the low-level
> stuff from avr-libc, or want a higher level of abstraction, and install
> a second library on top of that.
>
> However, the biggest issue with that approach is finding enough people
> who are willing to actively work on that.  I don't see those who
> currently maintain avr-libc having enough vacant resources to manage
> such a project.  (That doesn't mean we were completely "out" of such a
> project, it's only we've got our hands full with maintaining the
> current state of avr-libc.)
>
> So, volunteers welcome. ;-)
>
> Lacking that, I agree with Eric that some fairly low-level interface
> abstractions might also go into the "classic" avr-libc, thereby
> extending its scope a bit.  However, if there were enough developers
> for a separate library, its scope could be much beyond the current
> avr-libc, so things like a generic HD44780 driver API could be there
> as well.  (Feel free to pick the current implementation from the
> stdioexample as a starting point.)
>
> I agree to the person in that thread about the GPL issue; in order to
> keep such a project under the roof of avr-libc, I'd say using the same
> licensing conditions as avr-libc is pretty much mandatory, as this has
> shown to cause the least trouble to every potential user so far.  This
> in turn would not allow re-using code of Pascal Stang's library, but
> of course, re-using ideas or APIs does not constitute a licensing
> issue.
>
> --
> cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL
>
> http://www.sax.de/~joerg/                        NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> AVR-libc-dev@...
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Frédéric Nadeau-2]

Hi there,

I started such a project at the beginning of the year. Please check at:
http://code.google.com/p/avr-drv/

Still incomplete, but most is working and tested. It is currently
under BSD license and does not have anything to do with Procyon. I'm
willing to work on that and would see no objection to actully give
that code to the AVR-LIBC project.

Someone knows what happend to the idea of adding pin description in io.h?

Best regard

--
Frédéric Nadeau ing. jr



On Thu, Sep 17, 2009 at 7:14 AM, Ron Kreymborg <ron@...> wrote:

> I now have a little more spare time, so would be willing to join as a
> volunteer for this library.
>
> 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.
>
> Ron Kreymborg
>
>
>> -----Original Message-----
>> From: avr-libc-dev-bounces+ron=jennaron.com.au@... [mailto:avr-
>> libc-dev-bounces+ron=jennaron.com.au@...] On Behalf Of Joerg
>> Wunsch
>> Sent: Thursday, 17 September 2009 6:26 PM
>> To: avr-libc-dev@...
>> Subject: Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality
>> to avr-libc
>>
>> As Ruddick Lawrence wrote:
>>
>> > I guess the first thing to figure out is
>> > how you (and the other developers/maintainers) define the scope of
>> avr-libc,
>> > and how best to design a complementary library (if at all) to house
>> useful
>> > code that is outside of that scope.
>>
>> Ideally, if there were enough volunteers to develop *and* maintain
>> such a library (this includes maintaining documentation, handling bug
>> and patch tracker submissions, rolling releases etc.), I could think
>> of the avr-libc project being able to house it as a relatively
>> standalone project.  It could get a separate top-level directory in
>> the CVS tree, and roll separate releases from there.
>>
>> That way, users could decide whether they just need the low-level
>> stuff from avr-libc, or want a higher level of abstraction, and install
>> a second library on top of that.
>>
>> However, the biggest issue with that approach is finding enough people
>> who are willing to actively work on that.  I don't see those who
>> currently maintain avr-libc having enough vacant resources to manage
>> such a project.  (That doesn't mean we were completely "out" of such a
>> project, it's only we've got our hands full with maintaining the
>> current state of avr-libc.)
>>
>> So, volunteers welcome. ;-)
>>
>> Lacking that, I agree with Eric that some fairly low-level interface
>> abstractions might also go into the "classic" avr-libc, thereby
>> extending its scope a bit.  However, if there were enough developers
>> for a separate library, its scope could be much beyond the current
>> avr-libc, so things like a generic HD44780 driver API could be there
>> as well.  (Feel free to pick the current implementation from the
>> stdioexample as a starting point.)
>>
>> I agree to the person in that thread about the GPL issue; in order to
>> keep such a project under the roof of avr-libc, I'd say using the same
>> licensing conditions as avr-libc is pretty much mandatory, as this has
>> shown to cause the least trouble to every potential user so far.  This
>> in turn would not allow re-using code of Pascal Stang's library, but
>> of course, re-using ideas or APIs does not constitute a licensing
>> issue.
>>
>> --
>> cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL
>>
>> http://www.sax.de/~joerg/                        NIC: JW11-RIPE
>> Never trust an operating system you don't have sources for. ;-)
>>
>>
>> _______________________________________________
>> AVR-libc-dev mailing list
>> AVR-libc-dev@...
>> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> AVR-libc-dev@...
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Ruddick Lawrence]

I am willing to help develop and maintain such a library (I was the original
poster, mrjogo, fyi), but I am more enthusiasm than experience, and
obviously it would need more developers. Are other people on this list
interested in helping with this (donating code, but more specifically the
longer-term commitment to maintaining it)? I think it could be a valuable
addition to avr-libc and the AVR community.

Ruddick

On Thu, Sep 17, 2009 at 1:25 AM, Joerg Wunsch <j@...> wrote:

> As Ruddick Lawrence wrote:
>
> > I guess the first thing to figure out is
> > how you (and the other developers/maintainers) define the scope of
> avr-libc,
> > and how best to design a complementary library (if at all) to house
> useful
> > code that is outside of that scope.
>
> Ideally, if there were enough volunteers to develop *and* maintain
> such a library (this includes maintaining documentation, handling bug
> and patch tracker submissions, rolling releases etc.), I could think
> of the avr-libc project being able to house it as a relatively
> standalone project.  It could get a separate top-level directory in
> the CVS tree, and roll separate releases from there.
>
> That way, users could decide whether they just need the low-level
> stuff from avr-libc, or want a higher level of abstraction, and install
> a second library on top of that.
>
> However, the biggest issue with that approach is finding enough people
> who are willing to actively work on that.  I don't see those who
> currently maintain avr-libc having enough vacant resources to manage
> such a project.  (That doesn't mean we were completely "out" of such a
> project, it's only we've got our hands full with maintaining the
> current state of avr-libc.)
>
> So, volunteers welcome. ;-)
>
> Lacking that, I agree with Eric that some fairly low-level interface
> abstractions might also go into the "classic" avr-libc, thereby
> extending its scope a bit.  However, if there were enough developers
> for a separate library, its scope could be much beyond the current
> avr-libc, so things like a generic HD44780 driver API could be there
> as well.  (Feel free to pick the current implementation from the
> stdioexample as a starting point.)
>
> I agree to the person in that thread about the GPL issue; in order to
> keep such a project under the roof of avr-libc, I'd say using the same
> licensing conditions as avr-libc is pretty much mandatory, as this has
> shown to cause the least trouble to every potential user so far.  This
> in turn would not allow re-using code of Pascal Stang's library, but
> of course, re-using ideas or APIs does not constitute a licensing
> issue.
>
> --
> 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@...
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Joerg Wunsch]

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/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Joerg Wunsch]

As Frédéric Nadeau wrote:

> Someone knows what happend to the idea of adding pin description in
> io.h?

No, what are you referring to?

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Ruddick Lawrence]

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@...> 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@...
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Frédéric Nadeau-2]

Reference is here:
bug #25300 : Additional i/o port names
http://savannah.nongnu.org/bugs/?25300

On Thu, Sep 17, 2009 at 3:35 PM, Joerg Wunsch <j@...> wrote:

> As Frédéric Nadeau wrote:
>
>> Someone knows what happend to the idea of adding pin description in
>> io.h?
>
> No, what are you referring to?
>
> --
> cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL
>
> http://www.sax.de/~joerg/                        NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> AVR-libc-dev@...
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>

--
Frédéric Nadeau ing. jr


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Frédéric Nadeau-2]

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

--
Frédéric Nadeau ing. jr


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[David Brown-4]

Joerg Wunsch 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.
>

Can I add a few comments here?  First I'd like to applaud the volunteers
here - enthusiasm is more important than experience for a project like
this, and I think it is great that you are able and willing to spend
time on this library project.  The world of embedded development has too
many people like me - lots of experience, but little time to spread it
around since we work too much!

One thing I'd like to suggest is that the "library" be divided into
separate areas.  In particular, I'd like to see a "stable" area and a
"staging" or "experimental" area.  A module will only be moved into the
stable area after it has been well tested on a variety of devices,
documented, and after the maintainers and the mailing list have
generally agreed that it is ready.  These will be modules that users can
rely on, and which the library maintainers are committed to maintaining
over time.

The "staging" area would be for modules that are proposals.  They should
be good enough for people to make use of if they want, but there are no
guarantees about stability of the code or the APIs.  This gives you an
area for code that you'd like to see tested by others, without the risk
of being stuck with a sub-optimal API or implementation.

There may also be a "what you see is all you get" area, where you can
keep code that is donated but not documented, maintained, tested, or
otherwise ready for the main library.  This would provide a cheap entry
point for people who could provide code, and users can take it or leave
it.  If the code looks generally useful, it could then provide a
starting point for a full library module.  This should of course not
just be a dumping ground for any old code.

What I'm aiming at here is a way to get more code into the project, and
to allow different levels of completion (including documentation,
generalisation, testing, ABI stability, code style, and commitment to
maintenance) for different modules.  Modules of common use to beginners
must have a higher standard and ease of use than unusual modules useful
only to a few.  And it is very important that these distinctions are
made clearly, so that users know what they are getting.


Joerg has suggested using avr-libc's system for building and
infrastructure, which would be a good starting point.  However, I think
you should be open to other ways to use the code than as a traditional
static library build combined with header files.

For some modules and uses, it could be more practical for users to
simply add the module's C and header files to their project.  There are
several advantages to this - debugging is easier, code optimisation is
better (it will compiled with the same flags as the rest of the project,
possibly including --combine and -fwhole-program), it is easier to keep
the code stable (especially if the module is not from the "stable"
area), and it is easier to modify the code.

Making the modules re-usable in this way might mean more effort is
needed in making the modules stand-alone, or at least with clearly
specified interdependencies.  This is perhaps a good thing in general,
as modules will typically be written by different people.  Another issue
is licensing, although I think the avr-libc license allows such use even
with modifications to the library modules.


You might also want to have areas set up as a wiki for information, and
perhaps areas for sample code (either full demo programs or code
snippets).  But that would perhaps be stretching the scope of the
project too far.


On a practical point, having a separate mailing list is a good idea, but
with announcements copied to the related lists (like this one).  It
would also be nice to have the list registered at gmane.org - I find
gmane.org very convenient for many of the lists I follow.


mvh.,

David



_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Ron Kreymborg]

Some thoughts on a library.

Let me start with a library that manages just the processor's internal
peripherals: best practise would have all data structures the code requires
declared as private (static). Data in, data out, exceptions and status would
all be accessible only via public functions (external). Any housekeeping
data would be private. All this probably goes without saying, but now some
very sticky questions need to be answered.

Best practise would also specify that interrupts be used as this makes for
the most efficient use of the peripheral. The "send" side of the code causes
problems in how to handle a busy device. Typically an "are-you-ready"
function will suffice, but others will need tools to add for example,
semaphore access. While these problems are not that difficult the "receive"
side problems are. A polling (status) function could be provided or a
call-back function could signal the host program that "something" has
arrived. The call-back could set a flag the host program eventually actions
in some background loop, but this by definition would be time indeterminate.
Perhaps the module could use a software interrupt so the host can action the
event with some alacrity, but that means defining additional interrupts per
device. And some applications will require the interrupt function be outside
the library module altogether because the data stream simply requires
immediate action. While this could also be a call-back function we are then
stuck with avrgcc stacking every register (the C++ bugbear).

External peripherals are not so bad. Most display drivers for instance are
essentially one way. Most networks (CAN, LIN, etc) are happy with a flag
setting call-back for the packet "receive" side which should be adequate
except where speed is an absolute premium. Thus the internal data structures
for these modules can be safely hidden and a standard set of access
functions written that cover most possibilities.

A library for handling data structures (queues, lists, stacks, trees, etc
(something like a cut down STL)) would also lend itself to a closed library.

My point is that creating this library (or these libraries) is not a case of
us collecting our best bits and bundling them up. While the internals may
not be that hard, I think defining the API for each module will require
considerable discussion.

So Jorg, the idea of a separate list sound good in the long run, but might I
suggest we thrash out the ideas for, say, a USART API here on this list,
keeping in mind the points I raised in the second para. Many of us have
implemented one of these so there will be a good cross section of ideas on
what it should look like and how it should work. Let me suggest some basic
rules:

-------------

1a. All public functions are capitalised with no underscores and prefixed
with up to 4 letters defining the device.

Or conversely:

1b. All public functions are lower case using underscores for readability
with up to 4 letters defining the device.

An example of 1a) would be spiSendMessage, and of 1b) spi_send_message. I
vote for 1a but democracy would rule.

2. All modules which require prior initialisation use the same name for this
function, such as Init or Setup. Eg spiInit or spi_init.

3. All internal data structures are private (static) and only accessible via
public functions. All internal functions are likewise private.

--------------

If this looks like the definition for a C++ class then that is my basic
idea.

David Brown's idea of partial releases for community testing is good. The
library group can internally decide on a peripheral, work out an initial
API, put it out for comment, revise as necessary, implement, release for
beta, and finally release the module integrated into the library. The source
code can be released after adoption as otherwise the suggestions will be
overwhelming. At that point individuals can play with it at their leisure
but the distributed library would only change for bug fixes.

I think enough of us have written this stuff that the code itself is not the
challenge, but defining each module's API so we can all use it for most
projects will be.

All suggestions welcome.
Ron




_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-libc-dev-bounces+eric.weddington=atmel.com@...
> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of Frédéric Nadeau
> Sent: Thursday, September 17, 2009 5:44 PM
> To: avr-libc-dev@...
> Subject: Re: [avr-libc-dev] Adding (some) Procyon AVRlib
> functionality to avr-libc
>
> Reference is here:
> bug #25300 : Additional i/o port names
> http://savannah.nongnu.org/bugs/?25300
>

Hi Frederic,

That is totally my fault, and I owe you a patch review. It has been on my list, but I have been side tracked for the last month or so. Let me look into it over the weekend, and I'll get back to you. I *definitely* want to get this in and *soon*. :-)

Again, my apologies for not getting to this sooner.

Eric Weddington


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-libc-dev-bounces+eric.weddington=atmel.com@...
> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of David Brown
> Sent: Friday, September 18, 2009 1:20 AM
> To: avr-libc-dev@...
> Subject: Re: [avr-libc-dev] Adding (some) Procyon AVRlib
> functionality toavr-libc
>
> Can I add a few comments here?  First I'd like to applaud the
> volunteers
> here - enthusiasm is more important than experience for a
> project like
> this, and I think it is great that you are able and willing to spend
> time on this library project.  The world of embedded
> development has too
> many people like me - lots of experience, but little time to
> spread it
> around since we work too much!

Hi David,

Yes, we definitely need to have some sort of way to organize code into "well-tested" and "experimental" areas.

Yes, it would be nice if code was not delivered as object libraries, but as source code that could be brought into a project.

A wiki is sometimes useful, but has it's own maintenance issues.

And I'm sure we'll set up a separate mailing list.

I definitely appreciate all the help you do, especially helping to answer questions on the mailing lists. However I would suggest strongly that you use your talents even more to help implement your ideas above instead of just the "good idea" list from the sidelines, otherwise it becomes overwhelming for those who are doing the work. I understand time constraints, and it's difficult. So I suggest that you try helping in one area as a start.

Eric Weddington


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Frédéric Nadeau-2]

I volunteer to start the project.

I suggest we open a hosting on Savannha so that we can have a separate
mailing list and start discussion on that specific project. From there
on we could lay out a distribution plan, compilation method, etc.

I would personally name it "avr-drv". Any better name or suggestion?

Thanks
Frédéric Nadeau

On Fri, Sep 18, 2009 at 8:21 AM, Ron Kreymborg <ron@...> wrote:

> Some thoughts on a library.
>
> Let me start with a library that manages just the processor's internal
> peripherals: best practise would have all data structures the code requires
> declared as private (static). Data in, data out, exceptions and status would
> all be accessible only via public functions (external). Any housekeeping
> data would be private. All this probably goes without saying, but now some
> very sticky questions need to be answered.
>
> Best practise would also specify that interrupts be used as this makes for
> the most efficient use of the peripheral. The "send" side of the code causes
> problems in how to handle a busy device. Typically an "are-you-ready"
> function will suffice, but others will need tools to add for example,
> semaphore access. While these problems are not that difficult the "receive"
> side problems are. A polling (status) function could be provided or a
> call-back function could signal the host program that "something" has
> arrived. The call-back could set a flag the host program eventually actions
> in some background loop, but this by definition would be time indeterminate.
> Perhaps the module could use a software interrupt so the host can action the
> event with some alacrity, but that means defining additional interrupts per
> device. And some applications will require the interrupt function be outside
> the library module altogether because the data stream simply requires
> immediate action. While this could also be a call-back function we are then
> stuck with avrgcc stacking every register (the C++ bugbear).
>
> External peripherals are not so bad. Most display drivers for instance are
> essentially one way. Most networks (CAN, LIN, etc) are happy with a flag
> setting call-back for the packet "receive" side which should be adequate
> except where speed is an absolute premium. Thus the internal data structures
> for these modules can be safely hidden and a standard set of access
> functions written that cover most possibilities.
>
> A library for handling data structures (queues, lists, stacks, trees, etc
> (something like a cut down STL)) would also lend itself to a closed library.
>
> My point is that creating this library (or these libraries) is not a case of
> us collecting our best bits and bundling them up. While the internals may
> not be that hard, I think defining the API for each module will require
> considerable discussion.
>
> So Jorg, the idea of a separate list sound good in the long run, but might I
> suggest we thrash out the ideas for, say, a USART API here on this list,
> keeping in mind the points I raised in the second para. Many of us have
> implemented one of these so there will be a good cross section of ideas on
> what it should look like and how it should work. Let me suggest some basic
> rules:
>
> -------------
>
> 1a. All public functions are capitalised with no underscores and prefixed
> with up to 4 letters defining the device.
>
> Or conversely:
>
> 1b. All public functions are lower case using underscores for readability
> with up to 4 letters defining the device.
>
> An example of 1a) would be spiSendMessage, and of 1b) spi_send_message. I
> vote for 1a but democracy would rule.
>
> 2. All modules which require prior initialisation use the same name for this
> function, such as Init or Setup. Eg spiInit or spi_init.
>
> 3. All internal data structures are private (static) and only accessible via
> public functions. All internal functions are likewise private.
>
> --------------
>
> If this looks like the definition for a C++ class then that is my basic
> idea.
>
> David Brown's idea of partial releases for community testing is good. The
> library group can internally decide on a peripheral, work out an initial
> API, put it out for comment, revise as necessary, implement, release for
> beta, and finally release the module integrated into the library. The source
> code can be released after adoption as otherwise the suggestions will be
> overwhelming. At that point individuals can play with it at their leisure
> but the distributed library would only change for bug fixes.
>
> I think enough of us have written this stuff that the code itself is not the
> challenge, but defining each module's API so we can all use it for most
> projects will be.
>
> All suggestions welcome.
> Ron
>
>
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> AVR-libc-dev@...
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>

--
Frédéric Nadeau ing. jr


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Ruddick Lawrence]

I feel that naming it avr-drv restricts is too restrictive for what this
project is, since there has been mention of data structures and other things
besides drivers. The name should be distinctive (to make google searches for
it easier), but it doesn't need to be strictly explanatory, since people
will nonetheless have to look at the documentation/site a little to figure
out what it actually covers.

I still sort of like avr-packmule, but I understand if that's too out there.
How about avr-microutils (possibly too diminutive...)?

As for hosting, I think we should take up Joerg's offer to house us under
the avr-libc project. The project is pretty closely tied to it, and we may
even decide some code should belong there. Plus we can benefit from the
infrastructure they have already set up. I think the big bottle neck right
now is just deciding on a name, which is a silly, but at the same time
important bottleneck...

Ruddick

2009/9/18 Frédéric Nadeau <fred.nadeau@...>

> I volunteer to start the project.
>
> I suggest we open a hosting on Savannha so that we can have a separate
> mailing list and start discussion on that specific project. From there
> on we could lay out a distribution plan, compilation method, etc.
>
> I would personally name it "avr-drv". Any better name or suggestion?
>
> Thanks
> Frédéric Nadeau
>
> On Fri, Sep 18, 2009 at 8:21 AM, Ron Kreymborg <ron@...>
> wrote:
> > Some thoughts on a library.
> >
> > Let me start with a library that manages just the processor's internal
> > peripherals: best practise would have all data structures the code
> requires
> > declared as private (static). Data in, data out, exceptions and status
> would
> > all be accessible only via public functions (external). Any housekeeping
> > data would be private. All this probably goes without saying, but now
> some
> > very sticky questions need to be answered.
> >
> > Best practise would also specify that interrupts be used as this makes
> for
> > the most efficient use of the peripheral. The "send" side of the code
> causes
> > problems in how to handle a busy device. Typically an "are-you-ready"
> > function will suffice, but others will need tools to add for example,
> > semaphore access. While these problems are not that difficult the
> "receive"
> > side problems are. A polling (status) function could be provided or a
> > call-back function could signal the host program that "something" has
> > arrived. The call-back could set a flag the host program eventually
> actions
> > in some background loop, but this by definition would be time
> indeterminate.
> > Perhaps the module could use a software interrupt so the host can action
> the
> > event with some alacrity, but that means defining additional interrupts
> per
> > device. And some applications will require the interrupt function be
> outside
> > the library module altogether because the data stream simply requires
> > immediate action. While this could also be a call-back function we are
> then
> > stuck with avrgcc stacking every register (the C++ bugbear).
> >
> > External peripherals are not so bad. Most display drivers for instance
> are
> > essentially one way. Most networks (CAN, LIN, etc) are happy with a flag
> > setting call-back for the packet "receive" side which should be adequate
> > except where speed is an absolute premium. Thus the internal data
> structures
> > for these modules can be safely hidden and a standard set of access
> > functions written that cover most possibilities.
> >
> > A library for handling data structures (queues, lists, stacks, trees, etc
> > (something like a cut down STL)) would also lend itself to a closed
> library.
> >
> > My point is that creating this library (or these libraries) is not a case
> of
> > us collecting our best bits and bundling them up. While the internals may
> > not be that hard, I think defining the API for each module will require
> > considerable discussion.
> >
> > So Jorg, the idea of a separate list sound good in the long run, but
> might I
> > suggest we thrash out the ideas for, say, a USART API here on this list,
> > keeping in mind the points I raised in the second para. Many of us have
> > implemented one of these so there will be a good cross section of ideas
> on
> > what it should look like and how it should work. Let me suggest some
> basic
> > rules:
> >
> > -------------
> >
> > 1a. All public functions are capitalised with no underscores and prefixed
> > with up to 4 letters defining the device.
> >
> > Or conversely:
> >
> > 1b. All public functions are lower case using underscores for readability
> > with up to 4 letters defining the device.
> >
> > An example of 1a) would be spiSendMessage, and of 1b) spi_send_message. I
> > vote for 1a but democracy would rule.
> >
> > 2. All modules which require prior initialisation use the same name for
> this
> > function, such as Init or Setup. Eg spiInit or spi_init.
> >
> > 3. All internal data structures are private (static) and only accessible
> via
> > public functions. All internal functions are likewise private.
> >
> > --------------
> >
> > If this looks like the definition for a C++ class then that is my basic
> > idea.
> >
> > David Brown's idea of partial releases for community testing is good. The
> > library group can internally decide on a peripheral, work out an initial
> > API, put it out for comment, revise as necessary, implement, release for
> > beta, and finally release the module integrated into the library. The
> source
> > code can be released after adoption as otherwise the suggestions will be
> > overwhelming. At that point individuals can play with it at their leisure
> > but the distributed library would only change for bug fixes.
> >
> > I think enough of us have written this stuff that the code itself is not
> the
> > challenge, but defining each module's API so we can all use it for most
> > projects will be.
> >
> > All suggestions welcome.
> > Ron
> >
> >
> >
> >
> > _______________________________________________
> > AVR-libc-dev mailing list
> > AVR-libc-dev@...
> > http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
> >
>
>
>
> --
> Frédéric Nadeau ing. jr
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> AVR-libc-dev@...
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-libc-dev-bounces+eric.weddington=atmel.com@...
> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of Frédéric Nadeau
> Sent: Friday, September 18, 2009 10:00 AM
> To: avr-libc-dev@...
> Subject: Re: [avr-libc-dev] Adding (some) Procyon AVRlib
> functionality to avr-libc
>
> I volunteer to start the project.
>
> I suggest we open a hosting on Savannha so that we can have a separate
> mailing list and start discussion on that specific project. From there
> on we could lay out a distribution plan, compilation method, etc.
>
> I would personally name it "avr-drv". Any better name or suggestion?
>

I had started a project earlier and had called it LibAVR (or libavr). The point being that we have libc (the C library), libm (the math library), and this would be libavr, the AVR library. On the linker command line, it would be easy to spot with '-lavr'. Plus it has the distinction that the name is short.

See attached .zip file for existing code for the project.

Addressing Ron's earlier comment: I would rather not do a UART driver as the first device, mainly because there is actually a lot of code with that. I would vote for an SPI driver, mainly because it is simpler to implement. I, of course, also have an example of that in the libavr code attached.

Eric


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Ruddick Lawrence]

I think LibAVR might be too confusing. I know on avrfreaks a lot of people
complained that Procyon AVRLib (often shortened to just AVRLib) was too
easily confused with avr-libc. I guess we should think about what this
library really does (all I can think of is that it's "utilities") and see if
there's a concise word to describe it... I'm coming up dry in that regards.

Ruddick

2009/9/18 Weddington, Eric <Eric.Weddington@...>

>
>
> > -----Original Message-----
> > From:
> > avr-libc-dev-bounces+eric.weddington=atmel.com@...
> > [mailto:avr-libc-dev-bounces+eric.weddington<avr-libc-dev-bounces%2Beric.weddington>
> =atmel.com@nongnu.
> > org] On Behalf Of Frédéric Nadeau
> > Sent: Friday, September 18, 2009 10:00 AM
> > To: avr-libc-dev@...
> > Subject: Re: [avr-libc-dev] Adding (some) Procyon AVRlib
> > functionality to avr-libc
> >
> > I volunteer to start the project.
> >
> > I suggest we open a hosting on Savannha so that we can have a separate
> > mailing list and start discussion on that specific project. From there
> > on we could lay out a distribution plan, compilation method, etc.
> >
> > I would personally name it "avr-drv". Any better name or suggestion?
> >
>
> I had started a project earlier and had called it LibAVR (or libavr). The
> point being that we have libc (the C library), libm (the math library), and
> this would be libavr, the AVR library. On the linker command line, it would
> be easy to spot with '-lavr'. Plus it has the distinction that the name is
> short.
>
> See attached .zip file for existing code for the project.
>
> Addressing Ron's earlier comment: I would rather not do a UART driver as
> the first device, mainly because there is actually a lot of code with that.
> I would vote for an SPI driver, mainly because it is simpler to implement.
> I, of course, also have an example of that in the libavr code attached.
>
> Eric
>
> _______________________________________________
> AVR-libc-dev mailing list
> AVR-libc-dev@...
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>
>

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Weddington, Eric]

 

> -----Original Message-----
> From: Ruddick Lawrence [mailto:ruddick@...]
> Sent: Friday, September 18, 2009 12:45 PM
> To: Weddington, Eric
> Cc: Frédéric Nadeau; avr-libc-dev@...
> Subject: Re: [POSSIBLE VIRUS:###] RE: [avr-libc-dev] Adding
> (some) Procyon AVRlib functionality toavr-libc
>
> I think LibAVR might be too confusing. I know on avrfreaks a
> lot of people complained that Procyon AVRLib (often shortened
> to just AVRLib) was too easily confused with avr-libc. I
> guess we should think about what this library really does
> (all I can think of is that it's "utilities") and see if
> there's a concise word to describe it... I'm coming up dry in
> that regards.
>

Here's the objection that I have: Procyon AVRLib is no longer maintained, or at least doesn't seem to be. If we create an alternative, and it stays maintained, then it will get the name recognition. The Procyon stuff will just fade away. It's not like we will have to continue to compete with that project. So, personally I don't see it as such a big deal with the names being close.

Plus it has the advantage that it will be part of the larger avr-libc project. It will be included in the WinAVR distribution. So it will get name recognition.


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Joerg Wunsch]

As Ruddick Lawrence wrote:

> I think LibAVR might be too confusing.

I agree, though I also see Eric's point: assuming it will really
become an object library, a link specification like -lavr looks
good.

But then, just because the object library is named libavr.a, nobody
says this must exactly match the project name. ;-)

(I really wonder what the "possible virus" might have been. :)
--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev