There seems to be reason to think about filled buffers causing stalls and timeouts, but comments regarding 5-second sleeps between trials seem to rule that out. To debug what's actually happening, you might blink an LED each time you receive a character, and another LED each time you call your parse_command() routine; and if you have an oscilloscope, look at the serial transmissions back and forth to see whether delay is due to something at the Arduino end vs at the host end.
That said, I think it would make sense to simplify the protocol by getting rid of your input buffer and just processing input as it comes. For example, you could use the following letters as post-fix actions.
A Select shield 1
B Select shield 2
P Set pin number, eg 11P selects pin 11
S Set speed, eg 472S sets speed to 472
N Send current speed to current pin, then increment pin number
For example, the command sequence for “disable_all” could look like:
0S0PANNNNNNNNNNNN 0PBNNNNNNNNNNNNN
This is easy to parse on the fly; declare int val=0 and any other needed variables before loop(), then within loop() say:
char inc; // For incoming character
while (Serial.available()) { // Get characters
inc = Serial.read();
if (inc >= '0' && inc <= '9') {
val = 10*val + (inc-'0');
} else {
switch (toupper(inc)) {
case 'A':
board = 0;
break;
case 'B':
board = 1;
break;
case 'P':
pin = val;
break;
case 'S':
speed = val;
break;
case 'N':
if (PinNumberIsOk(board, pin))
pwm[board].setPWM(pin, 0, speed);
++pin;
break;
default :
; // handle blanks, returns, whatever
}
val = 0; // Set val to zero on any non-digit
}
As another example, the sequence 4PA 11SN13SN17SN would send speeds 11, 13, and 17, respectively, to motors 4, 5, 6 on the first shield.