As I am using Low end Micro-controller (PIC18), I don't want to implement CRC. Suggest if anything which works better.
I want to produce 1-byte CRC for 26 bytes . Can you share sample code?
Responding to the above two items....
First of all a PIC18 will do CRC just fine. Personally I use CRC16 or CRC32 regularly. Using a table-based CRC generation code is fast and easy. 8 Bit CRC algorithms are available which are 100% table driven which become really really fast. Personally, I'd use at least 16 bits of CRC, but that's just me. Especially if you're sending so little data, you can afford an extra byte for robustness if you really care.
You should temper the above with what others have said : If this is hardwired and local, the chances of a bit error is minimal at 9600bps, so maybe you really don't need the overhead. I'm more of a better safe than sorry person myself.
If you really don't want the overhead of a CRC, but still want some basic checksum, a really simple checksum is to just XOR each byte with the sum of each previous one. So for each message you start at '0' in your checksum value, and then for each character you do the following:
checksum^=ch;
Instead sending it in HEX format, do u want me send it in ASCII format ?.If so, it will definitely increase payload size right?.As the Application is timing critical, decoding all the packets back to Hex at PC side and Encoding it in TX side for every transmission will be a big challeng for me.
How about appending Length of payload after HEADER?
It is almost always safer to not encode length, but instead some sort of framing indicator. If you're sending this to a PC, I sure would be tempted to just encode the whole thing in ASCII, and use CRLF as the terminator, so you get strings on the PC which look like:
ff23723af342473f237223a32234ff23723af342473f237223a32234
The advantage of doing this is that it is really easy to separate out messages on the PC - you're just looking for hexadecimal characters followed by a 0x0d 0x0a.
Once you've sorted out how to detect a complete message, it is ok to embed frame lengths as part of the message.. But the over the wire protocol should not rely on length to detect the start and and of a frame.