How do you generate cyclic redundancy method of Modbus CRC-16 verification program without displacement module?

MIT App Inventor Help
1

I don't have a clear idea. Please help me do the following code!


uint16_t Uart_CRC16(uint8_t *CRC_Buf,uint8_t CRC_Leni)
{
    uint8_t i,j;
    uint16_t CRC_Sumx;
    
    CRC_Sumx=0xffff;
    for(i=0;i
    {
        CRC_Sumx^=*(CRC_Buf+i);  //Òì»ò
         for(j=0;j<8;j++)
        {
            if(CRC_Sumx&0x01)
            {
                CRC_Sumx>>=1;
                CRC_Sumx^=0xA001;
            }
            else
            {
                CRC_Sumx>>=1;
            }
        }
    }
    return (CRC_Sumx);
}
2

This board's translation facilities can't translate this post.
Can you post an English version?

3

Because there is no displacement command, there is no good idea, but we have to do it. Ask for help building the post program. thank you!

4

This line of code is incomplete.

Also, I don't see any difference between this code and the code at your other post Crc校验码程序。crc校验码程序。crc校验码程序 - #2 by ABG

What is a displacement command?

5

Sorry, I was careless

for(i=0;i<CRC_Leni;i++）

For example, the displacement instruction is to shift the binary number 10010110 to the right, round off the end, add 0 to the first, 0 → 10010110, and the result is 01001011

I have tested the code shared by another post administrator. The CRC result generated by modulo-2 division is not ideal, so I insist on writing cyclic redundancy method. The attached figure shows the CRC results of unsatisfactory errors.

C

Z

6

I added hex conversion to the output in the version at Crc校验码程序。crc校验码程序。crc校验码程序 - #2 by ABG
(draggable)

when btnGo Click
when btnGo Click1834×204 45.7 KB

and got a result matching what you checked.

In the case of where you fed the program a byte sequence including 256 as a byte value, be aware that unsigned byte values should run from 0 to 255, so 256 is wrong.

Should the app complain about that, or silently "clean" it up?

3 Likes
7

程序已编辑好，如果有跟我一样因为没有右移指令的伤脑筋有缘人，请@我，我发给你。

8

thank! It is really a human error caused by my careless conversion of hexadecimal FF to decimal 256 input.