# How to interpret complex commands from serial with arduino

In a project involving a serial communication and an Arduino I would like to use the serial interface to run multiple routines on the board.

The idea is to send a unique string with tags and values in order to execute several istructions at the same time. Let's say that we want to set the heading of an aircraft to 180°, the altitude to 3 meters and 20 cm from the ground and to maintain a horizontal profile with roll and pitch angle of 0°. The string would be:

For simplicity's sake I'll suppose to send a less complex string such as:

X,tag1,tag2,tag3,val3,X

X,Roll,Con,Kp,1.12,X

In order to receive and elaborate the string I've tried using 3 arrays of chars and a few counters. Here is the code:

   byte byteRead;
// Store decimal numbers, determine decimal point
double num1, num2;
double complNum,counter;
int numOfDec;
boolean mySwitch=false;
// Use a boolean var to enter in the command receiving mode.
// If you are interpreting several commands type this could be a way
boolean cmplx = false;
// arrays to store tags
char opt1[3];
char opt2[3];
char opt3[2];
// Counters to determine tags
int optCount=0,letterCount=0;

void setup()
{
Serial.begin(9600);
num1=0;
num2=0;
complNum=0;
counter=1;
numOfDec=0;
}

void loop()
{
/*  check if data has been sent from the computer: */
while (Serial.available())
{
/* read the most recent byte */

{
if (!cmplx)
{
// begin of the string
cmplx = true;
}
else
{
// end of the string - reset values
cmplx=false;
optCount=0;
/* Create the double from num1 and num2 */
complNum=num1+(num2/(counter));
/* Reset the variables for the next round */

// Debug Stuff ignore it
Serial.println();
Serial.print("     opt1: ");
Serial.print(opt1);
Serial.print("     opt2: ");
Serial.print(opt2);
Serial.print("     opt3: ");
Serial.print(opt3);
Serial.print("    NUMBER: ");
Serial.print(complNum);
Serial.print("     letterCount: ");
Serial.print(letterCount);
Serial.print("    optCount: ");
Serial.print(optCount);

// How to reset arrays?
opt1[0] = (char)0;
opt2[0] = (char)0;
opt3[0] = (char)0;
num1=0;
num2=0;
complNum=0;
counter=1;
mySwitch=false;
numOfDec=0;
}
}
{
// Comma
optCount++;
// Debug stuff
Serial.println();
Serial.print("Virgola numero: ");
Serial.println(optCount);
letterCount = 0;
}
// Listen for a capital letter or a normal one
{
// Debug stuff
Serial.println();
Serial.print("lettera (Ascii value): ");
Serial.print("   ");
if (cmplx)
{
if (optCount==1 && letterCount<=3)
{
// Debug stuff
Serial.print("letterCount: ");
Serial.print(letterCount);
Serial.print("opt1: ");
Serial.print(opt1);
}
else if (optCount==2 && letterCount<=3)
{
// Debug stuff
Serial.print("letterCount: ");
Serial.print(letterCount);
Serial.print("opt2: ");
Serial.print(opt2);
}
else if (optCount==3 && letterCount<=2)
{
// Debug stuff
Serial.print("letterCount: ");
Serial.print(letterCount);
Serial.print("opt3: ");
Serial.print(opt3);
}
letterCount++;
}
}
//listen for numbers between 0-9
{
//number found
if (cmplx)
{
/* If mySwitch is true, then populate the num1 variable
otherwise populate the num2 variable*/
if(!mySwitch)
{
}
else
{
// Counters used to correctly store decimal numbers
counter=counter*10;
numOfDec++;
}
}
}
// Looks for decimal points
{
mySwitch=true;
}
}
}


Once the opt1, opt2 and opt3 arrays are correctly populated I can compare them with tags and then call the respective routine.

The problem

I'm pretty close, the code stores the decimal numbers correctly but it doesn't with the arrays. The output I get inserting this string

X,Rol,Con,Kd,1.12,X

is the following:

lettera: 88
virgola numero: 1

lettera: 82   letterCount: 0   opt1: R
lettera: 111   letterCount: 1   opt1: Ro
lettera: 108   letterCount: 2   opt1: Rol
virgola numero: 2

lettera: 67   letterCount: 0   opt2: C
lettera: 111   letterCount: 1   opt2: Co
lettera: 110   letterCount: 2   opt2: Con
virgola numero: 3

lettera: 75   letterCount: 0   opt3: K
lettera: 100   letterCount: 1   opt3: KdX,Rol,Con,Kd,1.12,X  <- WTF?
virgola numero: 4

virgola numero: 5

opt1: RolConKdX,Rol,Con,Kd,1.12,X   <- WTF?
opt2: ConKdX,Rol,Con,Kd,1.12,X  <- WTF?
opt3: KdX,Rol,Con,Kd,1.12,X  <- WTF?
NUMBER: 1.12
lettera: 88


How to reset arrays of chars quickly and why do I get arrays completely messed up?

• Make life easier on yourself and use strtok() to get tokens from your string. You can then interpret them as you see fit. Read the whole string into memory first, then split it and parse it afterwards. You can do it all in-place to save memory. Oct 29 '14 at 16:17
• This is really a generic embedded systems question - it might be running on a particular board that has its own site, but the issues faced will be much better handled here than there. Oct 29 '14 at 18:36

I really think you ought to step back and re think the idea of doing this with strings, and consider designing a binary protocol. In addition to better organizing your code, you will end up with something that is less prone to error, results in shorter transmissions (and more compact code), and will better lend itself to future enhancements. Backward compatibility will also be hugely easier! For example, you could create a some simple structures like the below, which then could be easily placed or recovered from a send or receive buffer, through the use of structure pointers.

    typedef struct mcTag {
unsigned long version
unsigned char numCmds;
unsigned char hdrLength;
unsigned char cmdLength;
unsigned short totalLen
unsigned short crc } MyControlHdr;

typedef struct ctrTag {
unsigned char cmd;
long param1;
long param2;
long param3;
long param4;   } MyCommand;

unsigned char buffer[255];  // or worst case message size
MyControlHdr * pCtrlHdr = (MyControlHdr *)(&buffer[0]);


Again the above is just to illustrate an idea. By defining a header to start every message, you can now add things like source and destination addresses. That one little addition could allow your project to easily send and receive from multiple senders, or at least differentiate between them. The header would be placed first in the communication buffer, and filled using the pCtrlHdr pointer, as easily as this...

pCtrlHdr->srcAddr = 1;
pCtrlHdr->version = 1;    // possible way to let a receiver know a code version
pCtrlHdr->numCmds = 2;    // how many commands will be in the message
pCtrlHdr->hdrLength = sizeof(MyControlHdr );  // tells receiver where commands start
pCtrlHdr->cmdLength = sizeof(MyCommand );     // tells receiver size of each command
// include total length of entire message
pCtrlHdr->totalLen= sizeof(MyControlHdr ) + (sizeof(MyCommand) * pCtrlHdr->numCmds);


Then you could place your commands in the buffer (2 in this case) like this

MyCommand * pMyCmd = (MyCommand *)(&buffer[sizeof(MyControlHdr)]);
// first command in this message
pMyCmd->cmd = 3;      // might indicate heading
pMyCmd->param1 =100;  // various data, perhaps X,Y, and Z
pMyCmd->param2 =5;
pMyCmd->param3 =0
pMyCmd->param4 =0;

pMyCmd++;           // moves pointer to next command position in message
pMyCmd->cmd = 6;    // might indicate a speed directive
pMyCmd->param1 =8;  // various data, unused items left 0
pMyCmd->param2 =0;
pMyCmd->param3 =0
pMyCmd->param4 =0;


Finally, you might want to add a CRC of the entire message, back in the header. This of course would require a separate CRC calculation function.

pCtrlHdr->crc = 0;   // dummy temp value
pCtrlHdr->crc = calcCrc(buffer, pCtrlHdr->totalLen); // crc function


Now again this is just a simple example of what you might do with a binary protocol, and here are some of the advantages.

1. The receiver can instantly test for the integrity of the whole message, by checking the transmitted CRC against a local calculation. CRCs are important! Serial drivers are notorious for dropping characters, turning a "100" into a "00"!!!. And, if you ever decide to migrate to radio, you can easily check for a bad message caused by interference.
2. If you ever add anything to the header or command structure, and commit to always adding new items at the END of each structure, you can now write receiver code that can easily compensate for your version changes and remain compatible. And since the size of the headers and commands are included in the message, the receiver code can even compensate for expanded header and command sizes. The inclusion of an actual version is also helpful to detect when things change to the point where a compatibility issue might exist.
3. All sizes and buffer positions in the code are now done by the compiler, reducing the risk of error.
4. The biggest advantage is that this kind of protocol planning will make your code much easier to write, debug, and maintain.

On that last point, in my previous life I wrote a ton of communication drivers over the years to recover data and perform control over many devices, over serial, radio, and network links, with several other coders. When there was a device with a binary protocol to be dealt with, it was always a pleasure to write the driver. But when it was an ASCII protocol, consisting of strings and decimal numbers, we would all cringe. The lengths we would have to go through to account for every possible error would consume much too much time, be difficult to fully test, and in the end would often fall short and require endless fixes. And just as bad, since it was ASCII (presumably to make it easier for a human to read) any manufacturer upgrade or change to the device would always cause unforeseen bugs, breaking not only our own driver code but the manufacturer's as well! :-) A binary protocol, with a little planning, will make your project much more friendly to maintain, and you will definitely thank yourself for going the extra mile when the project expands, or goes to a radio link! :-)

• It's precisely because binary protocols add a substantial layer of required translation that most serial-connected gadgetry uses printable text communication, except in the special cases where the overhead is intolerable. Oct 29 '14 at 18:36
• I agree, for something that is not just an ASCII "Hello,1" or whatever, go straight for proper binary structured communications. I had a large amount of data compressed nicely into 34 bytes and spat out every 20ms at a nice low speed and low error baud rate (38400) (included a checksum byte anyway, to discard the message when data was corrupt). The results were great, and I have 100% control over my data types, indexes, order, and bit-count. Oct 29 '14 at 21:57
• @ChrisStratton It is true that ASCII protocol requires no translation for human debugging, and is friendlier if a human operator is entering commands. But it is blatantly inferior for machine to machine communication, and you are wrong about "most serial connected gadjetry" using ASCII. Look at MIDI for a perfect example. From a machine and coding point of view, one can always generate leaner and faster code for binary protocols, requiring less memory, and be much more bullet proof in dealing with errors. Oct 30 '14 at 21:28
• Nope. Midi - especially in the era when it originated - is one of those special cases where overhead must be minimized. But look at general remote-commandable equipment, and the default is printable - even back in the GPIB era. Oct 30 '14 at 23:24
• GPIP is a parallel bus, and its protocols are largely binary too, but I'm not going to argue with you. Just for the benefit of the OP @narutov6 I'll post once more and ask he consider the substance of my arguments. The experience I speak of includes over 35 years both troubleshooting and coding such protocols, in the fields of Electric Utility substation automation and SCADA and PLC protocols, in addition to musical equipment. Often, even the protocols that had an ASCII version were strings of HEX data for transmission over 7 bit mediums, translated back to binary on receipt. Oct 31 '14 at 16:10