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

[Jan Waclawek]

> > What I want to avoid here is that someone contributes code 
> > for a great 
> > SPI driver, people start using it, and then someone else 
> > points out that 
> > some AVRs have more than one SPI bus and the entire API needs to be 
> > changed to take that into account.  You end up with a choice 
> > of annoying 
> > people by changing the API regularly, or annoying people by 
> > using an API 
> > that doesn't cover the requirements just to avoid changes.  
> > Basically, I 
> > want to make it perfectly clear to users when they can expect 
> > an API to 
> > be stable and when it might change.
> 
> You certainly bring up good points.
> 
> 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?

JW