RE: [Avr-libc-corelib] Library Design Questions

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> gnu.org] On Behalf Of Mike Perks
> Sent: Monday, September 21, 2009 10:52 AM
> To: address@hidden
> Subject: [Avr-libc-corelib] Library Design Questions 
> 
> 
> 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.

Sounds like a good plan to me.

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

Yes. Separate threads.

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

I'd have to see more about a specific implementation before agreeing one way or 
the other.
 
>               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.

Again, I think it depends on the implementation. I'd like to follow the KISS 
rule where possible, which means from my perspective that I would rather have 
simple drivers and limited functionality (but tested), than have a driver that 
has a lot of functionality but is very complex to use. So I think that it would 
be better to have as one of the design goals: simple to use. I think the target 
audience here is beginner and intermediate users. For advanced users who need 
to have the complexity, they can use the source code (freely available) as a 
starting point and modify it as they see fit.

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

No argument here. :-)



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

Well this mailing list is a part of the avr-libc project on Savannah. We can 
keep a design document on the avr-libc project. However, a design document has 
not been started. If you start one, then I would suggest doing it in a simple 
text file, as we have Linux and FreeBSD users here so avoid any MS format 
documents.