Darell is it too much asking what CRC stand for?
Al.
Darell is it too much asking what CRC stand for?
Al.
All progress began with an idea
Too much ... nope.
Too little ... maybe.
Cyclic Redundancy Check
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
<br>
DT
Darrel, thank you for the link.
Al.
All progress began with an idea
Darrel,
Thanks for explaining that, you are a mine of information. I would have just used -
IF CRC.15 THEN
CRC =CRC *2 'shift left one bit
You obviously know pbp intricately, and maybe need more time in the pub! I would certainly buy you a few beers
Tim.
Hi,
I'm struggling with this as well. I have the follwing CRC routine working properly:This works properly for what I'm doing (MODBUS) but is painfully slow. Darrel said he got 825us for 9 bytes @4Mhz. This thing takes 2837 cycles for 9 bytes....Code:MB_CRC = 65535 ' Initialize CRC value MB_k = MB_Buffer_Ptr - 3 ' Find out where in the array to stop. T1CON = 1 FOR MB_i = 0 to MB_k ' Iterate thru the frame, stop before the last two bytes which are the actual CRC. MB_CRC = MB_CRC ^ MB_Buffer[MB_i] ' Bitwise EXOR the current low byte of the CRC "value" with the byte in the buffer FOR MB_j = 0 to 7 ' Cycle thru the low byte of the CRC value If MB_CRC.Bit0 THEN ' If the LSB is set MB_CRC = MB_CRC >> 1 ' We shift CRC on bit to the right.... MB_CRC = $A001 ^ MB_CRC ' and EXOR it with out polynomial for MODBUS CRC-16 ($A001) ELSE MB_CRC = MB_CRC >> 1 ' If the LSB is not set we simply shift CRC one bit to the right. ENDIF NEXT ' Next bit in the byte NEXT ' Next byte in the frame T1CON = 0 RETURN
Giving it 67 bytes and it it takes ~14000 cycles to return the 16 bit CRC value.
To my naked eye this looks fairly close to the Darrels routine but this uses another polynomial (which I can't see making any difference time wise) and it's "reversed".
I've rearanged a couple of things, splitting statements in two etc which has gained me a bit of performance but now I seem to be stuck. Again, it works properly which is the most important thing but can anyone tells me what the h..l is taking so long ;-)
Thanks!
/Henrik.
Hello again,
Seems like I was a bit off in my timings as I was actually feeding the CRC routined more bytes than I thought (I measured the time for the incomming AND outgoing frames) so it's a bit better but still not near Darrels numbers.
I've moved the starting and stopping of the timer so it's "around" the GOSUB that calls the CRC routine so the numbers below includes jumping to and from the routine.
If I feed it the same 9 bytes is in Darrels example (123456789) it takes 1730 cycles to execute while Darrels routine does it half of that time. For a 67 byte array it takes ~12600 cycles, obviously depending sligthly on what's "in" the bytes.....
If anyone has any pointer to how I could increase the performance of this I'm all ears.
Thanks!
/Henrik.
Looking for some confirmation that DT's CRC calculation routine will work with CRC-8.
This is two typical samples of what I have incomming from a Fine Offset WH2081 weather station transmitter.
FF AD 42 CB 16 05 06 00 6C 0E 87
FF AD 42 CC 16 05 08 00 6C 0C 0D
FF is a preamble, and the last byte is CRC-8 using the polynomial x^8 + x^5 + x^4 + 1 (which I think becomes the constant $131 for calculations).
The middle 9 bytes are data, and used for the CRC byte sent by the TX.
Do I have it right that DT's code could be used directly if the CRC_Len and CRC_poly constants are changed as below ?
CRC VAR WORD
CRC_IN VAR BYTE
Idx VAR BYTE
CRC_Len CON 8
CRC_Poly CON $131 ; x^8 + x^5 + x^4 + 1
;-----CRC-16 -----------------------------------------------------
CRC16:
CRC.HighByte = CRC.HighByte ^ CRC_IN
FOR Idx = 0 to 7
IF CRC.0(CRC_Len-1) THEN
CRC = (CRC << 1) ^ CRC_Poly
ELSE
CRC = CRC << 1
ENDIF
NEXT Idx
RETURN
If so, is it just a matter of setting the CRC_IN byte to each value of the nine data bytes in turn while looping through CRC16: each time, the wanted result being the value of CRC after the ninth loop ?
Or is there stuff to be done after each result of subroutine CRC16 ?
Thanks if anyone can confirm that for me before I try to hack my receiver code to pieces.
Martin
Bookmarks