Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

CRC16 from QByteArray and big/little endian questions



  • Hi,

    i have a working code to get a CRC16 from a QByteArray.

    quint16 MUDPIPackage::calculateChecksum(QByteArray ba)
    {
        uint16_t *buf = (uint16_t*)( ba.data() );
        size_t len = static_cast<size_t>( ba.size() );
    
        uint32_t sum;
        // Calculate the sum                                            //
        sum = 0;
        while (len > 1) {
            sum += *buf++;
            if (sum & 0x80000000)
                sum = (sum & 0xFFFF) + (sum >> 16);
            len -= 2;
        }
        if (len & 1)
            // Add the padding if the packet length is odd          //
            sum += *((uint8_t *) buf);
    
        // Add the carries                                              //
        while (sum >> 16)
            sum = (sum & 0xFFFF) + (sum >> 16);
        // Return the one's complement of sum                           //
        return static_cast<quint16>( ~sum );
    }
    

    But i have some questions to the endianness of the data in QByteArray?

    1. What kind of endanness should the data() of QByteArray have?
    2. Must i interprete the result of CRC16 always as little endian, idependent of the endianness of data()?
    3. What if the data() is partly big and partly little endian?

    I'm a little or big confused about the endianness? :-)
    Thx


  • Lifetime Qt Champion

    Hi @MECoder,

    What kind of endanness should the data() of QByteArray have?

    That's totally up to your requirement. The data is in the array as you put it in.

    Must i interprete the result of CRC16 always as little endian, idependent of the endianness of data()?

    Same as one. I have implemented protocols where the data is in Big Endian format (like Ethernet) but also RS-422 protocols with Little Endian encoding.

    What if the data() is partly big and partly little endian?

    How should that happen?

    To summarize: the endianess of data in an array is up to you. What's you cannot change is the endianess of int-types. These only depend on the processor architecture, e.g. Intel: Little Endian, Motorola: Big Endian.

    Hope that helped. Regards



  • @aha_1980 said in CRC16 from QByteArray and big/little endian questions:

    Hi @MECoder,

    What kind of endanness should the data() of QByteArray have?

    That's totally up to your requirement. The data is in the array as you put it in.

    I thought that a CRC expects the data to be little endian.

    What if the data() is partly big and partly little endian?

    How should that happen?

    It's very easy. The QByteArray contains a 32 Byte Header (big endian) and a payload (little endian).
    The numeric values of the Header are serialized as big and the payload values are serialized as little-endian.
    And you can also serialize a 32-bit integer as little or big-endian. The CRC16 is part of the Header.
    This was specified by our customer.

    If the data is big-endian, is the CRC also big endian?
    If the data is little endian, is the CRC also little endian?
    or does it depend on the CRC code?
    My guess (or feeling) is, that it's not good to build a CRC over the QByteArray with big and little endian data.

    Thx for your help


  • Lifetime Qt Champion

    @MECoder said in CRC16 from QByteArray and big/little endian questions:

    This was specified by our customer.

    A-ha! There you have it, it's all about specification.

    If the data is big-endian, is the CRC also big endian?
    If the data is little endian, is the CRC also little endian?

    Can be, will most often be, but must not be.

    or does it depend on the CRC code?

    No.

    My guess (or feeling) is, that it's not good to build a CRC over the QByteArray with big and little endian data.

    No, it does not matter. A CRC is just a checksum over bits, it does not care about the meaning of the bits. The CRC just guarantees that the data is unchanged.

    Regards


Log in to reply