As you ask what I think, I think that for a "first program" submitted here, it is pretty good. In particular I noticed button debounce logic using timers. A bit lengthy for what it does, but it looked OK. I tried to see your blue-button-hang problem and then noticed a few (fatal?!) flaws, so here are a few(?) suggestions for improvement:
One minor pain with the compiler (and partly because of the chip architecture, to be fair) is that when you write
Serial.println("Hello World") the string is placed into RAM (because all data has to be in RAM to be manipulated on the stack or addresses thereto)
You only have 2K (standard Arduino, and The core also takes a hundered+ bytes RAM) so all those "Toggling Red" messages fill up. You also have an 550 byte array - TWICE. As I do not have time to count the sum of all your strings, but from just glancing through it, I'd say you've exceeded RAM.
The usual explanation for "it works sometimes," or "there is a mystic error when I do x-y-z in the program" is RAM is exceeded. This may explain your "stuck on Blue sometimes".
Correction - I just ran your program and included "memoryFree" to check the memory usage and it says you have 833 bytes left. So it isnt that.
You declare new variables all over in your loop(). The RAM usage is the same, although they reside on the stack, and not on the heap. Also they get set to zero (unless you declare them static), with the notable exception of arrays. The scope is limited to the {} block they are in, but they are allocated at the start of the loop (and a few more details)
Thus you use
Serial.println("Start Recording:");
char str[550]="";
is_bound = 1 ;
Strictly speaking the array could be placed in a new memory location on every run through the loop(), but it just happens to work for you, as you have no other function calls, so the array gets placed in the same spot, and nothing has overwritten it, so it works like static for you. Except the compiler has recognized that you declare it inside a small "{ }" - block and do not use it, and thus it is optimized away - the str[550]="" does nothing. Fortunaty for you, you have a global str[], too. and all errors cancel, so to speak.
I suggest you take all your loop variables and place them outside loop(), as you want them to be static.
}else{
inByte = Serial.read();
}
while(inByte != '!'){ //to end the wait ! needs to be at the end
if((inByte-'0') < 10) //Note: This was the biggest pain, for some
reason the buffer
// has many junk values (255 being one). So i have it check
// for a value that is below 10 which it should be anyway
// (its only a byte!). also in order to get the correct int
// value from a byte you must subtract '0'.
{
pause = pause*10; //Muliply last pause by 10 to make it easier
The problem is that you do a Serial.read call without having checked Serial.available. What happens is that while you may have sent a line with "W10!" on the serial line, it takes 10ms/char at 9600 baud. You zip through the code (your loop() probably runs in 0.1ms, if it does not execute any delay()) fetch out the W and then start doing Serial.read in a tight while loop. Serial.read returns -1 if no character has arrived yet. Until the "1" has made it, you read it and then get another thousand -1 until the "0" has gotten through.
Your choice of terminator for the number, the '!' is OK, but you could decide that any non-numeric character is the end of the number (ie the next command). Of course that only works if you do the Serial.available correct, and you may want use Serial.peek() to avoid reading the character so it gets read at the top of the loop() for the command processing.
Lastly a note on timing. If you use Arduino v0022 then all Serial.print will hang (just like the delay() function) until the last character is placed on the TX line (where it takes 10ms for the bits to make it out of the UART and up the USB line). As you echo a >10 bytes string on every button push, your button debounce logic is never used; you effectivly wait for 100ms on the first transient change. If you use the V1.0 the characters are stuffed into a buffer (64 bytes for input and 64 for output) and shipped out via interrupt, in which case the Serial.print is less than 1ms. If you attempt to send faster than it is shipped out the old behaviour occurs.
I have NOT examined you recording/playback logic. You say it works, fine. Your button logic uses a global timer and statevariable, thus you can only push one button at a time (design choice or implementation accident?). The timer variables should be unsigned long.
Dont reply on this thread, start a new one under Programming. You can use the PM function to call my attention to such a thread.
Otherwise I hope this lengthy reply has not put you off from asking more. I got carried away, sorry.