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

[Weddington, Eric]

> -----Original Message-----
> From: Jan Waclawek [mailto:address@hidden 
> Sent: Sunday, September 20, 2009 2:03 PM
> To: Weddington, Eric
> Cc: David Brown; address@hidden
> Subject: Re: [avr-libc-dev] Re: Adding (some) Procyon AVRlib 
> functionality toavr-libc
> 
> > One possibility: When an API is being designed and is being 
> considered for inclusion, there must be some work done to 
> make it fit for the existing devices, even it's for the 100+ 
> devices that are currently in the AVR family. Yes, it's time 
> consuming, but that would ensure that we've at least thought 
> of ramifications for all devices, even if they haven't been 
> fully tested out.
> > 
> 
> 
> Could someone perhaps give a real example we could chew upon? 
> What should an "API" or whatever look like? 
> Isn't the issue with multiple different AVRs related more to 
> the library routines themselves rather than to an API?
> 

Well, actually a few of us have provided examples.

API means Application Programming Interface, which is nothing more than a set 
of function calls: their names, what parameters they accept (and their types) 
and what the function returns, and the meaning of what the function does.

For example, I sent to this list an example of set of routines that I and other 
colleagues have written and tested. These routines are categorized into 
different areas, such as an SPI driver. The API (list of functions) that are 
provided to drive the SPI peripheral on the AVR should be designed in such a 
way that they will be relevant to all AVR devices that have such an SPI 
peripheral. The underlying implementation of these API functions could be 
different, depending on any differences in the SPI peripheral on the various 
AVR devices. However, the interface itself should be designed in a way that it 
can be used across the entire range of exsiting AVR devices.

Various APIs should be developed for the various on-chip AVR peripherals.