Click here to Skip to main content
15,891,943 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Folks,

I have an application that simulates an 8051 comm protocol. This requires changing the parity mid-message. The first byte is a Wake-up byte and needs Mark parity. After sending that byte, the parity needs to be changed to Space for the remainder of the message.

This has been working just fine since 2000 under Win98, but I've recently ported the app to XP. Now, it seems that the call to SetCommState, which occurs after the Wake-byte to change parity to Space, takes about 1.5 seconds! This delay causes the receiver to ignore the message.

Code snippet:

C++
static BOOL XmitPacket (BYTE * lpPacket)
{
	BOOL fWriteOk;
	BOOL fRcvdACK = FALSE;
	int tries = 0;
	
	// save the value of the Ack we're looking for
	gDesiredTxAck = ACKBYTE (lpPacket[0]);

	// attempt to send the packet
	do
	{

		fWriteOk = CommWriter (&lpPacket[0], 1);


		if (!fWriteOk)
			break;
			
		if (SetCommState (ghCommDev, &gdcbSpaceParity) == 0)
		{
			AteError_WinSys ("RCI:XmitPacket:SetCommState (gdcbSpaceParity)", 0);
			break;
		}

		fWriteOk = CommWriter (&lpPacket[1], lpPacket[1]);
		Sleep(40); //need for Pentium 4  CPU communications
		
		if (SetCommState (ghCommDev, &gdcbMarkParity) == 0)
		{
			AteError_WinSys ("RCI:XmitPacket:SetCommState (gdcbMarkParity)", 0);
			break;
		}

		if (!fWriteOk)
			break;

	     Sleep(40);

		//
		// then, wait for the RCM to send an Ack
		//
		if (WaitForSingleObject (ghSignalAckRcvd, gdwAckTimeoutPeriod) == WAIT_OBJECT_0)
			fRcvdACK = TRUE;
	} while (!fRcvdACK && (++tries < gXmitMaxRetries));
	
	if (!fRcvdACK)
		++gXmitErrCounter;

	return fRcvdACK;
}



Output from Sysinternals Portmon:
9:25:07 AM	iGenATEB3.exe	IRP_MJ_WRITE	NiSerP1	SUCCESS	Length 1: .	
9:25:07 AM	iGenATEB3.exe	IOCTL_SERIAL_WAIT_ON_MASK	NiSerP1	SUCCESS		
9:25:07 AM	iGenATEB3.exe	IOCTL_SERIAL_GET_BAUD_RATE	NiSerP1	SUCCESS		
9:25:07 AM	iGenATEB3.exe	IOCTL_SERIAL_GET_LINE_CONTROL	NiSerP1	SUCCESS		
9:25:07 AM	iGenATEB3.exe	IOCTL_SERIAL_GET_CHARS	NiSerP1	SUCCESS		
9:25:07 AM	iGenATEB3.exe	IOCTL_SERIAL_GET_HANDFLOW	NiSerP1	SUCCESS		
9:25:08 AM	iGenATEB3.exe	IOCTL_SERIAL_SET_BAUD_RATE	NiSerP1	SUCCESS	Rate: 38400	
9:25:08 AM	iGenATEB3.exe	IOCTL_SERIAL_CLR_RTS	NiSerP1	SUCCESS		
9:25:09 AM	iGenATEB3.exe	IOCTL_SERIAL_SET_LINE_CONTROL	NiSerP1	SUCCESS	StopBits: 1 Parity: SPACE WordLength: 8	
9:25:09 AM	iGenATEB3.exe	IOCTL_SERIAL_SET_CHAR	NiSerP1	SUCCESS	EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13	
9:25:09 AM	iGenATEB3.exe	IOCTL_SERIAL_SET_HANDFLOW	NiSerP1	SUCCESS	Shake:52 Replace:0 XonLimit:2048 XoffLimit:512	
9:25:09 AM	iGenATEB3.exe	IRP_MJ_WRITE	NiSerP1	SUCCESS	Length 5: .....	


From this you can see between 1 and 2 seconds have elapsed between writing the single byte (at 9:25:07) and writing the rest of the message (at 9:25:09).

Any of you folks have an idea as to what's up here?

TIA!
Jesse
Posted
Updated 21-Apr-14 9:47am
v2
Comments
[no name] 19-Mar-15 12:59pm    
Are you using a direct serial port or a USB to serial adapter?

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900