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

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

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


From: Ruddick Lawrence
Subject: Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc
Date: Fri, 18 Sep 2009 11:21:20 -0700

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

> 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 <address@hidden>
> 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
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
> >
>
>
>
> --
> Frédéric Nadeau ing. jr
>
>
> _______________________________________________
> 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]