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)
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
