MCU Communication with CRC-CCITT
The receive interrupt on the PIC was tested, first with a basic ‘echo’ routine. This was then later expanded to apply the CRC routine on a single byte of data sent as a 4-byte payload. The ‘$’ symbol means that 3 more bytes are to follow:
packet[0] = $
packet[1] = single data byte
packet[2] = upper nibble of the CRC data
packet[3] = lower nibbler of the CRC data.
This is the output obtained over a live serial link at 19200-N81,
System Bootup...Online.
> HEARTBEAT OFF
> ECHO RX OFF
> CRC_TEST ON
.
>> CRC-CCITT of ASCII 'A': 0x58E5
>> CRC-CCITT of ASCII '123456789': 0x31C3
>> CRC-CCITT of ASCII 'ABC...XYZ': 0xE8AF
>> End of CRC Test.
.
Packet Received: |0x24|0x31|0x26|0x72| ($1&r)
CRC of '1' = 0x2672, MATCH!
.
Packet Received: |0x24|0x41|0x58|0x61| ($AXa)
CRC of 'A' = 0x58E5, FAIL!
This will be expanded to a much larger byte-payload which will carry the PWM duty cycle data and the final ‘total payload’ CRC double bytes at the end.
Even with a lot of redundant code, only ~46% of the ROM is being used. Preprocessor directives are being used to mark sections of code deemed to be ‘DEBUG’ related ect. At compile, this can be disabled by commenting a single line of code to make the final compile that much smaller and streamlined - a ‘gold master’ of sorts.
- CRC-CCITT Addendum…
- CRC-16, CRC-CCITT, and CRC-32
- CRC-CCITT on a MCU
- MARV Update…
A while back I posted a short article of my work on CRC-16, CRC-CCITT, and CRC-32. Few days ago, Joon posted a comment on this post pointing out a 'typo' in the program output. It should read, ASC...
The past 48 hours have been quite a ride. I really should be heading off to sleep, but instead...here I am posting on my blog. I spent the better part of yesterday evening right until around 8-9am...
Another successful afternoon where I launched Windows XP SP3 inside Parallels Desktop v3.0 for Mac, and connected to my MPLAB ICD2 PIC programmer. Yes, Wow! I managed to test some of the code ...
I hit a serious problem earlier on in the day. I had failed to notice that the PWM5 port on the 18F1330 was sharing the PGD pin and as such after each flashing of the MCU, the 3rd motor would not fun...

