| ||||
|
Look RS232
Download Order Support Testimonials FAQ Online help Modem Programming Serial port RS232 Hardware
Interface RS232C
ProgrammingHistory RS232C Likely problems Hardware
Hardware Properties
Interfacing devicesBit Rates DTE/DCE Speeds Flow control The UART Types of UARTs Null modems Loop Back Plug Registers |
|
||||||||
Another major thing affecting the work of read and write operations is time-outs. Time-outs have the following effect on read and write operations. If an operation takes longer than the calculated time-out period, the operation is finished. No error code is returned by ReadFile, WriteFile, GetOverlappedResult, or WaitForSingleObject. All indicators used to monitor the operation show that it finished successfully. The only way to tell that the operation has timed out is that the number of bytes actually transferred are lower than the number of bytes requested. So, if ReadFile returns TRUE, but fewer bytes were read than requested, the operation has timed out. If an overlapped write operation times out, the overlapped event handle is signaled and WaitForSingleObject returns WAIT_OBJECT_O. GetOverlappedResult returns TRUE, but dwBytesTransferred contains the number of bytes transferred before the time-out. The following code sample shows how to handle this in an overlapped write operation. Function example: BOOL WriteABuffer(char * lpBuf, DWORD dwToWrite); { OVERLAPPED osWrite = {0}; DWORD dwWritten; DWORD dwRes; BOOL fRes; // Create this write operation's OVERLAPPED structure hEvent. osWrite.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL); if (osWrite.hEvent == NULL) // Error creating overlapped event handle. return FALSE; // Issue write if (!WriteFile(hComm, lpBuf, dwToWrite, &dwWritten, &osWrite)) { if (GetLastError() != ERROR_IO_PENDING) { // WriteFile failed, but it isn't delayed. Report error. fRes = FALSE; } else // Write is pending. dwRes = WaitForSingleObject(osWrite.hEvent, INFINITE); switch(dwRes) { // Overlapped event has been signaled. case WAIT_OBJECT_0: if (!GetOverlappedResult(hComm, &osWrite, &dwWritten, FALSE)) fRes = FALSE; else { if (dwWritten != dwToWrite) { // The write operation timed out. // Decide if you want to abort or retry. If you retry, // you need to send only the bytes that weren't sent. // If you want to abort, you would just set fRes to // FALSE and return. fRes = FALSE; } else // Write operation completed successfully. fRes = TRUE; } break;
default: // An error has occurred in WaitForSingleObject. This usually // indicates a problem with the overlapped event handle. fRes = FALSE; break; } } } else { // WriteFile completed immediately. if (dwWritten != dwToWrite) { // The write operation timed out. // Decide if you want to abort or retry. If you retry, // you need to send only the bytes that weren't sent. // If you want to abort, then you would just set fRes to // FALSE and return. fRes = FALSE; } else fRes = TRUE; } CloseHandle(osWrite.hEvent); return fRes; } The SetCommTimeouts function specifies the connection time-outs for a port. To get the current time-outs for a port, a programme calls the GetCommTimeouts function. An applications should get the communications time-outs before changing them. This allows the application to set time-outs back to their original settings when it finishes with the port. Below is an example of setting new time-outs using SetCommTimeouts: COMMTIMEOUTS timeouts; timeouts.ReadIntervalTimeout = 20; timeouts.ReadTotalTimeoutMultiplier = 10; timeouts.ReadTotalTimeoutConstant = 100; timeouts.WriteTotalTimeoutMultiplier = 10; timeouts.WriteTotalTimeoutConstant = 100; if (!SetCommTimeouts(hComm, &timeouts)) // Error setting time-outs. Note Once again, communications time-outs differ from time-out values contained in synchronization functions.E.g. WaitForSingleObject uses a time-out value to wait until an object is signaled; this differs from a communications time-out. Setting the members of the COMMTIMEOUTS structure to ZERO causes no time-outs to occur. Nonoverlapped operations will suspend until all the requested bytes are transmitted. The ReadFile function is suspended until all the requested characters are received at the port. The WriteFile function is suspended until all requested characters are sent out. On the other hand, an overlapped operation won't end until all the characters are transferred or the operation is aborted. The following conditions occur until the operation is completed: WaitForSingleObject always returns WAIT_TIMEOUT if a synchronization time-out is supplied. WaitForSingleObject will suspend forever if an INFINITE synchronization time-out is used. GetOverlappedResult always returns FALSE and GetLastError returns ERROR_IO_INCOMPLETE if called directly after the call to GetOverlappedResult. If the members of the COMMTIMEOUTS structure are set in the following manner the read operations complete immediately without waiting for new data to arrive: COMMTIMEOUTS timeouts; timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) // Error setting time-outs. These settings are necessary when used with an event-based read described in the �Caveat� section earlier. In order for ReadFile to return 0 bytes read, the ReadIntervalTimeout member of the COMMTIMEOUTS structure is set to MAXDWORD, and the ReadTimeoutMultiplier and ReadTimeoutConstant are both set to zero. An application must always specify communications time-outs when using a communications port. The behavior of read and write operations is affected by communications time-outs. When a port is opened for the first time, it uses default time-outs supplied by the driver or time-outs remaining from a previous connection application. If an application assumes that time-outs are set a certain way, while the time-outs are actually different, then read and write operations may never complete or may complete too often. | |||||||||
Contact us © fCoder SIA |