I was wondering how to create a safe UART/USB communication protocol. I need it for the communication between a microcontroller and a PC. I have ~10 commands and thought I'd use 10 separate acknowledge commands for each of them.

The exchange should go like this:

  • PC sends wake up command via UART
  • µC recognizes that the PC is connected and sends his command to the PC, eg. 0x01
  • PC does what it was asked to (some hardware stuff) and responds with ~0x01 when it's done (I negate the number to create a larger "distance" between the two numbers)
  • µC knows that it sent 0x01 and is expecting ~0x01 from the PC. If something other than ~0x01 comes back, the µC will know that something went wrong and will send a new request or an error message

The case that the µC sends 0x01, the PC understands 0x02 and sends ~0x02 back but the µC reads ~0x01 due to some noise would be pretty bad.

How safe is that in terms of transmission, or how can I make this more secure?

  • 1
    \$\begingroup\$ You might want to review the related question of mine and the very good answers to it. \$\endgroup\$ – Eugene Sh. Nov 9 '15 at 18:27
  • 1
    \$\begingroup\$ By "more secure" I take it you mean less prone to transmission errors, not adding crypto etc. to resist eavesdropping and what not. Even just that is a pretty vast field: en.wikipedia.org/wiki/Error_detection_and_correction \$\endgroup\$ – SX welcomes ageist gossip Nov 9 '15 at 18:49
  • 2
    \$\begingroup\$ You might want to look up Hamming coding. It will take up to 16 commands (4 bits), and expand them in a systematic way to 7 bits (which can be transmitted over a standard UART). You can choose to correct any single bit error, or detect whether any two bits have been mis-received. \$\endgroup\$ – Neil_UK Nov 9 '15 at 19:12
  • 2
    \$\begingroup\$ 1) 7 bit + a parity bit is one way and it is simple. It will not catch all possible errors but will catch many. 2) A more robust method is to send two bytes, first with the actual command and second with the 'not' of the first command. 3) Even better is to send a 'command coming' byte, followed by the command, followed by the compliment of the command, followed by a 'end of command byte. The 'command coming' and 'end of command' bytes should be selected to not overlay with any of the command and compliment command bytes \$\endgroup\$ – user3629249 Nov 9 '15 at 19:22
  • 1
    \$\begingroup\$ If you only need 10 commands, you can fit two copies in every byte (for redundancy), plus parity bits. Or since you have a symbol space of 256 symbols, and only need 10, you could simply choose maximally different symbols (all symbols differ by multiple bits), or choose only symbols with even numbers of ones and zeros. You certainly don't have to worry about single bit errors. \$\endgroup\$ – mkeith Nov 9 '15 at 21:40

I think you should define longer commands including probably checksum or CRC and wait for an ACK / NACK or error condition.

You can take examples from easy protocols like TFTP (RFC 1350)

| improve this answer | |

For a safe communication you should consider all possible threads to your communication line. Therefore you need to define, if the system is accessable from the outside (third party systems e.g. wireless)

In generall you have to think about the following threads:

  • repetition
  • ommision
  • resequencing
  • manipulation
  • delay
  • insertion
  • corruption

Standard measures against threads are:

  • Sequencing or timestamps
  • time supervision
  • unique source and destination codes
  • response
  • identification precedure
  • some kind of checksum, hash code ...
  • cryprographic techniques some of these you already have implemented with your simple protocoll.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.