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

[David Brown]

Ron Kreymborg wrote:
> > > 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

I expect you are thinking of something like low-level functions to put 
send a byte to the screen and strobe the various control lines or 
address bus signals.

One thing here is that it can be difficult to find a balance between 
hiding as much as possible in the library code, and generating fast 
code.  If your low-level functions are too simplistic, then the function 
call overhead becomes dominant - something like "strobeChipEnable()" or 
"setRegisterSelectBit()" should be macros or static inline functions, 
not normal function calls.

If we aim that for the modules to be usable as either pre-compiled code 
(for user convenience), or by copying the modules to the project, then 
users can choose themselves.  They can then define a their 
"stropeChipEnable()" function as a normal function linked to the 
library, or as a static inline function compiled directly into the 
module if speed is important.