> Is the PICLIST community mostly sharing .asm files, or is
> anyone doing .o+.inc releases?  The .o+.inc gives better quality, IMHO,
> but some extra discipline is required.  Thoughts?

When I first started with PICs, I figured I'd make libraries of "standard"
routines as I created them, and package the .o files into library files so
the linker would pick whatever I referenced, just like on a real computer.

Unfortunately this didn't work.  There was too much external configuration
information per project so that any one .o file was only good for the
project it was created for.  Examples of such configuration are the
oscillator speed, size and location of the software stack, and number of
"general registers" defined.

I ended up creating my library routines at the source code level as
include files.  The include file for each project was then broken into two
parts, xxxLIB.INS.ASPIC and xxx.INS.ASPIC.  The first defines all the
generic configuration information that isn't project specific and needs to
be known by library modules.  The second contains all the project specific
declarations.  All the project specific modules include the project
include file, which includes the LIB include file.  I then have stubs for
each library routine used by a project.  The stub includes the LIB include
file only, then the generic library source routine include file.

You can see examples of this in the HAL project described at
http://www.embedinc.com/pic/hal.htm.  The only include file seen by the
generic library source modules is
http://www.embedinc.com/pic/hallib.ins.aspic.htm, and the include file
seen by the project specific modules is
http://www.embedinc.com/pic/hal.ins.aspic.htm.

> I am currently grumpy with the
> aesthetics of managing PCLATH in my code,

Take a look at my GCALL, GJUMP, and related macros in STD.INS.ASPIC at
http://www.embedinc.com/pic.  I rarely have to mess with PCLATH unless I'm
doing deliberate manipulation of the program counter, like a computed GOTO
or table lookup.

> Is anyone doing "Object oriented" assembly on the PIC?

I've done that in a few rare cases.  Object oriented structuring can be a
useful abstraction, especially when multiple people are working on a large
source project.  However, a PIC project is usually written by a single
person, and the abstraction can use up scarce runtime resources like call
stack levels.  In the end doing a good job of conventional programming
still beats anything less using any other method you can chose.  Break up
the project into modules, keep a clean master include file with all the
declarations, document the interfaces to every routine and macro, and
explain what most instructions are doing with good end of line comments.
If you do all this religiously, you'll have clean code that anyone
familiar with PICs can follow.  It will probably be less confusing because
it's not messing with program memory pointers a lot.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics