CRC must stand for Crazy Real Confusion

I’ve Come to a Reliable Conclusion upon working on CRC yesterday. Don’t try to understand what’s going on. Many walked this path before me, and yet I couldn’t look away at the promised cognitive pleasure of understanding it. In the end, I was denied this pleasure and here I am, left in frustration.

Well I might be a little bit exaggerating, but I’m sure that I’m miles away from having a grasp solid enough on CRCs to implement my own. For those who would want to do so though, this article from Barr’s group seems to stand as a reference, or at least a reliable entry point on the subject.

After going through this very good article I finally was able to run a 8 bit CRC on the STM. Basically, I followed the article and used pycrc to generate C files. I modified the code slightly to work with our STM, and dump the CRC in hex format on the uart communication.

Pycrc appeared to be a reliable tool, as you could specify some CRC model you want to implement, or more exhaustive parameters to implement your own CRC. This article is a solid reference on the best CRCs to implement, depending their lengths and the data lengths.

I now have to modify the dummy CRC function and adapt the code to use the newly generated CRC function to have a fully implemented CRC communication between ESP and STM.

Ideally, I should also write some code to simulate errors on the communication and verify that everything works well and edge cases don’t break the communication. I’ll probably do it if I manage to implement the shell before monday.

Leave a Reply

Your email address will not be published. Required fields are marked *