user29611: I'm sending via Bluetooth with an Android App two bytes like this:
private void _sendCommand(byte command, byte arg)
{
    if (CONNECTED)
    {
        try
        {
            os.write(new byte[]{command, arg});
            os.flush();

        } catch (IOException e) {
            Log.e(TAG, "Error sending command: " + e.getMessage());

        }
    }
}

And this is the code I'm using to receive them with Arduino:
byte _instruction;
byte _arg;

void loop() 
{    
  while(Serial.available() < 2)
  {
    digitalWrite(LED_BUILTIN, HIGH);
  }

  digitalWrite(LED_BUILTIN, LOW);

  _instruction = Serial.read();
  _arg = Serial.read();
  Serial.flush();

  switch (_instruction) 
  {

     ...

  }
}

I don't have any problems sending just one byte (modifying the code to receive just one), but I can't do the same with two bytes. It's always stuck in the while. Any idea of what I'm doing wrong?

EDIT: As ST2000 pointed out, there was a problem of syncronization, so this is the code working properly:
void loop() 
{    
  // Wait until instruction byte has been received.
  while (!Serial.available());
  // Instruction should be read. MSB is set to 1
  _instruction = (short) Serial.read();

  if (_instruction & 0x80)
  {
    // Wait until arg byte has been received.
    while (!Serial.available());
    // Read the argument.
    _arg = (short) Serial.read();

    switch (_instruction) 
    {
      ...
    }
  }

  Serial.flush();
}

Thanks,

user20245: There may be a underlying problem with synchronizing the transmitter and receiver.  They both have to agree / know which is a command byte and which is a data byte.
In order to do this, some protocols sacrifice a bit. For example you could set the most significant bit for commands and not set the most significant bit for data. However, that does mean you can only send data in the range of 0 to 127. And it does restrict you to only 128 commands. If you need more, and want to stick to this "most significant bit" approach, you could break your data into chunks and only send 7 bits at a time. The possibilities are many. Use this one or make one up that fits your needs better. 
In order to implement this approach, you will need to read and process each byte as it arrives.  You can not wait until you accumulate the expected number of bytes as this assume you are always in sync with the transmitter. Which may not be the case.

29611: <p>I'm sending via Bluetooth with an Android App two bytes like this:</p>

<pre><code>private void _sendCommand(byte command, byte arg)
{
    if (CONNECTED)
    {
        try
        {
            os.write(new byte[]{command, arg});
            os.flush();

        } catch (IOException e) {
            Log.e(TAG, "Error sending command: " + e.getMessage());

        }
    }
}
</code></pre>

<p>And this is the code I'm using to receive them with Arduino:</p>

<pre><code>byte _instruction;
byte _arg;

void loop() 
{    
  while(Serial.available() &lt; 2)
  {
    digitalWrite(LED_BUILTIN, HIGH);
  }

  digitalWrite(LED_BUILTIN, LOW);

  _instruction = Serial.read();
  _arg = Serial.read();
  Serial.flush();

  switch (_instruction) 
  {

     ...

  }
}
</code></pre>

<p>I don't have any problems sending just one byte (modifying the code to receive just one), but I can't do the same with two bytes. It's always stuck in the while. Any idea of what I'm doing wrong?</p>

<hr>

<p>EDIT: As ST2000 pointed out, there was a problem of syncronization, so this is the code working properly:</p>

<pre><code>void loop() 
{    
  // Wait until instruction byte has been received.
  while (!Serial.available());
  // Instruction should be read. MSB is set to 1
  _instruction = (short) Serial.read();

  if (_instruction &amp; 0x80)
  {
    // Wait until arg byte has been received.
    while (!Serial.available());
    // Read the argument.
    _arg = (short) Serial.read();

    switch (_instruction) 
    {
      ...
    }
  }

  Serial.flush();
}
</code></pre>

<p>Thanks,</p>
 20245: <p>There may be a underlying problem with synchronizing the transmitter and receiver.  They both have to agree / know which is a command byte and which is a data byte.</p>

<p>In order to do this, some protocols sacrifice a bit. For example you could set the most significant bit for commands and not set the most significant bit for data. However, that does mean you can only send data in the range of 0 to 127. And it does restrict you to only 128 commands. If you need more, and want to stick to this "most significant bit" approach, you could break your data into chunks and only send 7 bits at a time. The possibilities are many. Use this one or make one up that fits your needs better. </p>

<p>In order to implement this approach, you will need to read and process each byte as it arrives.  You can not wait until you accumulate the expected number of bytes as this assume you are always in sync with the transmitter. Which may not be the case.</p>
