2
29/6/2014 CCS :: View topic - CRC16, very efficient http://www.ccsinfo.com/forum/viewtopic.php?t=24977&postdays=0&postorder=asc&start=15 1/2 FAQ Forum Help Official CCS Support Search Register Profile Log in to check your private messages Log in CCS does not monitor this forum on a regular basis. Please do not post bug Reports on this forum. Send them to [email protected] CRC16, very efficient Goto page Previous 1 , 2 CCS Forum Index -> Code Library View previous topic :: View next topic Author Message ckielstra Joined: 18 Mar 2004 Posts: 3557 Location: The Netherlands Posted: Fri Nov 16, 2012 5:27 pm Quote: While trying to understand the code I found I could replace the two rlcf with one rlncf on a PIC18. Nice find! I have updated my code at the start of this topic to include this improvement. downybear Joined: 18 Nov 2012 Posts: 1 Poly change impossible? Posted: Mon Nov 19, 2012 2:50 am Hi, I have found this discussion with very elegant solution for CRC16 for embedded projects. I would change poly to CRC16-ARC - 0x8005. I think it should be for 0x8005: Code: crc = (crc << 8) ^ (x << 15) ^ (x << 2) ^ x; instead of 0x1021 Code: crc = (crc << 8) ^ (x << 12) ^ (x << 5) ^ x; Additionally original CRC16-ARC starts from crc=0x0000 and needs bits reflecting in input bytes and reflecting crc bits on output (0b11010010 -> 0b01001011). I have a set of W. Erhardt applications (SRP, TCRC) as a reference calculations but I can't get proper CRC with this algorithm after poly change. I have written small app in Delphi using code presented here and I have got same results like in PIC18 environment - good CRC calculations for 0x1021 and bad calculations for 0x8005 poly. To do bits reflecting I have used functions copied from W. Erhardt applications. My mistakes or ..... algorithm for 0x1021 only? - I do not want to believe.. Any ideas? Regards Mariusz One hour later... I have repeated some steps of my discovering and now I have found notice from the Ashley Roll:

CCS __ View topic - CRC16, very efficient2.pdf

Embed Size (px)

Citation preview

Page 1: CCS __ View topic - CRC16, very efficient2.pdf

29/6/2014 CCS :: View topic - CRC16, very efficient

http://www.ccsinfo.com/forum/viewtopic.php?t=24977&postdays=0&postorder=asc&start=15 1/2

FAQ Forum Help Official CCS Support Search

Register

Profile Log in to check your private messages Login

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them [email protected]

CRC16, very efficientGoto page Previous 1, 2

CCS Forum Index -> Code Library

View previous topic :: View next topic

Author Message

ckielstra

Joined: 18 Mar 2004Posts: 3557Location: TheNetherlands

Posted: Fri Nov 16, 2012 5:27 pm

Quote:

While trying to understand the code I found I could replace the two rlcf with one rlncf on a PIC18.

Nice find!

I have updated my code at the start of this topic to include this improvement.

downybear

Joined: 18 Nov 2012Posts: 1

Poly change impossible?

Posted: Mon Nov 19, 2012 2:50 am

Hi,

I have found this discussion with very elegant solution for CRC16 for embedded projects.

I would change poly to CRC16-ARC - 0x8005.

I think it should be for 0x8005:

Code:

crc = (crc << 8) ̂ (x << 15) ̂ (x << 2) ̂ x;

instead of 0x1021

Code:

crc = (crc << 8) ̂ (x << 12) ̂ (x << 5) ̂ x;

Additionally original CRC16-ARC starts from crc=0x0000 and needs bits reflecting in input bytes and

reflecting crc bits on output (0b11010010 -> 0b01001011).

I have a set of W. Erhardt applications (SRP, TCRC) as a reference calculations but I can't get proper

CRC with this algorithm after poly change.

I have written small app in Delphi using code presented here and I have got same results like in

PIC18 environment - good CRC calculations for 0x1021 and bad calculations for 0x8005 poly. To do

bits reflecting I have used functions copied from W. Erhardt applications.

My mistakes or ..... algorithm for 0x1021 only? - I do not want to believe..

Any ideas?

Regards

Mariusz

One hour later...

I have repeated some steps of my discovering and now I have found notice from the Ashley Roll:

Page 2: CCS __ View topic - CRC16, very efficient2.pdf

29/6/2014 CCS :: View topic - CRC16, very efficient

http://www.ccsinfo.com/forum/viewtopic.php?t=24977&postdays=0&postorder=asc&start=15 2/2

Quote:

* I've used the Standard CCITT CRC16 polynomial as this "standard" * doesn't use any of the bit reflection that confuses the implementation. * This polynomial is 0x1021 but you could use any you like.

Full text is here:

http://www.digitalnemesis.com/info/codesamples/embeddedcrc16/gentable.c

So it means that when bits are reflecting something can go wrong.

Looking for another solutions I have found:

http://miscel.dk/MiscEl/CRCcalculations.html

There are some Pascal examples of table and non-table CRC calculations.

I have checked immediately function CRC16 bit, inverted/reversed/reflected and I have got good

result.

I have translated it to C and it works in PIC18F environment as well

Here is the final, not optimized yet code:

Code:

unsigned int Calc_CRC_C_ARC(unsigned char *Buffer, unsigned int Len, unsigned

int crc_seed)

{

crc = crc_seed;

while(Len--)

{

bufdat = *Buffer++;

crc = crc ̂ bufdat;

for (i = 0;i < 8; i++)

{

if ((crc & 0x0001) !=0)

{

// Expected poly should be bits reflected so 0xA001 used instead of 0x8005;

crc = (crc >> 1) ̂ 0xA001;

}

else

{

crc = crc >> 1;

}

}

}

// Swapping final CRC nibbles

crc = (crc >> 8) | (crc << 8);

printf("CRC ARC: Seed: %.4x; Val: %.4x\r\n",crc_seed, crc);

return crc;

}

Now I will optimize the code and check if this is fast enough for me, if not I will go to assembler.

I hope that it can be useful for somebody

Regards

Mariusz

Display posts from previous: All Posts Oldest First Go

CCS Forum Index -> Code LibraryAll times are GMT - 6 Hours

Goto page Previous 1, 2

Page 2 of 2

Jump to: Code Library Go

You cannot post new topics in this forumYou cannot reply to topics in this forum

You cannot edit your posts in this forumYou cannot delete your posts in this forum

You cannot vote in polls in this forum

Powered by phpBB © 2001, 2005 phpBB Group