Hi everybody on the list,

I have joined the list recently and this is my first list I have ever
subscribed. I must say this is a terrific way to get help on a very specific
issues. I am not quite new to PIC and microelectronics, but certainly far
from not needing any help ever. I use almost everything from 12C508 to
16C74, haven't got project that demanding to use the 17Cxx family. My main
target is chemical laboratory equipment but generally everything, what has
little moving parts and lot of PICs. Let me share some tips on MPASM
programming.


1. Useful #defines

For each bit in every special register i declare a #define directive like this:

#define _Z      STATUS,Z
#define _SPEN   RCSTA,SPEN

I put them in a file and I name this file Q16Cxx.INC (after the P16Cxx from
Microchip) and keep it in the same directory. It takes a while to edit the
P*.INC into Q*.INC, but you do it just once for a new processor. Then I
include the Q*.INC file right after the P*.INC in the main program.

What is this all for ? I need not to remember or look up each time where the
bits reside. It also prevents errors like:

        BSF     TXSTA,SPEN      ; should be BSF     RCSTA,SPEN
                -----                               -----

What is bad about the above error - the statement is perfectly legal, you
receive no varning from the assembler and easily overlook it. You would just
wonder why the serial port is not working.


2. How to avoid "Register in operand not in bank 0." message

Questions like "What does it mean when assembler says: Message[302]
CC58_10.PIC 280 : Register in operand not in bank 0.  Ensure that bank bits
are correct" have already been posted to the list. It issued every time you
address any special register or variable from the page 1. If your code is
some 50 lines, you can thru it and "ensure that the bank bits are correct"
as the assembler suggests. If you go to larger source files, it is more and
more time consuming. You can remember the count and if it is still the same
as it was last assembly then assume it is OK this time as well. But it is
not that comfortable.
I work around these messages following way. My philosophy about pages
switching is to locate all byte or word variables in the page 0, and use
page 1 for buffers, seldom used or indirectly addressed variables or arrays.
Most of the time the page 0 is selected so you don't need page bits
handling. Any part of the code or a subroutine that switches to page 1 is
also responsible for swithing back to page 0. And now the little trick comes
- instead of plain BSF/BCF STATUS,RP0, I have these macros:

SELRP0  MACRO
        BCF     _RP0        ; _RP0 = STATUS,RP0
        ERRORLEVEL +0302    ; switch the page warning on
        ENDM

SELRP1  MACRO
        BSF     _RP0        ; _RP0 = STATUS,RP0
        ERRORLEVEL -302     ; switch the page warning off
        ENDM

So for the code, that uses variables from page 1 the warning is deactivated
and the rest of the code has the warning enabled. For a correct program
(regarding page swithing) you get no warnings. It is not totally foolproof
however - if you use variable from page 0 in the segment where the RP0 is
set, the warning does not appear. Or if you jump in the middle of the
segment with incorrect bits set. So if you receive no warning, it still does
not mean the page swithing is correct, but since the places, where an error
can occur, are generaly small in size, it is easier to check them.


3. Floating point library

I have ordered the May digest and noticed, that someone warns about
Microchip floating point divide routine. I use the FP32_14.a16 library and I
would like to point out, that not only the divide, but also the multiply
routine as well as subtract and addition routines have bugs too. The
multiply does not round correctly in some instances and the addition and
subtraction fail if the numbers have different signs and one is smaller by
the order of 2^24 or more than the other one. I have reported these bugs
together with corrected code to Microchip and guess what happened ! They
send me the $2300 PIC-Master, full tubes of JW parts and a very nice letter
encouraging me to continue in the valuable customer feedback.

(Just kidding, nothing happend so far. ;-) If there is an interest, I can
post the corrected code fragments.


4. Re - testing true/false returned from subroutine.

This solution I have found in the Fast Forward Engineering answer page, if I
overlocked the posting in the huge digest, then just disregard it.

        CALL    TEST    ; subroutine returns W=0 for FALSE, W=1 for TRUE
        ADDWF   PCL,F
        GOTO    FALSE   ; jump to process false branch
TRUE:   ...             ; process true branch here

Of course you have to watch out for program page boundaries.

Josef Hanzal