Alan B. Pearce wrote:

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

Hi Alan,

Thanks for your sharing your thoughts in this thread. Your points are
well-taken and I'm definitely aware of some of the trade-offs involved. I
was thinking along the lines (as you have already suggested) in that you
would use property 'Gets' and 'Sets' that go along with the library member
functions that need set/get attributes or properties. Even if you don't use
libraries, some people use routines in which they might pass the desired I2C
frequency in the W register to a function that configures, for example, the
I2C frequency (master mode) to allow configurability. If you're strapped for
space, this could be the straw that breaks the camel's back, but it is
definitely a nice way to program in my opinion if you have the resources
available (which I do in this case).

But even if one is a strong proponent of 'source' libraries versus 'binary'
libraries, there are still the issues of configuration management specific
to the original source code library that I alluded to in earlier posts. If
someone names their routines in their source library 'UART_Initialize' or
'UART_Get' or 'UART_Put' I'm just curious how they handle the situation in
which they need to make a revision on these routines (for whatever reason),
especially in the case where existing code is already using these routines.
In could be something as simple as an errata patch or something like that.
So the concern is that, in my opinion, you never want to destroy any
original code in the library. You would have to create a brand new routine
to host the fix/patch/revision and re-name it with a new name. Maybe the
change is so trivial that existing client code does not need to be updated,
or maybe it does. Changing a sub/function and naming it the same thing could
be disastrous. That's why I will go with the versioning strategy for the
sub/function names I mentioned before. Perhaps I should look at Embed Inc's
methods to see how this is handled in this regard.

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

To some extent the above is true in some cases, but even in your example of
a UART library module or my I2C example, I don't feel that these routines
would be so targeted or closely coupled to a specific project to render them
not re-useable, but maybe I'm misinterpreting what you are saying. I do
agree that some routines would probably be best served by not placing them
in a library because they would be so specific to a particular application
that it would not be worth the trouble. It would come down to a judgment
call.


Thanks for the dialog Alan -- I appreciate your thoughts.

Best regards,

Ken Pergola

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