AP_Math: split CRCs from checksums

[tpwrules]

All CRCs are checksums but not all checksums are CRCs.

Paves the way for deduplication and unification of CRC implementations, including interface and standard of implementation.

No functional change yet. Hopefully this cleanup is appreciated.

[tridge]

No functional change yet. Hopefully this cleanup is appreciated.

I'm a bit sceptical of the benefit of this change. Can you point at some examples of the ultimate benefit? I'm well aware of the distinction between crc and checksum, but for our purposes that is an implementation detail and really only of academic interest

[tpwrules]

The benefit is that by separating out the CRCs, we can switch to a common implementation for them. There is a known taxonomy (see section 15 here) and there are various code generators and template libraries available given those parameters.

This lets us identify and remove duplicates (e.g. crc_xmodem, crc16_ccitt) and intelligently switch between bit-wise or byte-wise computation with the space/speed tradeoff. We can also remove all the warts of the different functions (argument order, width of input size) and reduce flash usage.

[peterbarker]

The benefit is that by separating out the CRCs, we can switch to a common implementation for them. There is a known taxonomy (see section 15 here) and there are various code generators and template libraries available given those parameters.

This lets us identify and remove duplicates (e.g. crc_xmodem, crc16_ccitt) and intelligently switch between bit-wise or byte-wise computation with the space/speed tradeoff. We can also remove all the warts of the different functions (argument order, width of input size) and reduce flash usage.

That all sounds good. Have you seen a project which does this sort of heavy-reuse of CRC calculation?

[tpwrules]

That all sounds good. Have you seen a project which does this sort of heavy-reuse of CRC calculation?

No, I'm not really aware of anything else that needs to compute so many varied CRCs.

I looked into this in a bit more detail and while I still think this cleanup is valuable and worthwhile, the followup work will probably desire an extreme amount of testing and I can't commit to it right now. It's also not likely to save much flash in particular. It's more targeted towards reducing the code amount and simplifying it.

[peterbarker]

Decided this was a bad rename

[tpwrules]

Going to come at this in a less invasive manner some time in the future.