Page 1 of 1

UART CRC Check

Posted: Wed Sep 05, 2018 7:55 am
by Lord Grezington
Hello Everyone...

I have this project where I am trying to communicate with an IC that has a difficult CRC check. Anyone have any idea how I would implement this with Flowcode?

Thanks
CRC.jpg
CRC.jpg (90.67 KiB) Viewed 5163 times

Re: UART CRC Check

Posted: Thu Sep 06, 2018 1:47 pm
by Benj
Hello,

Yes that should be fine.

First create a byte variable named CRC and initialise it to 0.

Next create a loop icon that will run 8 times, you need to run this loop for every byte you send or receive so it might make sense to put the loop in a macro you can call when sending or receiving bytes. Next create a variable named data you might want to make it local to the macro if you created one.

You can simply do the following using a decision and calculation icons inside the loop. Remember to load the .Data variable with the byte value that's been received or ready to transmit before the loop.

Code: Select all

Decision:  (CRC >> 7) ^ (.Data & 0x01)
Yes: Calculation: CRC = (CRC << 1) ^ 0x07
No: Calculation: CRC = (CRC << 1)

Calculation: .Data = .Data >> 1

Re: UART CRC Check

Posted: Wed Sep 12, 2018 9:41 am
by Lord Grezington
Hi Ben

Works great, thanks again...

Re: UART CRC Check

Posted: Mon Nov 05, 2018 7:49 pm
by Brendan
As I use CRCs with Flowcode a lot (particularly Maxim 1-wire, etc), and assuming you've got 256 Bytes of program memory to spare for an 8-bit CRC, I'd like to chip in with a popular alternative of pasting a 256-byte table (relevant to your CRC polynomial) to the Flowcode LUT component.

Such CRC tables may be published by manufacturers in application notes, or can be found on the internet - though always wise to test/debug with an arbitrary Byte string and see if your result concurs with an online calculator.

The primary benefit to this approach is speed, particularly when streaming out/in indeterminate amounts of data with limited PIC speed...

CurrentCRC XOR DataByte = LUTindex, the returned Byte from that location being the new CRC.

Such an approach also applies to 16-bit CRCs and higher, with code space trade-off and appropriate Byte-shifting, but where speed gain becomes even more noticeable.

All the best,
Brendan