Electronic – Hardware/software needed to decode Differential Manchester

No, there is no standard or even generally accepted common practise.

If you are really sure all you will ever send over this link is a stream of 12 bit values, then you can put 6 bits in each byte and use the remaining 2 bits to identify whether this byte contains the high or low 6 bits of the 12 bit word. That leaves two more codes for a little expansion.

However, that's not what I'd, and certainly not what I usually do. No matter how much you think to the contrary now, chances are good that sooner or later you'll wish you could send something else over the link, even if just for debugging. Since you say bandwidth is not a problem, do it right now so that expanding the protocol will be easy.

What I usually do is send data in packets that start with a opcode byte, which is then followed by whatever data goes along with that opcode. I have done this many times. For clarity of documentation, I call packets from the host to the micro commands, and from the micro to the host responses, but that doesn't mean responses must be only a result of commands.

This scheme is easy to implement in firmware. It's easy on the host too, but that doesn't matter. With the infinite processing power and memory of a PC, any protocol you cook up that is tractable on the micro will be easy on the host. The point is to keep it simple on the small resource-limited system and have the other system adapts as necessary.

On receiving, I use a jump table for the opcode byte. That dispatches to the routine unique for that command, which knows how many more input stream bytes to read and what to do with them. When done, command routines jump back to a common return point, which fetches the next opcode, dispatches thru the table, which runs the next command routine, etc.

Once you have this mechanism set up and a test program on the host to read and write this protocol, it is really simple to add another command or response. Being so simple, you'll start to use this facility in ways you might not have envisioned at the start. For example, you can make a command that sets a debug bit in the firmware which causes other code to do something special. Or you realize there are some options you would like to control, maybe read back data memory, a special command that does something one-off for testing, etc, etc. This sort of stuff comes in really handy a lot.

To solve the particular case you asked about, you'd have a response that is followed by 2 bytes which contain the 12 bit number. In the micro, that's as simple as sending the response opcode byte followed by the two data bytes periodically. Meanwhile it leaves open the option of sending other things without messing up the stream of 12 bit values.

Your representation is correct. Differential Manchester encodes each data bit as follow:

• If it has the same value as the data bit before --> High to Low transition (that would be a '0' in non-differential Manchester)
• If it has a different value than the data bit before --> Low to High Transition (that would be a '1' in non-differential Manchester).

The very first bit of the transmission would not be specified, you may choose to encode it as normal Manchester.

You may also first calculate the "differential data stream" and then perform a normal Manchester encoding of this differential data stream. The differential data stream would be defined as: \${\text{diff}}_i={\text{data}}_i \oplus {\text{data}}_{i-1}\$.

For example if your data is 00110110 you would get X0101101 and then encode it as normal Manchester.

The decoding of the data stream is just the same. You may decode it first as normal Manchester and then apply \${\text{data}}_i={\text{decoded}}_i \oplus {\text{decoded}}_{i-1}\$