sys/checksum: Adding three new crc16 variations

[Teufelchen1]

Moin! 👋

Contribution description

This PR adds three new crc16 variations:

• ccitt-false
• ccitt-kermit
• mcrf4xx

The old "ccitt" was renamed to ccitt-aug as this is the "correct name" for the given implementation.
Since CRCs aren't really standardised, the names are vague, many have alias. I tried to stick close to what other software projects use (linux, pypi.org/project/crccheck, etc.).

Testing procedure

I kept the original test - duplicated & renamed it accordingly.

[miri64]

The old "ccitt" was renamed to ccitt-aug as this is the "correct name" for the given implementation.

This might lead to confusion for users that use the old ccitt. Maybe, it is best to move this through proper API aliasing and deprecation, i.e. introduce new crc16_ccitt_*() inline functions that wrap around crc16_ccitt_aug_* and add a @deprecation note that this function will be removed in 2 release cycles (i.e. 2023.01 if this PR gets merged soon). That node could also include a mention that crc16_ccitt_aug_* should be used instead.

[Teufelchen1]

This might lead to confusion for users that use the old ccitt. Maybe, it is best to move this through proper API aliasing and deprecation, i.e. introduce new crc16_ccitt_() inline functions that wrap around crc16_ccitt_aug_ and add a @Deprecation note that this function will be removed in 2 release cycles (i.e. 2023.01 if this PR gets merged soon). That node could also include a mention that crc16_ccitt_aug_* should be used instead.

@miri64 like this? :)

[miri64]

This might lead to confusion for users that use the old ccitt. Maybe, it is best to move this through proper API aliasing and deprecation, i.e. introduce new crc16_ccitt__() inline functions that wrap around crc16_ccitt_aug__ and add a @Deprecation note that this function will be removed in 2 release cycles (i.e. 2023.01 if this PR gets merged soon). That node could also include a mention that crc16_ccitt_aug_* should be used instead.

@miri64 like this? :)

Yes, but you also could make this function also now a static inline ... around crc16_ccitt_false_update() now to make the pending deprecation clearer.

Other than that, some formatting issues remain.

[miri64]

Is this what you intend the documentation to look like?

In case you do not and my code-based proposal did not work for you (which would look like this)...

... a table could also be an option:

Suggested change

	* @details polynom=0x1021
	* seed=0x1d0f
	* check=0xe5cc
	*
	* Parameter | Value
	* --------: | :----
	* Polynom | `0x1021`
	* Seed | `0x1d0f`
	* Check | `0xe5cc`

[Teufelchen1]

[..] and my code-based proposal did not work for you (which would look like this)...

You proposal was great, I just forgot about it - should not have pushed last minute before heading home...
I like the table idea - I picked it up and added some other values as well. Without going to much into detail: These parameter specify / identify one particular CRC algorithm, no more naming confusion! I initially omitted them since the check is already enough but the tables were just asking for more data. 😀

Thanks for providing your insights, I valued it a lot! :)

[miri64]

Please fix the issues pointed out by the static-tests. Other than that, I think this is ready for ACK now.

[miri64]

Ran the new tests on native and iotlab-m3. Found a minor nit. Feel free to address or not.

[MrKevinWeiss]

Kicking this out of the CI queue until master is fixed (or blacklisted)

[MrKevinWeiss]

Rerunning now that master should pass...