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

[Mike Perks]

David wrote:
> For example, consider an SPI interface as discussed earlier.  With C, 
> we are faced with a choice between including an "spi bus number" 
> parameter in every function (leading to more verbose, larger and 
> slower code on AVRs with 1 SPI bus) or having different APIs for 
> single-bus AVRs and multiple-SPI-bus AVRs.  As a compromise, some 
> macros and inline functions could be used as wrappers, along with 
> conditional compilation to end up with optimal code in each case.  
> With C++, these macros and conditional compilation can be templates 
> and classes, and the API stays neat and consistent.
I think we need to establish some guidelines (actually a design) for 
what this library will do and will not do. Here are some questions that 
I believe need answering (if they haven't already):

1. Do we handle devices with no RAM?
2. Are APIs stateful or stateless. Stateful implies using some number of 
"magic number" or "handle" to the current state and "instance". C++ 
would probably use an object instance.
3. Do we provide support for software emulation of things like USARTs 
and bit-banged SPI? If we do then this leads to internal data structures 
and bus numbers or channel numbers. I believe software emulation has to 
be a stateful API in all cases.
4. How do we handle devices with 1 of something versus multiple e.g. 
USARTs and SPI buses? Most devices except xmega have only one I2C port.
5. Do we have a one-size fits all approach that dynamically adds support 
for multiple SPI buses for example, or are there several different flavors?
6. Is the library simply header files with macros and inline functions 
or is there a library file to link with, or a mixture of both? The 
answer to the previous question may affect the answer to this question.
7. What non-device functions do we support e.g. multi-tasking of some 
kind? Do we add time of day/date/clock tick functions that gets 
allocated to a specific timer at compile or runtime?
8. What naming convention do we use? (has been discussed and I think a 
consensus reached to use underscores - just needs to be written down in 
the design document)
9. What is the license? (has been discussed and I think a consensus 
reached was to use BSD).

We should do an analysis of some other libraries so see how they work 
and the type of functions they provide. For example I am very familiar 
with the ZBasic language and library functions. The ZBasic library 
(http://www.zbasic.net/doc/ZBasicSysLib.pdf)  is very large and provides 
a great deal of support for both device and non-device functions.

Mike Perks
Oak Micros (oakmicros.com)