4
\$\begingroup\$

I'm working on a project where I have to communicate different lengths command from my PC to a microcontroller. (using usb to uart bridge) I already make a litle protocol (start byte, some data, checksum ...) but I need to adapt it for my new need.

I'm wondering if there is already a standard or a common way to do that.

\$\endgroup\$
1

4 Answers 4

Reset to default
11
\$\begingroup\$

variable-length commands

Many people highly prefer fixed-length commands. If you need to have variable-length commands, you need to think about:

  • Is it possible for accidental noise (or malicious pranksters) to generate something that will overflow my receive buffer?
  • If a little bit of noise flips the high bit of the "length" field of a short packet (making it appear to be a long packet), does my system properly recover?
    • bad: the microcontroller stops everything, waiting for the rest of what it thinks is a "long" packet. Several days later, after many frantic attempts to send it messages saying "deploy the airbags", "lower the control rods", "Open the pod bay doors, HAL", etc., it eventually gets all the bytes it expected, sees that the checksum fails, throws away this "long packet", and starts working normally again.
    • good: after a minute or some other reasonable time, the microcontroller times-out, erases everything in the command buffer (possibly discarding a few "deploy the airbags" messages after the length-corrupted message), and starts working normally again.
    • good: The microcontroller immediately recognizes there is some error in the header (which includes the start byte, the length field, and the header's checksum), and immediately throws away that header and begins searching for the start byte again. The microcontroller immediately starts working normally again, recognizing the first valid command (the header's checksum is good, and also the data's checksum is good) after the corrupted command.
  • Does the microcontroller immediately send one ACK after it sees that the (final) checksum of the packet is good, and then execute the command, and finally send back a response to that command? Or is it better to send only the ACK or only the response? Which one makes it easier to debug?

general protocol design tips

There are many more or less simple protocols listed in the "Serial Programming" Wikibook.

If you're lucky, perhaps one of them is already perfect for your application. Or at least close enough that it only requires a little tweaking to fit.

Pretty much everyone who successfully develops a new protocol goes through these phases:

  • 1 I may not know much, but reading other people's protocols gives me a headache. It looks like a bunch of unnecessary complexity. Let's dump all that stuff and build a nice, simple protocol.
  • 2 It's not working. Maybe if I add [feature 1] then it will work.
  • 3 Better, but still not working very well. Perhaps add [feature 2]? ...
  • 98 Finally it's working. I better write down who does what in my simple protocol so that if I need to switch to a different microcontroller or want to write a better program on the PC, I'll remember how it goes.
  • 99 Funny how my simple protocol takes so many pages to describe.
\$\endgroup\$
6
  • 1
    \$\begingroup\$ I disagree with the last paragraph. Most simple serial protocols are in fact simple and you can go a long way with just some packet timing requirements and CRC. Text based serial protocols without CRC are a different matter altogether. \$\endgroup\$
    – jpc
    Commented Apr 14, 2011 at 15:13
  • \$\begingroup\$ The book claims it's not possible for a protocol to be 8-bit clean while offering 'simple copy' and 'unambiguous start'. Those statements are only true if one restricts oneself to 8-bit data transmission. If one either uses 9-bit data transmission, or uses BREAK characters to indicate start-of-packet, one can have the other advantages sought. \$\endgroup\$
    – supercat
    Commented Aug 30, 2011 at 18:11
  • \$\begingroup\$ @supercat -- Ah, 9-bit transmission. You're right -- That's a glaring omission. Hang on while I fix it ... done. :-). Thank you. \$\endgroup\$
    – davidcary
    Commented Sep 1, 2011 at 21:39
  • \$\begingroup\$ @davidcary: My pleasure. It may be worth mentioning long-break characters as a special case, since even UARTs that are limited to handling 8-bit data frequently have some provision for break characters. While it takes longer to send a break than a normal character, use of breaks for signaling does not require any extra overhead to 8-bit data. \$\endgroup\$
    – supercat
    Commented Sep 1, 2011 at 21:47
  • \$\begingroup\$ @supercat -- Yes. I added a brief mention of the "long break" to that page. Thank you again. \$\endgroup\$
    – davidcary
    Commented Jan 27, 2012 at 15:40
6
\$\begingroup\$

There are many protocols available. One of my favorites is the Modbus. Modbus protocol

\$\endgroup\$
1
  • 1
    \$\begingroup\$ This one is really nice and simple. Just stick to Modbus RTU and do not worry about the standard "function codes". \$\endgroup\$
    – jpc
    Commented Apr 14, 2011 at 15:23
4
\$\begingroup\$

If there is only one master-slave connection, it sounds like you've done all you need to do. Use a standard CRC checksum algorithm, but that's all there is to meaningfully standardize. Don't worry about having an official ISO/IEEE protocol.

\$\endgroup\$
0
\$\begingroup\$

I don't know what your application is for, but if you are trying to do something in a "defined market", then research that market and try to use something that is implemented there. In SCADA, Modbus in any of its two or three (two are serial and one is IP) versions, is a good bet. In CCTV, Pelco D is a good bet. All of these protocols are easy to implement and are documented. And in addition there are other protocols in the same market, so have fun deciding what you want to do. Every protocol that you can find may be "improved" but if you are planning to interface to some "real" equipment, use their protocol, don't invent your own.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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