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

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Mike Perks
> Sent: Monday, September 21, 2009 7:55 AM
> To: address@hidden
> Subject: Re: [avr-libc-dev] Adding (some) Procyon AVRlib 
> functionality toavr-libc - C++
> 
> 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?

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.


> 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.



> 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. ;-)


> 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.


> 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.


> 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).


> 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.

> 9. What is the license? (has been discussed and I think a consensus 
> reached was to use BSD).

Agreed.

> 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.
> 

Thanks for the link! I'll take a look to see what they have.