[Avr-libc-corelib] Library Design Questions

[Mike Perks]

Weddington, Eric wrote:

1. Do we handle devices with no RAM?
    

This is pretty much a C language based library. Devices with no RAM are not easily supported by the C compiler. So IMO, no we do not support RAM-less devices. There aren't that many to begin with, and they're all legacy devices now anyway, so it's not that big of a loss.
  

Agree. Just want to make sure as this is a pre-req for some of the other design questions.

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.
    

I would imagine that if something is "stateful" that it does require some amount of RAM to support saving the state. In principle, I think we should strive for the smallest footprint as possible, especially in RAM usage as RAM is a scarce resource for practically all AVR devices. If we can design a driver with no RAM usage (stateless), that would be the best. If the driver requires saving state, then we should do so in the minimum possible way that can be achieved. I also have no objection to having 2 or more kinds of drivers for a particular peripheral. I do not think that one particular style will meet everyone's needs. But with that, we should also be aware that the purpose of the library is for convenience. It cannot be all things to all people, ever. Otherwise it will never get finished.

  

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.
    

While I have no objection to including these eventually (I have a bit-banged SPI driver I can contribute), we should probably focus on the on-board peripherals first, and then branch out from there.
  

The reason for asking this question is that it has impacts on RAM. and also on the API. For example we should at least think about software emulation otherwise we may find ourselves changing the API later. Better to design a little more up front first even if we do a staged implementation and not everything is available on day one.

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.
    

Good question. There are a lot of ways to do it. Let's discuss it after we can agree on which project to host with and we have a separate mailing list. ;-)
  

So now is the time? Probably should start a separate thread on this one (and for that matter some of the other open questions on this list.

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?
    

In my experience, one-size generally does not fit all. I'm ok with several different flavors.
  

No but you could have #defines that add additional features/functions e.g. #define MULTI_SPI_SUPPORT.

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.
    

Why impose an artificial limitation on the implementation. My experience has been that one has generally a mixture of both, header files with macros and library functions. It probably depends on how complex the API implementation is.
  

I wasn't trying to - just asking a question. My guess is that a lot of the code will be conditionally compiled and very little will be in a library archive per se.

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?
    

We are not developing an RTOS.

No objection to adding support for date functions, but let's do that down the road (unless you have some code you can contribute).
  

Date functions affect allocation of timers and need one reserved to keep track of ticks. We might have defines like the following:

#define ENABLE_TIME_OF_DAY 1
#define TIME_OF_DAY_TIMER   3

which enables a timer3 ISR for timer ticks and a #define such as #define TIMER3_ALLOCATED 1. Other code would check for TIMER#_ALLOCATED to avoid using these registers.

This is why I think we need to do some design up front for a staged implementation.

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)
    

Agreed.
  

Who is creating a design document and where will that reside? I don't yet see a project on http://savannah.nongnu.org.

Mike Perks
Oak Micros (oakmicros.com)