|
|
View previous topic :: View next topic |
Author |
Message |
iso9001
Joined: 02 Dec 2003 Posts: 262
|
Trying to change the poly in this crc algorithm, need help |
Posted: Sun Mar 26, 2006 4:40 pm |
|
|
I have an application that requires a CRC. I looked/asked around for an efficient algorithm and found this one from Dallas's One Wire protocol.
Dallas uses the poly 0x99. If it were up to me, I'de use that poly too, but its not up to me and I've been stuck with 0x11D.
My problem is that I have no idea how the number they are using have been calculated. I've searched and searched, but found nothing.
My CRC code right now works fine except that it for loops for every bit in every bite. An entire 8 byte message takes over 300uS @ 40Mhz,
I know that they picked 0x99 for a reason and that its possible that I can't take theirs and modify it, so if anyone has any other code it would really help me out a lot,
Can't wait till the day each pic has a tiny FPGA built-in... Then I can continue on being a crappy programmer
//-----------------------------------------------------------------------------
// Calculate crc8 checksum
// This is the checksum as used in the Dallas One Wire protocol.
// Advantage of this checksum over other crc's is that because of a pecularity
// of this specific polynomial it allows bytewise processing without bit
// shifting. It's very fast, small and uses no RAM.
//
// Based on: Maxim Application Note 27,
// http://www.maxim-ic.com/appnotes.cfm/appnote_number/542
// Original C code: T. Scott Dattalo
// http://www.dattalo.com/technical/software/pic/crc_8bit.c
// Optimized by: Dirk Van den Berge (dvdb)
// donated to the CCS-forum 12-jan-2004
// http://www.ccsinfo.com/forum/viewtopic.php?t=17170
//-----------------------------------------------------------------------------
int8 Calc_Crc8(int8 *Buffer, int8 byte_cntr)
{
int8 crc=0;
#ASM
//copy pointer to pointer register (CCS doesn't support lfsr assembly instruction)
movff Buffer,FSR0L
movff &Buffer+1,FSR0H
loop:
movf POSTINC0,w // load w with next databyte
xorwf crc,f // xor with accumulated crc (accumulated crc is no longer valid now)
movlw 0 // w will accumulate the new crc
btfsc crc,0
xorlw 0x5e // could also be iorlw
btfsc crc,1
xorlw 0xbc
btfsc crc,2
xorlw 0x61
btfsc crc,3
xorlw 0xc2
btfsc crc,4
xorlw 0x9d
btfsc crc,5
xorlw 0x23
btfsc crc,6
xorlw 0x46
btfsc crc,7
xorlw 0x8c
movwf crc // store accumulated crc
decfsz byte_cntr,f
goto loop // next databyte
// done, crc is in w
movwf crc // store in result
#ENDASM
return crc;
} |
|
|
iso9001
Joined: 02 Dec 2003 Posts: 262
|
|
Posted: Wed Mar 29, 2006 4:44 am |
|
|
No one knows a better CRC Algorithm or any advice on changing this one to work with my poly ????
Maybe even a table driven appliction ? |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Mar 29, 2006 11:32 am |
|
|
The problem is in how you posed your question. It left me uncertain
as to exactly what you want. To exlain:
Quote: | Dallas uses the poly 0x99. If it were up to me, I'de use that poly
too, but its not up to me and I've been stuck with 0x11D. |
Here you imply that some protocol or other controlling authority
requires you to use a specific CRC algorithm. You don't give us
any further information on this.
Quote: |
My problem is that I have no idea how the number they are using have been calculated. I've searched and searched, but found nothing.
|
Who is this "they" that you refer to ?
Quote: | My CRC code right now works fine except that it for loops for every bit in every bite. An entire 8 byte message takes over 300uS @ 40Mhz, |
It works fine right now ? But in all your comments above, you say
that the Dallas algorithm is unacceptable. Then you shift gears and
start talking about the speed of the algorithm, instead of the 0x99 vs.
0x11D issue.
Quote: | I know that they picked 0x99 for a reason and that its possible that I can't take theirs and modify it, so if anyone has any other code it would really help me out a lot, |
Here again we have this mysterious "they".
Do you understand now why you got no answers ? Everything is
left shrouded in mystery, and there's not enough information given
to solve the problem. |
|
|
Ttelmah Guest
|
|
Posted: Wed Mar 29, 2006 2:41 pm |
|
|
Also, as a further comment, 0x11D, is a very unusual CRC (9bits). Modifying an 8bit CRC, is not going to get very far for this...
Best Wishes |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Wed Mar 29, 2006 4:12 pm |
|
|
I thought the CRC.C and ex_crc in the samples would work.
The poly is defined. ... Don't you just refined the new one? |
|
|
iso9001
Joined: 02 Dec 2003 Posts: 262
|
|
Posted: Fri Mar 31, 2006 1:08 am |
|
|
I think there is plenty of information on the problem, I have a poly definded by outside sources as 11D and need an efficient CRC algorithm. My original question was if it was possible to modify the posted alg, or if anyone had an different one.
treitmey: Nah, ccs's is a 16bit CRC. Thanks for looking tho.
Ttelmah: Yea, I know its wierd. I have a feeling that 0x1D might also work but have not verified this.
What I don't understand is how Dallas has a poly of 0x99 but these are the number used in the code:
0x5e, 0xbc, 0x61, 0xc2, 0x9d, 0x23, 0x46, 0x8c
I'm still pretty confused how a I could set it up in a table driven application.
Anyone have experience with this ? |
|
|
jds-pic
Joined: 17 Sep 2003 Posts: 205
|
|
Posted: Fri Mar 31, 2006 9:06 am |
|
|
despite what YOU think, others are telling you there is not enough info.
iso9001 wrote: | I have a poly definded by outside sources as 11D and need an efficient CRC algorithm. |
we think you are misunderstanding the problem.
iso9001 wrote: | My original question was if it was possible to modify the posted alg, or if anyone had an different one. |
the dallas onewire algorithm has a peculiarity which makes it possible to use bytewide operations vs expensive bit shifting operations. while it is very possible that some bright guy/gal at dallas had the foresight to implement the polynomial this way, this type of peculiarity is not the general case for CRC algorithms. hence, you can't just change the onewire algorithm and expect that the peculiarity will continue on making your life easy. it's not that straightforward.
iso9001 wrote: | What I don't understand is how Dallas has a poly of 0x99 but these are the number used in the code:
0x5e, 0xbc, 0x61, 0xc2, 0x9d, 0x23, 0x46, 0x8c |
these are the "magic numbers" used to exploit the peculiarity noted above. they will not continue to work if you vary the polynomial, as explained above.
iso9001 wrote: | I'm still pretty confused how a I could set it up in a table driven application. |
set up a lookup table of the CRC values based on the CRC routine you have been provided.
iso9001 wrote: | Anyone have experience with this ? |
yes, 4 people with experience have replied to your query.
jds-pic
ps:
iso9001 wrote: | Can't wait till the day each pic has a tiny FPGA built-in... |
it is just as easy to screw up VHDL if you don't know what you are doing. in fact, we just discovered a bug in a Xilinx library (PortX) where the programmer concluded that 2^0=2. |
|
|
jds-pic
Joined: 17 Sep 2003 Posts: 205
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|