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

[Jan Waclawek]

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

I fail to see the device dependence of those I've seen. I might be 
exceptionally dumb, I admit. Can you point out one, please, perhaps with a 
negative example ("if we wouldn't do this and that, in device XYZ it would 
cause problems")?

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

IMHO, global data fail into that cathegory, too. Unless you want to play the 
total encapsulation game, which has little substantiation in the 8-bit 
microcontrollers' world.

I would also suggest a bigger emphasize on the usability of the various 
modules. From the user point of view, it's largely irrelevant what a function 
does ("enable double speed of SPI"); usually it's more important to explain, 
how should the provided functions be used so they fulfill the user's potential 
requirements (part of which the user might be  completely unaware initially). 
This could involve real-world examples, usage guides and FAQs.

Would a "configuration utility" type of application, enabling to use the 
library more easily, find far from the scope of this whole effort? 

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

It would be bizarre if it would be otherwise... :-)

JW