> > Obviously, MACROs must have some good reason for existing,
> > otherwise,
> > why would anyone use them?  So my question is, what's the difference
> > between a MACRO, and just using a subroutine?  Why would one choose
> > one
> > over the other in a given situation?

I didn't see the original message for some reason.  I see Harold has already
given you a good answer, so I won't repeat what he said.

I rarely use macros as just subroutines without the 4 cycle call/return
overhead.  I think of macros more as canned but possibly configurable code.
The parameters you pass to macros allow compile time choices to be made,
which allows for just the right code to be emitted in different situations
with considerable complexity.  You only having to work out the details once
when you write the macro.

I use a large set of standard macros accross all my projects and keep them
in a master include file.  Go to http://www.embedinc.com/pic and take a look
at STD.INS.ASPIC for many macro examples.

Another use for macros is to perform some canned assembly time operation.
Macros don't have to emit any code.  An example of this is the UART_BAUD
macro in the file I mentioned above.  It uses assembly time constants and
variables to compute the best UART setup values given the clock frequency
and the desired baud rate.

Especially take a look at the DBANKIF macro and related macros.  If everyone
used these or something similar, a number of the problems posted to the PIC
list would go away.  I very rarely have bank switching bugs in my code, and
if I do it's usually because I left out a DBANKIF or forgot to put an UNBANK
at a label that can be jumped to from different places.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olin@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body