[Top][All Lists]

[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: Frédéric Nadeau
Subject: Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc
Date: Fri, 18 Sep 2009 12:00:19 -0400

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?

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

reply via email to

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