We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
(Sorry for my limited English ability and limited technical ability.)
I have been requested to design an I/O-Control (Communication) Protocol. This simple protocol is designed for a LPC23xx based USBCDC, the USBCDC software solution is based on the open source project LPCUSB. The USB Host side is a Linux X86 platform. So that, the Linux X86 platform can control the I/O Port of my LPC23xx board via USBCDC connection.
Due to my limited technical ability, I am afraid that, I may make some obvious mistakes, or be unable to consider some complicated scenarios. So, please kindly give me some advices.
This simple protocol:
======================== 0xDEF0 -> 2Bytes (Head, 0xDE first) >=======Content=======< Length -> 2Bytes (Little-Endian) C-Type -> 3Bytes C-Data -> 13Bytes (Variable Length) CRC-32 -> 4Bytes (Little-Endian) >=======Content=======< 0xDE0F -> 2Bytes (Tail, 0xDE first) ======================== Length = C-Type size + C-Data size CRC-32 is for { Length, C-Type, C-Data } Stuffing Rule -> Tx-Side replaces all 0xDE of the Content with 0xDEAA Rx-Side replaces all 0xDEAA of the Content with 0xDE So that, the Length and CRC32 fields are also stuffed.
This is my first time doing the Bit Stuffing, are there any obvious defects or potential problems on my design?
And, if my design is acceptable, then I have a question, will the Stuffing break the CRC32 Error Detection? Because, the transmitted data is stuffed, not the same as the original one.
Yes, of course.
Having RLL-encoded data you are only safe when your bit errors are covered by the hamming distance of the patterns used in the stuffing. As soon as a pattern gets more damaged, you lose synchronization. Which may either result in incorrect decoding of following patterns or in the receiver seeing an invalid pattern forcing it to break reception until it sees a synchronization.
But you normally avoids stuffing schemes where you after four-in-a-row force an extra reversed bit. It is way too fragile even if it is compact, since there is no hamming distance. And it can be problematic with encodings where fixed-length data can encode into random-length output.
You normally compute a full set of output patterns with best possible hamming distance. You may for example split the input data into 5-bit blocks and replace with 8-bit blocks. Depending on the size of the input and output code blocks, you can have output code blocks with different hamming distance, allowing one or more bits in each block be inverted while still being able to correctly decode the data. And if a scheme with fixed size of input and output blocks is used, bit errors may not change the length of the stream. This also allows two-dimensional parity information to be used to greatly improve the error-correcting abilities.
But at the very minimum, somethink like the 4B/5B encoding should be used, where each 4-bit group is converted to a 5-bit group with good self-clocking properties and making sure you have a fixed length making sure that bit errors will not produce a a random sequence of decoded bit errors. And the 4B/5B encoding have patterns available for inlining commands in the data stream.
You normally compute a full set of output patterns with best possible hamming distance.
Good plan, but slightly besides the point, since that's no longer bit stuffing. That's a different technique which has variuos different names: Hamming Code or Group Code Recording, among others.