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 <r...@jennaron.com.au> 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@nongnu.org > http://lists.nongnu.org/mailman/listinfo/avr-libc-dev > -- Frédéric Nadeau ing. jr _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
