sergio masci wrote:
> "month" should already be documented as being in the range 1-12 and
> it's use should be consistant throughout the program.

If anything, month should be 0-11 consistantly except when it's coming or
going to a user interface.  The same goes for days within a month, hours
within a day, etc.  This makes internal computations more natural.  It is
only our human convention that numbers January as 1.

> Also changing:
> addlw 255
>
> to
> addlw -1
>
> would make the code that much easier to follow

You might have to say ADDLW LOW -1 to avoid a warning.

In any case, I think you're right, but that's really a minor nit.  I doubt
anyone's code would stand up to that level of nitpicking.

> It would be
> really useful if there were a seperate document that gathered esential
> details like this together in one place so that the reader could get a
> feel for what to expect before he/she starts ploughing through the
> code.

Separate documents get out of sync too easily.  If there is a separate
document, it should only be a general introduction to the structure of the
code.  Details should stay with the code, and only with the code.

It's funny you didn't mention the one thing that I think is a real problem
with Byron's code.  The bug waiting to happen is that he's using ADDWF PCL
to index into a call table without any mechanism to guarantee there won't be
a 256 word boundary there or even a comment warning someone that this must
be manually ensured.  Unless you're really really tight on cycles or space,
do the extra math to make sure PCLATH is set right.

In a few cases where I was tight on cycles, I put the table at a fixed
address and let the linker place other modules around it.  Since that was
the only section forced to a particular address other than the reset vector
and the interrupt routine, it was no big deal for the linker to still use
the code space efficiently.

> I mean, what does "interpolate" mean.

That's a standard english word that was quite legitimate for Byron to assume
the reader knows.  It's also common in computer science, and is often used
to describe the process of computing a blended value between two known
points when you know how far between them you are.  Look it up.  I don't
mean that as a flip comment, just that this has a standard meaning and it's
out there to easily find.

> So putting this back into assembly we get:

Yucc.  The lack of formatting makes this really painful to look at.  You'd
also get massive warning if you tried to assemble this.

> Now someone will stand up and shout "that's cheating, you've just
> moved a bunch of code into macros".

That's legitimate sometimes, but there's also a tradeoff.  The more macros,
the more non-standard your language becomes.  They can make things clearer,
but they also take time to look at, make sure they really do what is
claimed, check what corner cases are really handled and which ones are
assumed to not be presented, etc.

> BYTE_ABS .macro arg
>
> btfsc (arg),7
> comf (arg)
>
> .endm

If you want to pick apart Byron's code, you should at least use the same
language he did.  I don't know what this is, but it's not MPASM since that
doesn't have directives ".macro" and ".endm".  ASM30 does, but this is
clearly not the dsPIC instruction set.

Also it seems you have a bug.  The reason I can only say "seems", is that
you haven't defined what the BYTE_ABS macro is supposed to do exactly.  From
the name I can only assume that you intend it to take the absolute value of
ARG.  Note that while the name might be reasonably clear about the
arithmetic operation, it says nothing about where the result should go.
This should all be clearly described in the header comments of the macro.
For example, it could be just as legitimate to have the macro leave the
result in W.

As for the bug, to do a twos complement negate requires a complement and
increment, not just a complement.  Therefore your macros is seriously
broken.  If you really meant it to do ABS in something other than twos
complement, this should have been clearly documented.


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