Re: rs232 -help!
- From: "Heinz Ozwirk" <hozwirk.SPAM@xxxxxxxx>
- Date: Tue, 27 Jun 2006 09:16:10 +0200
"Robby" <Robby@xxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag news:91E88AF3-C15C-4E6E-9D57-C5E79F7F688D@xxxxxxxxxxxxxxxx
Hello,
At this point if anyone has used the CSerialWnd class from code project, I
am desperately in need of a code sample doing a Read task from rs232.
I have been exploiting this subject with some of the most credible fellows
on this newsgroups and I fully appreciated their support and wish to
continue. I am re-starting this subject so not to clutter the previous post
and to give the full story in case I didn't post it right before.
Right now I have the following code:
===========================================
//Global object declared one time
CSerialWnd MySerial;
LRESULT CALLBACK WndProc_CW1 (HWND hwnd, UINT message,
WPARAM wParam, LPARAM lParam)
{
static DWORD dwBytesRead = 23;
static BYTE abBuffer[23];
static TCHAR szBuffer[49];
MySerial.Open(TEXT("COM1"),hwnd,WM_NULL,lParam,0,0);
//Serial port monitor
if (message == CSerialWnd::mg_nDefaultComMsg)
{
// A serial message occurred
const CSerialWnd::EEvent eEvent = CSerialWnd::EEvent(LOWORD(wParam));
const CSerialWnd::EError eError = CSerialWnd::EError(HIWORD(wParam));
MySerial.Setup(CSerial::EBaud9600,CSerial::EData8,
CSerial::EParNone,CSerial::EStop1);
MySerial.SetupReadTimeouts(CSerial::EReadTimeoutBlocking);
switch (eEvent)
{
case CSerialWnd::EEventRecv:
MySerial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
//abBuffer[dwBytesRead] = 0; //Null character is now included in
receiving msg
break;
default:
break;
}
MultiByteToWideChar(CP_ACP,0, (LPCSTR)abBuffer,23,szBuffer,49);
MySerial.Close();
return 0;
}
I don't know the details of your CSerialWnd class, so I can only add some general comments.
1. Usually you should not open the port, initialize it and close it again in each and every message sent to a window. Usually you should open and initialize the port once when your program starts and close it only when your program terminates (or you don't want to receive more data).
2. Often serial ports don't give you the number of bytes you are asking for. You'll get as many bytes as are available when the read function is called. You have to test the number of bytes returned, and if not enough data is available yet, you have to store what you have got and wait for more data to be sent.
3. Often serial ports signal each byte they are receiving, or or groups of bytes when there is some delay between them. But the receiver might read all bytes when it processes the first event. Then more events may be in the window's message queue, but the bytes causing them have already been read. This especially happens when you slow down your receiver while debugging. For the first byte a message is sent to your window. This message is processed and execution stops at the breakpoint before calling Read. While the debugger waits for you to step through your code, mode data might arrive and Read will return those bytes, too. But messages generated for those bytes are still in the queue and will be processed once you have stepped through your code. Now when the next message is processed, the data causing that message have already been read, and Read will wait for the specified time. Try to find out how to determine the number of bytes available and only read that many bytes.
4. Don't use too large timeouts. The read intervall timeout depends on the behaviour of the sender of your data. How long does it need between sending two bytes. This timeout should be large enough for the sender to fetch and transmit the next byte. But values about 100ms should be large enough. The timeout multiplier depends on the selected baud rate. The higher that rate, the smaller this value can be. With 9600 baud you can transmit a little less than 1000 characters per second, so this timeout could be 2ms, but larger values usualy will not be harmfull. The total constant timeout basically determines the time a blocking read waits when no data is available. Usually I use values between 0.5 and 5 seconds.
But whatever timeouts you are using, be prepared that you do not read as many bytes as you are expecting. Provide some way to collect data of multiple reads and process them only when you got all the data you need.
The correct message was returned. However, immediately after, VC++ shows my
program going back again to the break point a second time without me having
sent another message to the port. I guess this event is caused by some junk
left over in the serial buffer. So I step to the Read statement.... and then
VC++ hangs thereafter!
First, I don't know if my Comm timeout is well set.... ? Obviously, if it
were, well then the Read function would of returned.... right?
Read the documentation of CSerial what EReadTimeoutBlocking really means. The name suggests that the read hangs until the requested number of bytes is available. Such behaviour does not really work well with (Windows-) message driven applications. When you read whenever data is signaled to your application, you should use small timeouts and never read more bytes then available at that time.
HTH
heinz
.
- Follow-Ups:
- Re: rs232 -help!
- From: Robby
- Re: rs232 -help!
- References:
- rs232 -help!
- From: Robby
- rs232 -help!
- Prev by Date: RE: Wierd Problem-missing .lib files even after successful dll creatio
- Next by Date: Re: Wierd Problem-missing .lib files even after successful dll creation
- Previous by thread: rs232 -help!
- Next by thread: Re: rs232 -help!
- Index(es):
Relevant Pages
|
Loading
