If I recall correctly, that author's conjecture about the correct result is know to be wrong. Your issue about needing to know all the parameters for correct implementation (initial value, bit processing order, complementing final value, etc.) is well founded.

Here's a C implementation of the type of algorithm that Jan posted, but that processes the bits in the LSBit-first order as they would be on-the-wire for UART exchange and as defined by the HDLC standard(s). It has been tested against HDLC protocol test equipment. I have adapted it to be most similar to Jan's code for the purpose of seeing how poorly the C version performs in comparison (28 cycles).

unsigned char CRCLo, CRCHi;

void CRCNib(unsigned char b)
{
    CRCLo ^= b;
    b      = CRCHi;
    CRCHi  = CRCLo ^ (CRCLo << 4);
    CRCLo  = b;
    CRCLo ^= (b = CRCHi >> 4);
    b      = CRCHi ^ (b >> 1);
    CRCLo ^= CRCHi << 3;
    CRCHi  = b;
}