I did the comparison on an AVR implementation with a CRC-16 with the 1021 poly. This was about 4 years ago so I do not recall the exact details but as close as I can remember the nibble is about 2.5 times faster than the bit serial mode. The byte table mode is about 1.5 times faster than the nibble mode.

On some processors the table lookup is more inefficient than on others (when the table is a constant array in the code space). This is particularly true on Harvard architecture processors such as AVRs and 8051s where data access to code space is cumbersome with the instructions provided.

I found it essential to have the speed gain that the nibble mode offered me over the bit serial method because we were using it to check the code FLASH CRC each time the system powered up. This power-up check was a customer requirement but the real time nature of the embedded application needed less than 400 msec reset to code start. When using the bit-serial-code, which I had originally inherited when I took over a project, the startup time was hovering around 950 msec.

Computational requirements for a CRC-8 are less than a 16-bit CRC algorithm so embedded developers can take that into account if they can drive the selection of the algorithm in use. Do note however that the error coverage of an 8-bit code is much lower than a 16-bit code. This is of particular concern when the payload that is being CRC'ed gets longer and longer in number of bytes. Of course many times there is no choice to be made if the CRC method is selected by the other end of the interface to your MCU.

Michael Karas