Re: Serial COM port communication problems

an0047@xxxxxxxxx wrote:
I suggest that you use overlapped I/O and the SetCommTimeouts to cause
it to return when the buffer is full or a brief silence (a few character
times) is detected. Then parse the returned buffer to find the CR characters yourself.
With this approach I have successfully stress tested the COM ports at extreme speeds
and loads without ever losing a character.
Scott McPhillips [MVP VC++]


How can this be done? (SetCommTimeout association to buffer size?)...I
will try to understand the overlapped
method better. Do you mean the Readfile Buffer that receives the data
read? I'm free to set the size of that buffer,
I will need to find the best size for this buffer, subpackages vary
amoung them as much as 20 bytes.
I'm a bit afraid of adding timing parameters to the problem but it
seems an elegant approach, hope
doesn't get more complex.

The problem by this type of signalization (the new timeouted buffers)
is that there will be CRs embeeded
on them. So the CR is first to be found, and regard the left part as a
subpackage or end of a subpackage and the right part as beginning of a
subpackage an so on...? Is there some type of generic algorithm to
build this type of subpackages together?

Thank you very much for your advice


Timing is the essence of the problem. The device driver is fast enough to receive all characters and put them in your buffer, but your program is much slower due to multitasking delays. So your program must process large numbers of characters that are returned occasionally in the ReadFile buffer. The ReadFile buffer should be large enough to hold all data that might be received while your program is suspended - perhaps 100-200 msec, possibly even longer. Do not consider the subpackage size, only the maximum required buffering time, when sizing the buffer.

You must not rely on the queue size reported by ClearCommError: That can cause a timing problem that is probably the cause of your data loss. By the time you read the data the queued size could have changed. The correct size is returned by ReadFile or GetOverlappedResult.

SetCommTimeouts is not set according to buffer size, it should be set according to baud rate and the timing characteristics of your data stream. There are probably gaps in the data stream (intervals with no characters). Use SetCommTimeouts to return when it detects such a gap. Example: 10/9600 = .001 seconds per character, times N character times in a gap. You would like this to be > .05 seconds if possible, to reduce processor loading.

To parse the buffer and put together the subpackages you can use memchr and memcpy.

--
Scott McPhillips [MVP VC++]

.

Relevant Pages

  • renee.rtf.xaa
    ... renee is RTF parser/macro processor I wrote. ... Character Stream\ ... Write Output Buffer to Files\ ...
    (comp.lang.tcl)
  • Re: input & output in assembly
    ... [As you've not specified OS or assembler, ... using individual character I/O and handling the rest yourself in your ... it finds in that string, ... ENTER key is pressed (maximum buffer size: ...
    (comp.lang.asm.x86)
  • Re: input & output in assembly
    ... [As you've not specified OS or assembler, ... using individual character I/O and handling the rest yourself in your ... it finds in that string, ... ENTER key is pressed (maximum buffer size: ...
    (alt.lang.asm)
  • Re: Can C do it ?
    ... where the user enters data with getchar() handling it like in the code ... and so on for each character entered until is pressed down. ... The Linux terminal driver does line canonicalization (in the normal ... For the next one the stdio buffer is now empty, ...
    (comp.lang.c)
  • Stateful character decoder?
    ... a decoder that will cache incomplete characters so that the caller can simply discard its entire input after calling the decoder. ... If you want to treat your input as a character stream, you've got a couple of very convenient options: InputStreamReader and BufferedReader. ... The problem with the latter is that using a CharsetDecoder explicitly means that if you get a partial character at the end of the current input buffer, you have to preserve those bytes and resubmit them to the decoder on the next try. ...
    (comp.lang.java.programmer)
Loading