Agree. Just want to make sure as this is a pre-req for some of the
other design questions.
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.
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.
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.
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.
6. Is the library simply header files with macros and inline
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
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.