serial monitoring with Putty - do I need a second PC?

I have been using Putty on my PC with NewSoftSerial to monitor variables. To run Putty I set a com port than is different from the Arduino board, and it all seems to work, but...

NewSoft Serial seems to be so slow that I can every easily bog down a timing sensitive Arduino program.

Maybe I need to use the TX hardware serial port on the board?

Is there any way to run Putty so I can see that same com port that the IDE uses? It seems like the Arduino IDE grabs that com port, so the only way to do it would be to run Putty on a different PC.

Am I missing something?

The IDE only grabs the port when actively uploading a sketch, or when using the Serial Monitor. If you upload the sketch, and then start putty it should monitor the HW serial port without any problem. You'll have to exit putty before you can upload a new version of the sketch, though.

Much appreciated. Sounds like a second PC would be easiest for debugging.

What baudrate are you using with newSoftSerial? it can do 115200

For debugging purpose it is often enough to send just 1 or 2 bytes to the PC and not a complete string. You can save up to a factor 20 or so. The price is that you need a receiving application that parses the incoming bytes an looks up the real message from a table and optionally receive some additional bytes.

a simple protocol could look ike:

0..199 -> indicates a position in the code 

200 -> OK
201 -> OK<1 byte>        // so after a 201, one more extra byte is read to dump a var
202 -> OK<2 bytes>               
203 -> OK<4 bytes>               
204 -> OK<string>         // string is \n terminated.

210 -> error
211 -> error <1 byte>        // so after a 201, one more extra byte is read to dump a var
212 -> error <2 bytes>               
213 -> error <4 bytes>               
214 -> error <string>         // string is \n terminated.

Further only place debug statements where you really need them. I sometimes see code full with debug statements, overkill. If you divided your code/design in enough functions, you can test one level at the time. Remove // comment debug statements from code as fast as possible.

Finally you can do delayed debugging, in which the messages are stored in an array (faster then printing) and only when the system has passed the time critical section you dump them to serial. E.g. you can log all the boolean conditions of a time critical section, to be able to replay the code by hand.

I'm using 115200, but definitely short messages are the only way to go. Yes, I do all these practices - good advice though.