Vitaliy wrote:
> So where do you specify the project specific attributes, for instance
> the baud rate for UART, or the resolution for ADC?

Those go in whatever module manages those resources.

> Specifying these attributes inside the module that uses them,
> effectively precludes code reuse.

Of course not.  If truly only the baud rate ever changes between your UART
modules, then you can put the baud rate constant in your project include
file and make the UART module a library include file.  However there are
different wrinkles in how you might want to use the UART.  The needs of a
particular project could span the range between using only the UART output
with a busy wait loop before writing, to full interrupt driven I/O using
FIFOs in both directions.  My QQQ_UART.ASPIC template module contains the
full blown case since it's a lot easier to delete things you don't want
instead of adding things that aren't there.  I can also use other project
code as templates, like when I want just programmed I/O UART output.

> You have to make a copy of the UART
> module, just so you can specify a different baud rate. Since the file
> is now different, it will quickly get out of synch with the other
> copies, because any other changes you decide to make, won't propagate.

The UART template module has changed very little in a bunch of years.  But
there is no problem even if it is customized for particular projects.

> It makes sense to isolate the stuff that changes (e.g., configurable
> attributes) and put it in one file that contains project-specific code.
> Then the UART module can be used without any modifications, in a
> project that uses it at 9600 baud and a second project that runs it at
> 115k baud.

In my experience, very few things on small resource-limited systems like
PICs can be pre-packaged and generalized at this level.  The UART is about
the only exception I can think of, which is why I have a UART template
module.  I've tried to do that with A/D handling code, and couldn't come up
with something flexible enough to meet a reasonable fraction of project
needs that was not so burdened with dealing with the options as to be too
unwieldy or inefficient.  There are just too many wrinkles, like which
channels are in use, how acqusition is timed, how conversion is timed, how
the results are filtered and/or scaled, how they are communicated to the
rest of the system, whether interrupts are used to get results, how
conversion is initiated, etc, etc.

In the end it's easier to start with code from a similar project and modify
it, or even start from scratch with maybe looking at code from another
project as a example.  Keep in mind that setting up the peripherals is the
trivial part of PIC projects.  Most of the work goes into the unique code
that performs whatever the project's function is.  The A/D module is rarely
that complex.  It doesn't matter how great a solution you have for 10% of
the problem.  You still have the other 90% to do.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist