Some thoughts:

• where is the algorithm from?
• how does code size compare?
• how does the runtime compare (a bit more concrete would be nice ;-))?
• I think it would make sense to add a ucrc16_calc that uses the hosts endianness (so that we can have platform independent code using this API)
• maybe the comparison (implementation choosing help) could move to the http://api.riot-os.org/group__sys__checksum.html page, and this and the other implementations doc point there?

Some thoughts:

• where is the algorithm from?

This is pretty much the standard version of the algorithm (the table version is the special optimized one ;-)), so you find it in any standard literature on the topic. In my case it's from Wikipedia, but its also e.g. written down in the reference you gave in your unittests for CRC16-CCITT. (OT: For what is that particular implementation for? The seed you used isn't mention in any spec I saw).

• how does code size compare?

With cosy (from the unittests) on iotlab-m3:

module                                                          text    data     bss     dec     hex
------------------------------------------------------------------------------------------
[…]
.... .... _crc16_lookuptable                                     512       0       0     512     200
.... .... crc16_ccitt_update                                      36       0       0      36      24
[…]
.... .... ucrc16_calc_le                                          40       0       0      40      28
.... .... ucrc16_calc_be                                          42       0       0      42      2a
.... .... crc16_ccitt_calc                                        12       0       0      12       c

on samr21-xpro:

.... .... _crc16_lookuptable                                     512       0       0     512     200
.... .... crc16_ccitt_update                                      36       0       0      36      24
[…]
.... .... ucrc16_calc_le                                          42       0       0      42      2a
.... .... ucrc16_calc_be                                          46       0       0      46      2e
.... .... crc16_ccitt_calc                                        20       0       0      20      14

on z1:

.... .... _crc16_lookuptable                                     512       0       0     512     200
[…]
.... .... crc16_ccitt_update                                      34       0       0      34      22
[…]
.... .... ucrc16_calc_le                                          44       0       0      44      2c
.... .... ucrc16_calc_be                                          72       0       0      72      48
.... .... crc16_ccitt_calc                                        14       0       0      14       e

So the sizes of the actual code are comparable with the lookup-table being the caveat of the table version (which also grows linear if e.g. two CRC versions are present in the code).

• how does the runtime compare (a bit more concrete would be nice ;-))?

Did not test, but since the table-version goes byte-wise, while the non-table-version goes bit-wise, it is expected, that the non-table-version is 8 times slower ;-).

• I think it would make sense to add a ucrc16_calc that uses the hosts endianness (so that we can have platform independent code using this API)

This makes no sense at all IMHO. In most use-cases relevant for RIOT CRC is used to calculate a checksum for a packet going over the wire (mostly e.g. for PPP in big endian, for IEEE 802.15.4 in little endian).

• maybe the comparison (implementation choosing help) could move to the http://api.riot-os.org/group__sys__checksum.html page, and this and the other implementations doc point there?

Can do, but the simple explanation is: if you don't have memory (especially if your code demands more than one flavor of CRC16): use ucrc16. Else use crc16_ccitt (with caution).

Or to quote Wikipedia:

This [version] is usually the most compact software implementation, used in microcontrollers when space is at a premium over speed.

So exactly what most of our target platforms are ;-)

• maybe the comparison (implementation choosing help) could move to the http://api.riot-os.org/group__sys__checksum.html page, and this and the other implementations doc point there?

Can do, but the simple explanation is: if you don't have memory (especially if your code demands more than one flavor of CRC16): use ucrc16. Else use crc16_ccitt (with caution).

Done

• I think it would make sense to add a ucrc16_calc that uses the hosts endianness (so that we can have platform independent code using this API)

This makes no sense at all IMHO. In most use-cases relevant for RIOT CRC is used to calculate a checksum for a packet going over the wire (mostly e.g. for PPP in big endian, for IEEE 802.15.4 in little endian).

CRCs are also used for integrity checks on (RAM, ROM, flash etc.) memory. So IMHO this is a relevant use-case. There is just no code in RIOT yet that does this ;)

(OT: For what is that particular implementation for? The seed you used isn't mention in any spec I saw).

I can not answer your question anymore and don't have time to re-research but googling around a bit you will find some indication that it actually exists outside RIOT..

CRCs are also used for integrity checks on (RAM, ROM, flash etc.) memory. So IMHO this is a relevant use-case. There is just no code in RIOT yet that does this ;)

True, but then it really doesn't matter what byteorder you choose as long as you use the same function for calculating and checking the checksum. => The default could always be _be (or _le) since it is only used locally (if not you need to decide on a byte-order again).

Anyway, would be happy to see this (and maybe #6121?) merged at today's Hack'n"ACK

CRCs are also used for integrity checks on (RAM, ROM, flash etc.) memory. So IMHO this is a relevant use-case. There is just no code in RIOT yet that does this ;)

True, but then it really doesn't matter what byteorder you choose as long as you use the same function for calculating and checking the checksum. => The default could always be _be (or _le) since it is only used locally (if not you need to decide on a byte-order again).

I am still not convinced, but if you don't want to do it at this point that's fine with me.

Squashed

Excluded more boards from linking the unittests and squashed immediately.

@miri64 this PR needs love

And would be a better time of the year for that? ;-)

PR loved ;-)