On Mon, Aug 19, 2002 at 03:19:16PM -0700, Andrew Warren wrote:
> Dave Dribin <PICLIST@mitvma.mit.edu> wrote:
>
> > I've made some minor modifications to the code, like set p=16f877,
> > include "p16f877.inc", and add some debugging code to print the CRC
> > out the serial port when entering CRC16.  In other words, nothing
> > that should affect the CRC.
> >
> > When I run the code through the simulator (gpsim under Linux), I get
> > correct results.  The CRC matches the ones in the comments as I step
> > through the code.  However, when run on a real PIC (16F877 @ 4MHz),
> > the results are wrong.  Note: the results in comments appear to be
> > correct.  I've verified it with some C code on the desktop.  Here are
> > the results from a real PIC from the serial port
>
>     Dave:
>
>     Twenty dollars says that the CRC is being calculated correctly,
>     but your serial-out routine (and whatever other junk you've put
>     between the PIC's registers and your eyes) is corrupting the
>     data that you see.

I thought of that and have double checked the serial code.  The serial
routines do not to touch `crc_high' nor `crc_low'.  Unless there's
some weird side affect that I'm not seeing.  BTW, I'm using the USART
in polling mode.

Here's the serial code I added at the beginning and end of the routine
(surrounding in "IF (1)" so I could easily comment it out).  You
should be able to guess what the routines do:

CRC16:
 IF (1)
        movwf   saved
        movfw   saved
        call    SerPrintHexByte
        movlw   ' '
        call    SerPrintAscii
        movfw   saved
 ENDIF
        xorwf   crc_lo,W        ;W = input XOR old crc_lo
        xorwf   crc_hi,W        ;Swap old crc_hi with W

        [ ... unmodified ... ]

        btfsc   STATUS, C       ; if shift out is one
        xorwf   crc_lo,F        ; flip bit 7 of crc_lo

 IF (1)
        movfw   crc_hi
        call    SerPrintHexByte
        movfw   crc_lo
        call    SerPrintHexByte
        call    SerPrintNewline
 ENDIF
        retlw   0

>     P.S.  In order to avoid using a temporary register, the author of
>     your CRC code made it slow, large, and dangerously tricky.  If
>     you don't mind using one extra register, you could improve the
>     code quite a bit.

Hmm.. I'm all ears.  I don't understand that code for the life of me,
so I can't even begin to figure out what's wrong.  I'm currently in
the middle of trying to understand and rework Ashley Roll's code:

  http://www.digitalnemesis.com/ash/projects/EmbeddedCRC16/default.htm

It doesn't use a reflected table, so I'm trying to get it work with a
reflected CRC.

-Dave

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu