I have an ascii stream to serial port. If the stream is interrupted it seems that ReadFile will be in a continuous loop. The CPU start to work and the execution will not return from ReadFile. The ReadProc is locked.
This is the main thread.
invoke CreateFile,addr comport,GENERIC_READ,0,0,OPEN_EXISTING,0,0
.if eax==INVALID_HANDLE_VALUE
mov hCom,0
....
.else
mov hCom,eax
....
invoke CreateThread,0,0,offset ReadProc,0,0,addr ThreadId
invoke CloseHandle,eax
.endif
This is the ReadProc thread
....
@Read:
lea edi,buffer
.while char!=0Dh
invoke ReadFile,hCom,addr char,1,addr pvBits,0
.if pvBits==1 && eax==TRUE
mov eax,char
mov byte ptr [edi],al
inc edi
.endif
.endw
mov byte ptr [edi],0
....
jmp @Read
Any ideas how to handle this situation?
Best regards
mainly ReadFile waits for input from the COM-port. To solve this you can either use Overlapped IO (ReadFileEx) or, for your case, (re)define the timeout value using SetCommTimeouts().
Not sure what on earth your doing with that CloseHandle.
My recollection with the COM port is that it doesn't block indefinitely. It might return with no data, or less than you want. You can set timeouts for COM ports. And WriteFile to a COM port may return early, so you need to check the dwWrite, advance the buffer pointer and retry sending the remainder.
You're also going to want to set the baud rate, parity and flow control once you have a handle.
To be more specific. There are two types of interupt of the data stream.
1. No data due to device is removed.
2. No data from the connected device.
The device can be connected to the dsub-9 connector, usb-connector or some other connectors. The difference is that if you remove the device from the dsub the CreateFile is still valid but not for the others.
My hope was to avoid to use timeout, but apparently I must do so.
Quote
Not sure what on earth your doing with that CloseHandle.
From msdn: "The thread object remains in the system until the thread has terminated and all handles to it have been closed through a call to CloseHandle. "
Quote
My recollection with the COM port is that it doesn't block indefinitely.
It is blocked indefinitely if the device is removed from a connector other than dsub-9 and the reading is ongoing.
Thank you both for your answers. Now I must figure out how to do to get out if the CreateFile is valid or not.
What's the situation with the DTR/DSR? Depending on the device, you might need to take action to coordinate these signals.
-r