>But in my case, a binary library appears to make sense (at least right now)
>and I think I will give it a shot. If I fall on my face in the mud with
>arrows in my back that's ok. :)

I suspect that one of the reasons it has not happened is that everything
needs to be highly configurable, but use minimal resources. For instance,
lets say you have a module to handle a UART.

How do you configure the baud rate?

Do you have a callable subroutine that is passed a parameter? If so then
this is going to consume a number of words of ROM to handle parameter
checking that would otherwise be done by macros at assembly time. This is
for code that will be run once, but could be (relatively) sizable for what
it does. If you don't do it this way, then you have to write external code
that loads the baud rate generator, which is exactly what one is trying to
get away from.

I think that Olin's environment gives the best of both worlds, where a
source module can be effectively a library item, but is assembled for each
project. This allows details to be modified to suit the project, and
unwanted/unused pieces of code to be cut out if need be. It also allows the
code to be tweaked to get the required performance for the project, e.g. A/D
channel handling. One would not want that in code that needs only one A/D
channel, but be writing external code to handle multi-channel A/D switching
when the library module is single channel.

The overheads involved with otherwise unused code in a very limited ROM
resource environment makes the library handling a bit of a pain I think you
will find. Each module will be so exactly targeted that when you want one
there will never be a "drop in" module, and you will start from the
beginning modifying the source of an existing one.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads