I've been following this thread for a bit, and I don't think anyone's
mentioned one of the pitfalls of using macros that seems to "bite"
assembly-code writers rather frequently:
(forgive me if this is redundant!)
The scenario in which you inadvertently use a "skip" instruction of some
kind, 'around' a macro instance that generates multiple instructions.
Depending on the style of your macro definitions, and how closely they
syntactically resemble actual mnemonics, bugs like this can be very tricky
to find.  True, you can usually zero right in if you're "simulating" the
code, but (as Murphy would have his way) for some reason these usually
manifest themselves in "critical" code that you can only execute in "real,
live" context.
  I'm not adverse to using macros myself, btw.   Just wanted to point out
that this is an area in which you need to be more diligent.

Jim

----- Original Message -----
From: "Jinx" <joecolquitt@CLEAR.NET.NZ>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Thursday, February 12, 2004 3:58 PM
Subject: Re: [PIC:] Reading PortA on 16F877


> > Because I document well throughout the code, and write in a
> > straight  forward way without using macros, I have achieved
> > code that is readable, maintainable, and performs as it was
> > designed to do, and everyone is happy
>
> And you can't argue with happy ;-)
>
> Just to be clear, no one would get on a high horse trying to tell you
> that you don't know what's good for you. I have a comfort zone too.
> The major benefits for me using macros are (1) reduces typos
> (2) quicker to write code and (3) no or less time spent debugging
> sections that are done deals (IF you have been careful)
>
> I find _simple_ macros particularly useful. MOVFW for example
>
> movfw    macro   litval
>          movf    litval,w
>          endm
>
> I have been known to type something like movf temp,f when I meant
> movf temp,w. We've all done it. It's very very easy to overlook this
> during debugging. Using movwf temp is much more informative from
> that point of view. As a result I now spend more time optimising
> functionality (which is important) rather than looking for typing errors
> (which is annoying and always ends up with a self-kicking). And that
> makes ME happy ;-)
>
> > As far as 'EQU' and 'DEFINES' are concerned, I use them all the
> > time.  I wouldn't write a program unless I did.  Unless it was very
> > small, but then again ?
>
> I have some small 68HC705 test programs, very old code, pre-PIC,
> that I didn't bother to use defines for. As part of a HDD clean-up last
> week I looked through them. Hardly had a clue what they were for
>
>            bset 4,0
>            nop
>            bclr 4,0
>            nop
>            bclr 1,0
>            nop
>            bset 1,0
>
> Hmmm, what did that do again ? Up to the port comments, down
> to the code, up to the comments for the next lot..........
>
> If I'd originally defined them as reset4040 and clock4040 I'd have
> saved 10 minutes last week. It's all so obvious when you're in the
> groove, but don't see it for a while and you'd be just as clueless
> as anyone
>
> But I think I'm flogging a dead (high) horse ;-)
>
> --
> 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

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