>> See this thread on AVRFreaks for some of the needed code for the >> external program. >> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=80405 >> > Did you get that code from Atmel?
I make reference to Atmel supplying some broken code some place, that was the basses for that message. I sent what I fixed back into them, which might be what they are sending out now. It is basically the same code I get from Atmel support, this is the PC version taking an octet stream and the length of data to compute as input: Thank you. > app section CRC) we end with an odd number of bytes to compute. Do we need to > add a byte valued to 0 at the end? Probably. > I can't understand how they process 16 bits at a time without doing a loop > through all bits or using a precomputed table. I would suspect at the hardware level it is shift registers. > I'm not a math guru but this seems to broke the mathematical principles at > the base of CRC calculations. Which is what I suspect. > If you can test this and find out what's wrong and maybe make it works, > it would be a very nice thing and perhaps we could add the routine to > the avr-libc help to make it available to everyone. Real Soon Now... >> I was referring to die revision J. That is what Atmel said they would >> fix the CRC Rage problem in. >> > That makes my laugh! They are stuck on rev.H with plenty of errors to > fix for two years and they expect to solve the CRC problem not in the > next revision but in the one after? When they expect to release the J > revision, in 2013 or later? Come on, I have firmwares full of patches > and tricks to overcome XMEGA faults! It is common to skip the letter "I" because it looks like the number "1". I do agree with you. _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
