avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [POSSIBLE VIRUS:###] RE: [avr-libc-dev] Adding (some) Procyon AVRli


From: Ruddick Lawrence
Subject: Re: [POSSIBLE VIRUS:###] RE: [avr-libc-dev] Adding (some) Procyon AVRlib functionality toavr-libc
Date: Fri, 18 Sep 2009 11:45:23 -0700

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 <address@hidden>

>
>
> > -----Original Message-----
> > From:
> > address@hidden
> > [mailto:avr-libc-dev-bounces+eric.weddington<avr-libc-dev-bounces%2Beric.weddington>
> address@hidden
> > org] On Behalf Of Frédéric Nadeau
> > Sent: Friday, September 18, 2009 10:00 AM
> > To: address@hidden
> > 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]