Re: [avr-libc-dev] RFD: more avr-libc API changes

[Wojtek Kaniewski]

E. Weddington wrote:
> On the other hand, I abhor reinventing the wheel and there should be a 
> place for *exactly* what you describe: libraries to interface to common 
> external peripherals, that have been vetted. The downside to this is 
> twofold: the time it takes to verify the submitted code, and where to 
> put it.

The problem is that people usually get avr-libc bundled with complete 
AVR development environment and don't know how to find, get and use 
external libraries, thus they end up creating the code that's floating 
around the Internet for a long time. I agree that avr-libc should focus 
on providing standard C functions, but as there already are some 
non-standard extensions, I couldn't resist to ask.

> To further the cause, I will volunteer: Please submit code to me, or to 
> the avr-libc-dev list, and I'll help pull it together in one single 
> place. (...)

The code I have isn't ready for publication yet. Main problem with 
supporting _external_ hardware is the configuration of electrical 
connections. Some will want LCD display connected to PORTA, some to 
PORTB. Some will want to use constant delays, some will want BUSY 
polling. That's why it's rather unreal to have the code compiled. I 
still don't have the idea how and what to distribute. Header files with 
inline functions that would require some configuration #defines?

(Cc: address@hidden removed.)

Regards,
Wojtek