COMM_Print() never returns when opening Arduino UNO R3 serial port

[EmbeddedMan]

If I have an Arduino Uno R3 plugged into my Windows 8 PC, on COM18, and run the following program:


Uses "Console"
Uses "COMM"

Dim hComm As Long
Dim nBytes As Long
Dim sBuffer As String

hComm = COMM_FreeFile
Console_WriteLine("Opening")
COMM_Open("\\.\COM18", hComm)
Console_WriteLine("Done with Err = " & Err)
COMM_Print(hComm, "V" + Chr$(13))
nBytes = COMM_Get(hComm, %COMM_RXQUE)
COMM_TRecv(hComm, nBytes, sBuffer, 1000)
Console_WriteLine("Pre print")
COMM_Print(hComm, "V" + Chr$(13))
Console_WriteLine("Post print")
COMM_Close(hComm)
Console_WriteLine("Press any key to exit.")

Console_WaitKey


then I get

Opening
Done with Err = 0
Pre print

and then it hangs there. I have to unplug the Arduino, at which time the program finishes properly.

I can do this same thing (print "V" + chr$(13) twice) to the Arduino using a terminal emulator just fine, without any hangs. Note that the Arduino is not sending anything back - nBytes is always zero.

Any ideas on how I can debug this further? Why would a COMM_Print() not ever return? Is there some type of COMM setting that I can change to try and help thing?

It's critical that I do two writes with a read between them, or the program doesn't hang. So there's something going on with this USB serial port that involves a writing, then a reading, then the next write never returning.

*Brian

[EmbeddedMan]

I know there's something a little strange with the Arduino Uno, as none of my other USB serial devices (and I've tried many) cause this same hang.

Is there any way to see more what's happening inside ThinBasic when it does the COMM_Print() call?

*Brian

[EmbeddedMan]

Another clue : If I plug the UNO in, and run the sample program above, I get the hang.

If I plug the UNO in, then open up COM18 in a terminal emulator (like Tera Term), then close the terminal emulator (note, I don't type anything), and THEN run the above test program it works fine - no problems.

So there's something going on with how the com port is set up (within Windows?) that TeraTerm does right, but is not being done in my sample program.

*Brian

[EmbeddedMan]

Nevermind. :-) I got it figured out.

For whatever reason, the UNO absolutely needs the baud rate set (to any value - it doesn't seem to matter).

So the following program:


Uses "Console"
Uses "COMM"

Dim hComm As Long
Dim nBytes As Long
Dim sBuffer As String

hComm = COMM_FreeFile
Console_WriteLine("Opening")
COMM_Open("\\.\COM18", hComm)
COMM_Set(hComm, %COMM_BAUD, 123)
Console_WriteLine("Done with Err = " & Err)
COMM_Print(hComm, "V" + Chr$(13))
nBytes = COMM_Get(hComm, %COMM_RXQUE)
COMM_TRecv(hComm, nBytes, sBuffer, 1000)
Console_WriteLine("Pre print")
COMM_Print(hComm, "V" + Chr$(13))
Console_WriteLine("Post print")
COMM_Close(hComm)
Console_WriteLine("Press any key to exit.")

Console_WaitKey

Works every time!!!

No idea why, but I don't much care. It works.

*Brian

[ErosOlmi]

Hi Brian,

I was to reply to set some communication settings before start sending/reading data.
Serial communications always need to "handshake" a common way to talk before talking.
Maybe (but quite sure it is so) your terminal emulator send communication setting (maybe default ones) at the very beginning when you open the serial port.

Use a more classic 9600 baud rate instead of 123 or one of the standard rates: https://www.arduino.cc/en/Serial/Begin

Thanks for letting us know the problem and the solution ;)

Ciao
Eros

[EmbeddedMan]

Eros,

Yes! That was the solution to the problem. This device needed to see a baud rate change message over USB before it would properly allow reading or writing from the PC, and the terminal emulator always sends default settings to the COM port on startup, like you say.

The baud rate doesn't matter in this case, since the device on the other side of the UART link is not trying to read any bytes from the PC nor write any data back to the PC.

If I were expecting to actually TX or RX data with the Arduino, then I would have to set the COM port's baud rate to the baud rate that the Arduino sketch used. But in this case, all that mattered was that a baud rate message was sent, not the actual value of the baud rate.

*Brian

[ErosOlmi]

:)

Programming sometimes is an act of faith!