RE: [Avr-libc-corelib] proposed corelib style guide

[Ron Kreymborg]

> > As I understand it, the library will be a pre-compiled lib file, with
> the
> > MCU name in the makefile linking to the matching version for that
> processor.
> 
> This approach is ok for built-in modules, but how about a HD44780
> driver? I have not ever made a PCB where the pins for the HD44780 were
> exactly like any previous.
> Using a HD44780 driver with runtime flexible pin definitions is a (code
> size) nightmare. Or is a HD44780 not supposed to be in this library?
> 
> Wouter

Not sure about the PCB pin problem. 

For the library, I think a device like this should not be too hard. Most of
the complex stuff is associated with providing various display functions -
text strings, scrolling, flashing, etc, and this would be provided by the
library. Actually handling the ports would be handled by a call-back
function. From memory I think all you need is a send function and perhaps an
"are you busy" function.

Not positive here, but the send would probably look like:

void LcdSend(uint8 value, bool commandFlag);

The user would then stitch their various assigned pin numbers into a
boilerplate sample function provided as part of the library, probably just
by setting a few macros. The byte to output is <value>, and whether it is a
command or data is defined by <commandFlag>. Where necessary, the user could
edit another provided boilerplate function that splits the byte for 4-bit
interfaces. And libc already provides an accurate delay function should this
be needed.

The library need know almost nothing about the hardware connections.

Ron