'Two tips on MPASM; floating point library bugs; Tr'
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
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
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:
BCF _RP0 ; _RP0 = STATUS,RP0
ERRORLEVEL +0302 ; switch the page warning on
BSF _RP0 ; _RP0 = STATUS,RP0
ERRORLEVEL -302 ; switch the page warning off
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
GOTO FALSE ; jump to process false branch
TRUE: ... ; process true branch here
Of course you have to watch out for program page boundaries.
At 09:02 PM 5/30/97 +0200, you wrote:
>Hi everybody on the list,
>blah, blah, blah,
>yeah, yeah, yeah,
>3. Floating point library
>They send me the $2300 PIC-Master, full tubes of JW parts and a very nice
>encouraging me to continue in the valuable customer feedback.
Man, did you have me going! I hadn't been that speechless since the OJ
As a matter of fact, I would be interested in your corrected fragments. As
well as any info you have on calling the routines. I actually failed at my
first run at the library since I couldn't for the life of me figure out the
calling and returned information. Worst of all, I couldn't interpret the
IEEE format to check the result for accuracy. I have collected some
comments from our Piclist for the fateful day when I will not be able to
avoid FP. Boy, can you squeeze alot out of long integers when you are
afraid of the FP routines.
Thanks up front.
Christopher Eddy, PE
Pioneer Microsystems, Inc.
Pittsburgh, PA (Nor is it smelly)
More... (looser matching)
- Last day of these posts
- In 1997
, 1998 only
- New search...