Age | Commit message (Collapse) | Author | Files | Lines | |
---|---|---|---|---|---|
2020-09-04 | move old software snippets and hacks to software/obsolete | Harald Welte | 1 | -56/+0 | |
2018-05-12 | CRC4: use proper CRC4 table to avoid bit-reversal of each byte | Harald Welte | 1 | -23/+50 | |
In commit 9bd2c9ffe7cf82c5d0a12406db018717d9b78858 we fixed the CRC4 computation by bit-reversing every byte before using it in the CRC table. This is of course a waste of CPU cycles. Let's just compute the CRC4 table slightly different (thanks to Dietter): The following commands using pycrc from pycrc.org were used: ./pycrc.py --width=4 --poly=0x3 --reflect-in=false --reflect-out=false --xor-out=0 --xor-in=0 --algorithm table-driven --generate c -o crc4itu.c ./pycrc.py --width=4 --poly=0x3 --reflect-in=false --reflect-out=false --xor-out=0 --xor-in=0 --algorithm table-driven --generate h -o crc4itu.h | |||||
2018-05-11 | HACK to make CRC4 computation work | Harald Welte | 1 | -1/+2 | |
* reverse bit-order of every input byte when computing CRC4 * reverse bit-order of CRC4 value we receive in TS0 bits I don't really understand why, but this makes the CRC check pass. We probably need another table if we want to avoid this. | |||||
2018-05-07 | WIP: Software for E1 mux/demux | Harald Welte | 1 | -0/+28 | |