基于J.G.Fletcher的校验和算法

我的任务是实现基于J.G.Fletcher校验和和和ISO 8473-1:1998的校验和算法，描述如下：

然后，他们列出了4个可以检查的数据，以查看算法是否正确，但我的版本在最后两个值处失败。
0000给出FFFF的校验和
0000'00给出FFFF的校验和
ABCDEF'01的校验和为9CF8
1456'F89A'0001给出了24DC的校验和

我已经花了好几个小时来研究这个问题，但我找不到我做错了什么，一双新的眼睛可以帮我很大的忙

以下是我的功能：

uint16 Crc_CalculateISOChecksum(uint8 *pt_start_address, uint32  length)
{
    uint8 C0, C1;
    uint8 data;
    uint32 i;
    uint8 ck1, ck2;

    /* Initial value */
    C0 = 0;
    C1 = 0;

    /* memories - 32bits wide*/
    for (i=0; i<length; i++)    /* nb_bytes has been verified */
    {
      data = pt_start_address[i];   
      C0 = (C0 + data)%255;
      C1 = (C1 + C0)%255;
    }
    /* Calculate the intermediate ISO checksum value */
    ck1 = (unsigned char)(255-((C0+C1)%255));
    ck2 =  (unsigned char)(C1%255);
    if (ck1 == 0)
    {
      ck1 = MASK_BYTE_LSB;
    }
    if (ck2 == 0)
    {
        ck2 = MASK_BYTE_LSB;
    }
    return ((((uint16)ck1)<<8) | ((uint16)ck2));    
}

uint16 Crc\U计算同步（uint8*pt\U起始地址，uint32长度）
{
uint8 C0，C1；
uint8数据；
uint32Ⅰ；
uint8 ck1，ck2；
/*初始值*/
C0=0；
C1=0；
/*内存-32位宽*/
因为（i=0；i刚刚偶然发现了这一点。如果有人仍然感兴趣：你在错误的方向上迭代

不要从0迭代到length-1，而是从length-1迭代到0，这样就可以了

for (i = length-1; i >= 0; i--) // and change i to 'signed'

您的中间金额应为uint16（或您的行话中的uint16）

根据系统上的
char
和
int
是什么（例如，不要假设int的位数大于char），您的中间和可能会溢出。您的实现依赖于uint8\t的提升

举例说明：

 0xFF               0xFF
+0xFF              +0xFF
=====              =====
0x1FE % 255 = 0     0xFE % 255 = 254
  ^Retain            ^Drop

你说有问题…也许你也应该告诉我们为什么你认为，如果你需要帮助…你有错误吗？是什么？或者输出有错误吗？如何？对不起，我想我不太清楚我的问题是什么。在问题描述中，有四个数据是根据它们应该生成的校验和值提供给我的（0x0000=0xFFFF；0x000000=0xFFFF；0xABCDEF01=0x9CF8；0x1456'F89A'0001=0x24DC）当我尝试使用我的函数时，只有前两个数据产生预期的校验和，其他数据没有给我预期的值我再次运行测试，这里是我得到的值，而不是预期的值：0xFFFF（ok），0xFFFF（ok），0xFFF2（nok？！），0xFFD5（nok？！）我想知道这是否是一个Endian问题，因为我们正在使用Big Endian处理器，但事实并非如此：（校验和是位置相关的。必须从第一个（索引0）迭代到最后一个（索引N-1）元素。
 0xFF               0xFF
+0xFF              +0xFF
=====              =====
0x1FE % 255 = 0     0xFE % 255 = 254
  ^Retain            ^Drop