Help with using for CRC-9 (not-byte-sized) about crc HOT 4 CLOSED

Hi @smarek,

generally the CRC output should be configureable on a bit size level. From my point of view at lest the bit sizes
[8, 64] should work fine as output widths.

Regarding the input data, I see a single byte as the smallest unit which is expected to be feed into the CRC calculation
(from the client code).
I personally don't plan to add support for feeding single bits into the CRC calculation from the client code.
If you have an idea (concept) or PR for this feature, I am open to discuss if and how we could add it.

best
Nico

P.S. happy holidays

from crc.

Hi @Nicoretti

thank you for reaction, but I think you've missed my point, the CRC-9 is not 9-bit sized just when producing final output, but the input is also not byte sized (135 bits) and i've seen in your code, you assume that the number of operations is // 8 meaning you'll miss few bits, and I'm afraid there are more similar assumptions in your code.

Or should I understand it so that if I pad the input with zeroes it should not change the calculation output?

Anyway you're not supposed to change anything, I just wanted to get clarification, on whether you think your code should be able to handle odd sized payloads and produce odd sized crc result, or not.

Similar project, where eg. CRC-3/CRC-4/CRC-5 and other odd sized calculations are supported by default, is https://sourceforge.net/projects/crccheck/files/
But I don't think you should change anything, unless you want to support similar algorithms as well.
And if you'd want to, there is self-test (see configuration of properties _check_data and _check_output) in there, so it should be really easy to unit-test and gradually add support for some of the algorithms, https://sourceforge.net/p/crccheck/code/ci/default/tree/crccheck/crc.py#l280

Also wish you nice and pleasant holidays, cheers!

from crc.

Or should I understand it so that if I pad the input with zeroes it should not change the calculation output?

No wasn't meant that way. I wrote the crc processing/calculation code quite a long time ago.
I need to read up on it again, but you are definitely right about that only chunks of 8 bits (1 byte) are supported as input.

So this must hold true for the input: amount_of_bits(input) % 8 == 0

I thought though the supported output size should be "arbitrary", but not 100% sure without checking in detail.

In any case, I have created #26 to track the "arbitrary" bit width issue you pointed out. I must say though, that
I'm currently focusing on other things. So I don't think I will be able to address this issue any time soon.

best
Nico

from crc.

Status quo should hopefully got clarified in the discussion above, the missing support for all crc widths is tracked in #26

from crc.