Re: WaitCommEvent and ResetEvent for SerialPort
- From: "Hector Santos" <nospamhere@xxxxxxxxxxxxxx>
- Date: Wed, 13 Apr 2005 15:56:24 -0400
There are many issues here, but when I hear "large incoming buffer" and
issues like this, it is usually related to flow control design issues.
This is extremely true when you say you are exhausting the input buffer, in
which case, you should completely stay away from resetting events yourself.
In any case, large incoming buffer where you have partial processing
typically means you need to look at design that incorporates:
- Background I/O threading using circular buffers
- Proper setting of flow control (DCB)
Not knowing exactly what you are doing, but if you are reading data, then
processing incomplete amounts and then going back to get the remaining
parts, well, that means you need the above. Otherwise, you need to do
something like:
Read
Stop Flow
Process
Start Flow
Goto Read
which is doable but inevitably unreliable logic for large I/O applications.
The general rule of thumb is "Receive High, Transmit Low" in serial
communications.
What you want is to received as fast as possible with no interruptions into
a large circular buffer. This receiver thread will then signal your main
application that data is available. This is where you will read the data
available and process it accordingly. In the mean time, the background
thread is doing its work receiving more data as you do your processing.
All top notch serial classes, APIs or libraries, commericial or otherwise
use background Serial I/O frameworks. Look for one. Check out
http://www.codeproject.com I think there I saw one there.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
"stephSF" <stephSF@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:CA8365E6-B155-4A2E-89DB-2EB21A1B79CC@xxxxxxxxxxxxxxxx
> Yes, I saw that example too and found that interesting.
>
> Most of the time it does work, in fact well over 99% of the time it works,
> but we are getting sporadic "time-outs" at higher layers indicating that
the
> message is not complete. I think what you are saying is what we are
seeing.
> We have our receive timeouts return from ReadFile() immediately with what
it
> has and we continue doing a ReadFile() until it returns no data.
>
> So to sum up, yes we are seeing what you are saying.
>
>
> "Chris Burnette" wrote:
>
> > From the WaitCommEvent documentation, the overlapped structure should
> > contain a manual-reset event, but the samples use an auto-reset event.
In
> > either case, WaitCommEvent is supposed to handle the signalling state of
the
> > event itself (it states that it sets the event to non-signalled before
> > actually waiting).
> >
> > Let me see if I can synopsize what's happening:
> >
> > You receive a block of character (let's say 1024). This triggers
> > WaitCommEvent.
> > You try to read these characters, but it timesout or something and you
only
> > get 512.
> > You sit at WaitCommEvent. Since no characters are currently coming it,
you
> > sit there.
> > More characters come in triggering WaitCommEvent.
> > You perform a read, and there are the other 512 characters from the
first
> > message.
> >
> > Does this about sum it up?
> >
> > Chris
> >
> >
> > "stephSF" <stephSF@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> > news:2D3B283B-7E00-4F1F-8D64-91166C15F246@xxxxxxxxxxxxxxxx
> > > Can anyone tell me if the ResetEvent() for the manual reset event used
in
> > > WaitCommEvent is necessary or will it bite us? A large stream of
> > > characters
> > > come in, we receive a portion of them and process them, but then
timeout
> > > (within a higher layer) indicating that the complete message wasn't
> > > received
> > > within the timeout. However, if we transmit another message; its
response
> > > then triggers us to receive more characters and low and behold the 1st
> > > response's completing message is there, too. We do not experience any
UART
> > > overruns or any other serial error, so we know the characters are out
of
> > > the
> > > UART and we also know that the transmitting side is NOT delaying
sending
> > > these characters in the response.
> > >
> > > I have seen numerous SerialPort implementations searching on google,
some
> > > seem to have the ResetEvent and others do not. I was just thinking
that
> > > maybe
> > > we are resetting an Event that maybe WaitCommEvent has just signaled
to
> > > indicate we've received more characters.
> > >
> > > any help???? Note, we have experienced this on NT and XP (XP,
> > > dual-processor)
> > >
> > > // Create an event object for WaitCommEvent()
> > > overlappedCommStatus.hEvent = CreateEvent (NULL, true, false, NULL);
> > >
> > > // Overlapped I/O event types
> > > enum eventType
> > > {
> > > EVENT_TERMINATE = WAIT_OBJECT_0,
> > > EVENT_OVERLAPPED_STATUS
> > > } event;
> > >
> > >
> > > HANDLE eventArray[MAX_NUM_EVENT_HANDLES] = {evTerminate,
> > > overlappedCommStatus.hEvent};
> > >
> > > /* Set the event mask:
> > > * EV_DSR: The DSR signal changed state.
> > > * EV_RXCHAR: A character was received and placed in the input buffer.
> > > * EV_ERR: A line status error occurred (CE_FRAME, CE_OVERRUN, or
> > > CE_RXPARITY).
> > > */
> > > dwCommEvent = EV_DSR | EV_ERR |EV_RXCHAR;
> > > SetCommMask(m_PortHandle, dwCommEvent);
> > >
> > > while (!done)
> > > {
> > > while (!waiting)
> > > {
> > > if (!WaitCommEvent(m_PortHandle, &dwCommEvent, &overlappedCommStatus))
> > > {
> > > if ((dwError = GetLastError()) == ERROR_IO_PENDING)
> > > {
> > > waiting = true;
> > > }
> > > else
> > > {
> > > try
> > > {
> > > ClearError();
> > > }
> > > catch (...)
> > > {
> > > break;
> > > }
> > > }
> > > }
> > > else
> > > {
> > > // WaitCommEvent returned immediately. Make sure event is set
> > > SetEvent(overlappedCommStatus.hEvent);
> > > waiting = true; // bust out of waiting loop to handle event.
> > > }
> > > }
> > >
> > > // We can wait forever, because one of the things we are waiting for
> > > // is our terminate signal.
> > > event =
> > > (eventType)WaitForMultipleObject(MAX_NUM_EVENT_HANDLES,
> > > eventArray, false,
> > > INFINITE);
> > > waiting = false;
> > >
> > > switch(event)
> > > {
> > > case EVENT_TERMINATE:
> > > done = true;
> > > break;
> > >
> > > case EVENT_OVERLAPPED_STATUS: // Event occurred
> > > DWORD dwOvRes;
> > > if (!GetOverlappedResult(m_PortHandle, &overlappedCommStatus,
> > > &dwOvRes, false))
> > > {
> > > // An error occurred in the overlapped operation;
> > > dwError = GetLastError();
> > > try
> > > {
> > > ClearError();
> > > }
> > > catch (...)
> > > {
> > > done = true;
> > > }
> > > }
> > > else
> > > {
> > > // Status event is stored in the event flag, dwCommEvent,
> > > // specified in the original WaitCommEvent call.
> > > // Deal with the status event as appropriate.
> > > HandleCommEvent(dwCommEvent);
> > > ResetEvent(overlappedCommStatus.hEvent);
> > > }
> > > break;
> > >
> > > default:
> > > // Error in WaitForMultipleObjects; abort. This indicates a
problem
> > > with
> > > // the OVERLAPPED structure's event handle.
> > >
> > > done = true;;
> > >
> > > } // switch
> > > } // while
> > > }//Create comm event
> >
> >
> >
.
- Follow-Ups:
- Re: WaitCommEvent and ResetEvent for SerialPort
- From: stephSF
- Re: WaitCommEvent and ResetEvent for SerialPort
- References:
- WaitCommEvent and ResetEvent for SerialPort
- From: stephSF
- Re: WaitCommEvent and ResetEvent for SerialPort
- From: Chris Burnette
- Re: WaitCommEvent and ResetEvent for SerialPort
- From: stephSF
- WaitCommEvent and ResetEvent for SerialPort
- Prev by Date: Re: WaitCommEvent and ResetEvent for SerialPort
- Next by Date: Re: WriteFile()
- Previous by thread: Re: WaitCommEvent and ResetEvent for SerialPort
- Next by thread: Re: WaitCommEvent and ResetEvent for SerialPort
- Index(es):
Relevant Pages
|
