Follow-up Comment #4, bug #37901 (project avr-libc):
I disagree. The way you are looking at it is bitwise, but programmers these
days are probably looking at it bytewise. The USART takes care of bit order,
all the programmer gets is their byte in the DATA register.
That is exactly what I expected, so on one device I just fed the bytes in to
_crc_ccitt_update() and on the other one I spooled them into the XMEGA's
CRC.DATAIN. The results did not match, despite both claiming to be an
implementation of CRC-CCITT.
The XMEGA implementation matches all the publicly available code I found on
Google with a few quick searches. Many big and popular libraries include such
code. Naturally instead of re-inventing the wheel I use one of those
implementations in my desktop app and as a fix for the _crc_ccitt_update()
issue.
As I said, even if we don't rename anything it should at least be made clear
in the documentation. Personally I would suggest implementing three new
functions:
_crc_ccitt_avr_update()
_crc_ieee32_avr_update()
_crc_atmel_flash_avr_update()
I'm sure someone can think of better names. At least then people would be less
confused and compatibility with the AVR CRC generator hardware would be
explicitly mentioned.
I have code available for the ieee32 and atmel_flash CRCs, BTW. I will prepare
a patch.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?37901>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
