On Saturday, July 20, 2019, 9:10:36 AM, Tomasz Mon wrote:
> On Sat, Jul 20, 2019 at 5:37 AM Tomasz Mon <desowin@xxxxxxxxx> wrote:
>> The advantage of 1) over 2) is the ability to be able, if the CRC is
>> incorrect, to tell what the correct CRC should have been.
>> Approach 2) allows only to veify if the CRC is correct - but at the
>> advantage of being able to take full bytes as input.
> Approach 2) is now implemented [1].
One of the properties of LFSRs is that a 1 bit in the input toggles a
completely predictable set of register bits *at any point in the
future*. This isn't often useful for most CRC caculations on variable
sized input, as the cost of working out which those bits are vastly
outweighs most other methods.
But here we have a fixed 11 bit input, so we don't need to carry
around such a big table:
int crc5(int v)
{
static const char ival = 0x08;
static const char bvals[11] = {
0x1f, 0x1d, 0x1c, 0x0e, 0x07, 0x11, 0x1a, 0x0d, 0x14, 0x0a, 0x05
};
int rv = ival;
for ( int i=0 ; i<11 ; i++ ) {
if (v & (1<<(10-i))) rv ^= bvals[i];
}
return rv;
}
(Tested and produces same values as USB spec's example perl script.)
> [1] https://code.wireshark.org/review/#/c/34025/
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
John
--
Dead stars still burn
